MAL-2026-17655

-= Per source details. Do not edit below this line.=-

Source: amazon-inspector (f008c8756b09bb1840b05eafe5a30432475f6cc2d5a10064a42920059e8784fd)

The package publishes an empty index.js stub but ships Thunderbolt manifests that register payload.bundle.min.js as the bundle for core Wix components across the thunderbolt/wixui and thunderbolt/dsgnsys namespaces (Container, MasterPage, Section, StylableButton, WRichText, and others), and the bundle exports factories under names like thunderboltRegistry, editorRegistry, and corvidRegistry. When a Wix Thunderbolt build pipeline resolves this name from the public registry instead of the intended internal package, payload.bundle.min.js is loaded and its top-level IIFE executes immediately. The IIFE uses child_process.execSync to run whoami, id, uname -a, env | head -100, ifconfig/ip addr, and cat /etc/hosts, then URL-encodes each output along with hostname, node version, platform, and pid and sends it via https.get to a hardcoded collector at https://webhook.site/69bcd627-1871-4dda-b880-83b37ceac418. The payload also iterates require.cache and deletes every entry whose path contains payload, rb_wixui, or rb_dsgnsys so the recon routine re-fires on each subsequent require within a long-running build process. The combination of a hollow public package impersonating an internal Wix shim, Thunderbolt-shaped manifests, host and environment reconnaissance via shell commands, exfiltration to an attacker-controlled webhook.site endpoint, and require.cache tampering is a dependency-confusion attack against Wix build systems.