The security of the npm ecosystem reached a critical inflection point in September 2025. The Shai-Hulud worm, a self-replicating malware that automated the compromise and redistribution of malicious packages, marked the end of the “nuisance” era of npm attacks and the beginning of a high-consequence threat landscape.
Since that watershed moment, Unit 42 has tracked an aggressive acceleration in the frequency and technical depth of supply chain compromises. Attacks have evolved from a series of isolated typosquatting incidents into systematic campaigns by various threat actors to weaponize the trust that powers modern software development.
We have seen two campaigns in April: the first started April 22, 2026 and included the string Shai-Hulud: The Third Coming. The second started April 29, 2026 and is known as Mini Shai-Hulud.
In May 2026, the Mini Shai-Hulud campaign continued with two new waves attributed to TeamPCP. These campaigns introduced two unique elements. One campaign used a credential-free initial access technique. The other campaign generated the highest single-hour package count of any Shai-Hulud worm to date. Copycat activity has made future attribution to TeamPCP more difficult.
A new supply chain attack on June 1, 2026 compromised at least 32 packages published under the @redhat-cloud-services npm namespace. The attacker bypassed code review entirely, pushing a payload named Miasma.
The Shai-Hulud incident proved that the npm registry could be used as a force multiplier for malware distribution. In the months following, we have observed three core shifts in adversary TTPs:
npm compromises have common themes. In the post-Shai-Hulud era, we believe it is helpful to consider the attack surface as a whole.
This article will combine:
A malicious npm package published as @bitwarden/cli version 2026.4.0 was identified as part of a broader supply-chain campaign attributed to TeamPCP. The package impersonates the legitimate Bitwarden command-line interface (CLI) password manager. Upon installation, it executes a multi-stage payload that steals credentials from cloud providers, CI/CD systems and developer workstations. It then self-propagates by backdooring every npm package the victim can publish. It has been noted that inside public GitHub repositories that were published contained the string “Shai-Hulud: The Third Coming.”
Attackers deployed the same payload across multiple Checkmarx distribution channels, indicating a coordinated campaign to weaponize compromised developer tooling credentials to maximize the area of impact:
Palo Alto Networks customers are better protected from the threats described in this article through the following products and services:
The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.
On June 1, 2026, a new supply chain attack compromised at least 32 packages published under the @redhat-cloud-services npm namespace, with the malicious versions cumulatively averaging approximately 80,000 weekly downloads. The root cause was a compromised Red Hat employee GitHub account, used to push malicious orphan commits to multiple RedHatInsights repositories, bypassing code review entirely.
The attacker triggered GitHub Actions workflows to request OpenID Connect (OIDC) tokens, publishing Trojanized packages with valid SLSA provenance. The certificate was accurate, the packages really were built by that pipeline. It just also happened to have malware injected into it at the time.
The payload is called Miasma. It is named after the description that the malware stamps on attacker-created GitHub repositories, "Miasma: The Spreading Blight." The threat is derived from the Mini Shai-Hulud malware open-sourced by TeamPCP on May 12, with substantially identical tradecraft.
The analyzed sample replaced a normal approximately 200 KB index.js with a 4.29 MB obfuscated payload. This is a 25x size increase that is itself a reliable detection signal.
Stolen credentials include:
Attribution remains uncertain. The TTPs are consistent with TeamPCP, but the public release of the Mini Shai-Hulud source code means any competent actor can replicate the same attack. What is certain is the trend, which is that one compromised account and one CI pipeline delivered 32 trojanized packages automatically to every developer who ran npm install. Then the registry does the rest.
Two further waves in May 2026 continued the Mini Shai-Hulud campaign:
Both are attributed to TeamPCP, though the public release of the worm's source code on May 12 has already spawned separate copycat activity, complicating future attribution.
On May 11, TeamPCP launched a coordinated supply chain attack across the npm and PyPI ecosystems. The initial vector was TanStack's GitHub Actions CI pipeline. Within six minutes, 84 malicious package artifacts were published across 42 @tanstack/* packages.
The worm's self-propagation mechanism then expanded rapidly. By end of day, we had documented 373 malicious versions across 169 npm packages plus compromised PyPI packages.
The affected scope went well beyond TanStack. The worm's self-propagation spread the compromise to packages across multiple industries and ecosystems:
@tanstack/react-router alone receives over 12.7 million weekly downloads. We estimate 520 million cumulative downloads were in the affected window. Palo Alto Networks provides XDR and XQL queries to detect this activity.
Every prior Shai-Hulud wave began with a stolen or phished credential. The TanStack attack needed neither. Instead, three GitHub Actions weaknesses were chained, none of which was sufficient alone.
On May 10, the attacker created a fork of TanStack/router under the account zblgg/configuration, deliberately named to avoid appearing in fork-list searches. A malicious commit was authored under the spoofed identity claude <claude@users.noreply.github.com>, impersonating the Anthropic Claude GitHub App, and prefixed [skip ci] to suppress automated CI on push.
A pull request (PR #7378) against TanStack/router#main then triggered bundle-size.yml — a workflow that used the pull_request_target trigger and checked out the fork's merge ref. This gave the fork's code execution in the base repository's runner context, with full access to its cache scope.
The threat actors used Bun, which is a lightweight JavaScript runtime and package manager alternative to Node.js and npm as shown in Figure 1. The attack used Bun to execute the malicious payload tanstack_runner.js. This in turn attempted to enumerate the system for sensitive credentials, including invoking the GitHub CLI to capture the GitHub authentication token (gh auth token).
In a Linux-hosted Kubernetes environment, Unit 42 observed legitimate runc create container activity associated with a build pipeline that subsequently retrieved and executed the compromised JavaScript package. The runc create invocation itself was legitimate Kubernetes runtime activity associated with the containerized build process.
During the build:
The process lineage is shown in Figure 2.
The fork's code wrote a 1.1 GB poisoned pnpm store under the exact cache key that release.yml would later look up. The key was pre-computed from the public pnpm-lock.yaml using the same hashFiles() formula the workflow uses. The poisoned cache entry then sat dormant for eight hours.
A critical detail: actions/cache@v5's post-job save uses a runner-internal token, not the workflow GITHUB_TOKEN, so setting permissions: contents: read on the workflow does not prevent the cache write.
When a legitimate maintainer pushed to main, release.yml triggered, restored the poisoned cache and executed attacker-controlled binaries during the build phase. Those binaries read /proc/<Runner.Worker>/mem and extracted the OIDC token — minted lazily in runner memory only when id-token: write is set — then POSTed it directly to registry.npmjs.org.
The workflow's own Publish Packages step was never reached; tests failed and that step was skipped. npm received 84 valid, signed, provenance-attested package publishes anyway.
This is the same /proc-memory extraction technique documented in the tj-actions/changed-files compromise of March 2025 and reused in the April 2026 SAP and Bitwarden waves.
This is the first documented case of a worm publishing malicious npm packages with valid SLSA Build Level 3 provenance. Sigstore correctly attested that the packages were built by release.yml from refs/heads/main of TanStack/router — because they were. SLSA provenance confirms which pipeline built a package, not whether that pipeline's internal state was clean.
The root cause is the same OIDC trust-scope misconfiguration exploited in the April 29 @cap-js wave. The trusted-publisher binding trusted the entire repository rather than a specific workflow on a protected branch.
Provenance verification is necessary but no longer sufficient. This is why behavioral analysis at install time is essential.
The malicious payload, router_init.js (2.3 MB obfuscated), was not delivered via a preinstall hook on the compromised packages themselves. Instead, each tarball received an injected optionalDependencies entry pointing to an orphaned commit in the attacker's fork.
This is a commit that GitHub surfaces under the legitimate TanStack/router URL due to shared fork-network commit object storage:
"optionalDependencies": { "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c" } |
The dependency is designed to fail silently during installation. The malicious code executes in the background while the install process appears normal, leaving near-zero trace in logs. The payload uses multiple layers of obfuscation and encryption to resist automated analysis. It shares the same custom cipher documented in the April 22 Bitwarden and April 29 SAP sections, confirming shared authorship across all three waves.
For secondary victims infected via worm propagation (e.g., UiPath, Mistral AI and OpenSearch), the delivery mechanism reverted to the familiar preinstall hook from the April SAP wave.
The pattern is now well-established. Once the worm gains a foothold in one ecosystem, it uses stolen credentials to republish itself into every other package the victim maintains, rapidly expanding its reach across unrelated projects and organizations.
The May 11 payload installs a persistent background service that polls api.github.com/user with the stolen GitHub token every 60 seconds. If the token is revoked (HTTP 40x), the service executes rm -rf ~/ — destroying the user's home directory. The daemon auto-exits after 24 hours.
On the evening of May 12, 2026, the fully weaponized Mini Shai-Hulud source code was published to public GitHub repositories before being taken down. The toolchain including the CI cache-poisoning scripts, OIDC token extractor and the credential stealer with its propagation logic is now publicly available.
Mini Shai-Hulud is no longer scoped to TeamPCP. Future incidents using this toolchain may not share TeamPCP's infrastructure or tradecraft and should not be attributed solely on the basis of worm lineage.
On May 19, 2026, the npm maintainer account atool was compromised as part of a new Mini Shai-Hulud wave. In approximately one hour, 639 malicious package versions were published across 323 unique packages. This is the largest single-hour package count of any Shai-Hulud wave to date.
The affected scope spans the @antv data visualization ecosystem and related libraries:
The potential area of impact across data visualization, graphing, mapping, charting and React component ecosystems is significant.
Unlike the TanStack wave's pipeline-hijack technique, this wave returns to a simpler model. This involves compromising a maintainer account and using it to republish packages directly. This is the same approach seen in the September and November 2025 campaigns.
The attacker modified each package's package.json in three ways:
To ensure the malicious versions reached as many targets as possible, the attacker also bumped version numbers beyond the latest legitimate release (e.g., @antv/s2-vue jumped from the real version 2.2.0 to 2.4.0). Any project using a permissive version range like ^2.x would automatically pull the malicious version on its next install.
The 499 KB obfuscated payload runs six credential collectors in parallel, sweeping a broad range of targets:
All stolen data is encrypted and sent to a C2 endpoint disguised as OpenTelemetry trace ingestion (t.m-kosche[.]com), meaning network monitoring tools may classify the traffic as legitimate observability telemetry.
A fallback channel exfiltrates data to GitHub repositories created under the victim's account, using Dune-themed names and the reversed campaign marker Shai-Hulud: Here We Go Again as the description.
As of April 29, 2026, a new supply chain attack wave (dubbed Mini Shai-Hulud) is actively targeting the SAP developer ecosystem via four compromised npm packages.
The affected versions are:
Combined, these packages carry approximately 570,000 weekly downloads, with @cap-js/sqlite and @cap-js/db-service each pulling around 250,000 and 260,000 downloads, respectively.
All four packages are part of SAP's Cloud Application Programming (CAP) Model and multitarget application (MTA) build toolchain. This makes the targets of this attack enterprise developers and CI/CD pipelines with access to cloud credentials, GitHub tokens and deployment secrets.
The campaign is a close structural continuation of the @bitwarden/cli@2026.4.0 compromise earlier in April 2026. It uses the same toolchain, same obfuscation and same propagation logic, which is now turned against the SAP ecosystem.
Each compromised package received two new files:
These files arrived along with a modified package.json that adds a preinstall lifecycle hook ("preinstall": "node setup.mjs"). This means the malicious code executes automatically during the npm install process, before the installation is complete. The setup.mjs bootstrapper detects the host OS and architecture, then performs the following activities:
The 11.7 MB single-file, obfuscated credential stealer, execution.js, is a propagation framework. It performs the following activities:
It harvests the following information:
A particularly aggressive CI path uses an embedded Python helper that reads the /proc memory of the GitHub Actions Runner.Worker process to extract masked secret values.
All collected data is:
The campaign uses GitHub's public commit search API as a covert command and control (C2) channel. The malware performs the following activities:
Once a usable token is obtained, the payload:
The malware also pushes the following files directly into victim repositories:
The malware pushes the above files using commits authored as claude <claude@users.noreply.github.com> with the message chore: update dependencies.
The three forensic links to @bitwarden/cli@2026.4.0 are precise enough to indicate shared authorship or a directly reused toolchain.
1. The setup.mjs preinstall bootstrapper. In the Bitwarden campaign, setup.mjs was the self-replication artifact the worm (bw1.js) injected into every npm package the victim could publish. The SAP packages use that same filename as their bootstrapper, and the two share clear common lineage: same Bun version (1.3.13), same Alpine/musl detection logic and the same redirect-following download approach.
2. The decodeScramble / ctf-scramble-v2 obfuscation method. The Bitwarden payload encodes all sensitive strings using a custom seeded ASCII shuffle cipher. This is a Fisher-Yates shuffle over a 128-character ASCII table driven by a linear congruential PRNG seeded with 0x3039 (12345). The SAP execution.js uses a layer explicitly labeled ctf-scramble-v2, which is the same deterministic substitution scheme. This is not a library, it is a bespoke implementation. It is reused across both payloads.
3. The GitHub commit dead-drop pattern. The Bitwarden malware used GitHub's public commit search API as a covert C2 channel. It embedded stolen tokens in commit messages matching LongLiveTheResistanceAgainstMachines:<base64> and used them to bootstrap new exfiltration channels without attacker-controlled infrastructure.
This wave applies the exact same pattern under a new keyword (OhNoWhatsGoingOnWithGitHub) with matching commit messages decoded as a token dead-drop. The mechanism is identical in implementation:
Rotating the keyword while keeping the technique intact is a hallmark of the same operator updating a reused codebase.
According to Checkmarx's official security update, this npm package is one component of a broader supply-chain campaign that simultaneously compromised multiple Checkmarx distribution channels:
Per Checkmarx's disclosure, all artifacts share the same C2 infrastructure (audit.checkmarx[.]cx), the same obfuscation techniques and the same credential harvesting and propagation logic. The VS Code extension variant delivered its payload (mcpAddon.js) from a backdated orphan commit in Checkmarx's own GitHub repository, making the download URL appear trustworthy.
TeamPCP (@pcpcats) publicly took credit for the compromise. Per Socket's analysis, the group had previously targeted Checkmarx infrastructure in March 2026, along with Trivy and LiteLLM, suggesting an ongoing campaign against security tooling vendors.
Table 1 shows the attributes of the attack.
| Attribute | Detail |
| Package | @bitwarden/cli@2026.4.0 |
| Trigger | preinstall lifecycle script |
| Runtime | Bun v1.3.13 (downloaded during install) |
| C2 server | audit.checkmarx[.]cx:443 (94.154.172[.]43) |
| C2 path | /v1/telemetry |
| Fallback C2 | Dynamic, fetched via GitHub Search API dead drop |
| Exfiltration | HTTPS POST (encrypted) + GitHub public repos |
| Attribution | TeamPCP (@pcpcats) |
Table 1. Attributes of the attack.
The Bitwarden security team provided the following information. They identified and contained the malicious package described in Table 1, which was briefly distributed through the npm delivery path for @bitwarden/cli@2026.4.0 between 5:57 PM and 7:30 PM EST on April 22, 2026, in connection with the broader supply chain incident.
Their investigation found no evidence that end user vault data was accessed or at risk, or that production data or production systems were compromised. Once the issue was detected, they:
The issue affected the npm distribution mechanism for the CLI during that limited window, not the integrity of the legitimate Bitwarden CLI codebase or stored vault data.
People who did not download the package from npm during that window were not affected. Bitwarden completed a review of internal environments, release paths and related systems. They found no additional impacted products or environments at this time.
A CVE for Bitwarden CLI version 2026.4.0 is being issued in connection with this incident.
The package.json provides two execution paths for the malicious script, as shown in Figure 3.
The preinstall hook runs automatically during npm install. The bin field registers bw_setup.js as the bw command, symlinking it into the user's PATH.
Since the legitimate Bitwarden CLI also uses bw as its binary name, this serves as a secondary trigger. Even if preinstall is blocked (e.g., via --ignore-scripts), the malware executes the next time the user or any script invokes bw. The shebang line #!/usr/bin/env node at the top of bw_setup.js ensures it runs as a Node.js script when called directly.
The bootstrap script performs three actions:
A custom ZIP extraction implementation is included to avoid any dependencies, making the bootstrap entirely self-contained.
The payload is an approximately 10 MB single-line JavaScript file containing approximately 285,000 lines when formatted. It bundles legitimate software developer kits (SDKs) (e.g., AWS SDK, Google Cloud client libraries, Azure Identity, Octokit, jsonwebtoken, tar) alongside the malicious orchestration code.
The code employs multiple layers of obfuscation:
The 128-character ASCII set is shuffled deterministically, producing a substitution table where an index with the hex value 0x42 maps to the ASCII character a, 0x6e to u. For example, the C2 domain is stored as [0x42, 0x6e, 0x36, 0x4b, 0x2b, 0x5c, 0xd, 0x57, 0x0, 0xd, 0x7, 0x26, 0x42, 0x3, 0x2a, 0x5c, 0xd, 0x2a], which decodes to an ASCII string for the domain audit.checkmarx[.]cx.
The payload deploys multiple provider classes, each targeting a different credential source. Every provider scans its results with regex patterns to extract npm and GitHub tokens, as shown in Figure 5.
Reads sensitive files from the developer's workstation, with per-OS path lists decoded via the scrambler as shown below in Table 2.
| Platform | Targeted Files |
| Linux | ~/.ssh/id_*, ~/.ssh/keys, .git/config, ~/.npmrc, .npmrc, .env, ~/.claude/mcp.json, ~/.claude.json, ~/.kiro/settings/mcp.json |
| macOS | ~/.aws/credentials, .git/config, ~/.npmrc, .npmrc, .env, ~/.claude.json, .claude.json, ~/.kiro/settings/mcp.json, .kiro/settings/mcp.json |
| Windows | Credential store paths, config.ini |
Table 2. OS path lists from the malware.
Files larger than approximately 5 MB are skipped. All others are read in full and included in the exfiltration payload.
Runs gh auth token via execSync to capture the GitHub CLI's active token, and then harvests the full process.env environment block. Both are returned for token-regex scanning and exfiltration. Unlike the cloud providers below, the Shell Provider does not use any SDK — it relies solely on the single shell command and environment variables.
Detects CI/CD environments via process.env.GITHUB_ACTIONS === "true" and extracts all configured secrets by parsing {"value":"...","isSecret":true} patterns from the Actions runner context.
Uses the bundled AWS SDK (SSMClient, DescribeParameters, GetParameter) to enumerate and read parameters from AWS Systems Manager Parameter Store.
Uses Azure Identity and Key Vault SDK to call getSecretsFromVault, listing and reading secrets from all accessible vaults.
Uses the Google Cloud Secret Manager client to listSecrets and accessSecretVersion, reading all accessible secrets across projects.
All harvested credentials are processed through a two-tier exfiltration system.
Using stolen GitHub tokens, the malware:
This dual exfiltration ensures data reaches the attacker even if the C2 domain is blocked.
When the malware obtains a GitHub token with repo and workflow scopes, class u_ validates the scopes and then:
This is the self-replicating component. When the malware finds an npm token (npm_...):
Calls the npm tokens API with Authorization: Bearer <token>, verifies the token has publish (write) permission on the package scope and that it bypasses two-factor authentication (2FA).
Using the validated token:
For each target package:
Writes a .npmrc with the stolen token's auth line (//registry.npmjs[.]org/:_authToken=<token>) and runs bun publish <tarball>.
Every newly infected package will trigger the same preinstall chain on any developer who installs it, creating an exponential propagation vector.
The malware implements a fall back mechanism for C2 resilience using GitHub's public search API as a covert command channel.
If the primary C2 server (audit.checkmarx[.]cx) is unreachable, the malware:
At the time of analysis, the dead drop contained a placeholder value (hxxps[:]//example[.]com), indicating it was pre-staged for future use. The attacker can rotate C2 infrastructure at any time by creating a new signed commit on any public GitHub repository.
A second fall back (Hr function) searches for commits matching LongLiveTheResistanceAgainstMachines:<base64> to recover previously stolen GitHub tokens from exfiltration repos, bootstrapping new GitHub-based exfiltration channels without any attacker-controlled infrastructure.
The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit this CVE across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation.
The following XQL query has been used to successfully identify execution of a JavaScript file through Bun that subsequently calls the GitHub CLI in a likely attempt to collect locally stored authentication tokens. While Bun is legitimate in many developer environments, its use as a runtime for package install malware in this campaign makes this behavior worth investigating when observed with credential access commands such as gh auth token:
// Title: Mini Shai-Hulud antv package compromise malicious package installation and persistence // Description: Identifies the Mini Shai-Hulud installation activity at various stages involved in the antv npm package compromise. // MITRE ATT&CK TTP ID: T1195.001 config case_sensitive = false | dataset = xdr_data | fields agent_hostname, event_id, actor_effective_username, actor_process_image_command_line, actor_process_image_path, actor_process_image_sha256, action_file_sha256, action_file_path, action_file_name, action_process_image_command_line, action_process_image_path, action_process_image_name, event_type, event_sub_type, action_external_hostname | filter event_type in (ENUM.FILE, ENUM.NETWORK) and (action_file_path ~= "(?:\/tmp\/kitty\-[A-Za-z0-9]{6}\/.\.py|\.local\/share\/kitty\/cat\.py)" or (actor_process_image_path ~= "\.npm\/_npx\/[0-9a-f]{16}\/node_modules\/bun\/bin\/bun.exe" and (action_file_path ~= "\.npm\/_npx\/[0-9a-f]{16}\/node_modules\/nx\-next\/index\.js" or action_external_hostname ~= "(?:t\.m\-kosche\.com|api\.github\.com)"))) |
Unit 42 has witnessed a shift since the September 2025 Shai-Hulud incident, proving that it wasn’t a temporary spike but the new baseline for software supply chain risk. In an ecosystem where code is shared at the speed of thought, a single compromised dependency can trigger a global cascade.
Ultimately, npm compromises share commonalities and organizations can navigate this volatility by keeping particular best practices in mind. As we continue to monitor, analyze and update our findings related to npm packages, we encourage you to move beyond static defenses and embrace a culture of continuous verification. The supply chain may be the new primary target, but with collective intelligence and relentless visibility, it doesn’t have to be the primary vulnerability.
Palo Alto Networks customers are better protected by our products, as listed below. We will update this threat brief as more relevant information becomes available.
Implement a policy (via a private registry or proxy like Artifactory) that blocks any package version published within the last 24 to 72 hours. Most malicious packages are identified and removed from the public registry within this window.
Many compromises rely on preinstall or postinstall hooks to exfiltrate secrets. Use the following in your .npmrc: ignore-scripts=true.
Use package-lock.json and ensure your CI/CD pipelines use npm ci instead of npm install. This prevents the "hidden" update of dependencies during a build.
Never allow developer machines or CI runners to talk directly to registry.npmjs[.]org. Route all traffic through a private registry.
Attackers often publish packages with the same name as your internal libraries to the public registry. Always use scoped packages (e.g., @myorg/internal-lib) and configure your private registry to only resolve that scope internally.
Verify the OpenID Connect Attestation. Many major packages provide "provenance," proving the code was built on a specific GitHub/GitLab runner. Use tools like slsa-verifier to check these during the build.
Most npm-based malware attempts to send ~/.npmrc tokens or ~/.ssh keys to a C2 server. Apply strict egress network policies to your CI runners. Only allow connections to your private registry and known deployment targets.
Automatically generate an SBOM for every production release. This allows your security team to perform instant impact analysis when a new zero-day is announced.
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of indicators associated with npm compromises, including the malicious Bitwarden package.
Advanced URL Filtering and Advanced DNS Security identify known domains and IP addresses associated with this activity as malicious.
Cortex Cloud’s Application Security Module (ASPM) supports the scanning of npm packages installed on cloud resources as well as monitoring audit logs from third party SaaS vendors, including GitHub as discussed within this article. Cortex Cloud prioritizes alerts, issues, policies and assets based on ingested applications as well as their usage. This allows security teams to maintain security awareness across their on-premises and cloud environment by identifying and remediating impacted cloud resources and actively responding to associated runtime operations from the threats discussed within this article through Cortex Cloud’s XDR Agent and serverless operations. For additional details about how to protect against this threat using Cortex Cloud, please see their blog.
Koi Agentic Endpoint Security allows customers to delay automatic updates for all installed packages by a set time window, allowing newly pushed versions to establish reputation and undergo public scrutiny before being deployed in your environment.
Table 3 lists the network indicators from this activity.
| Indicator | Type |
| audit.checkmarx[.]cx | C2 domain |
| 94.154.172[.]43 | C2 IP address |
| checkmarx[.]cx | Attacker-controlled domain |
| 91.195.240[.]123 | Attacker IP address |
Table 3. Network indicators.
Table 4 lists the GitHub indicators from this activity.
| Indicator | Type |
| helloworm00/hello-world | Dead drop repository |
| bc544f455d7c06c8a1f3446160a6d9a4a8236b11 | Dead drop commit SHA1 hash |
| helloworm00@proton[.]me | Attacker email address |
| Commit messages matching LongLiveTheResistanceAgainstMachines:* | Exfiltration staging |
| Public repositories named <dune-word>-<dune-word>-<3digits> with description "Checkmarx Configuration Storage" | Exfiltration repositories |
Table 4. GitHub indicators.
Table 5 lists the file and process indicators from this activity.
| Indicator | Type | SHA256 hash |
| bw_setup.js | Bootstrap script | f35475829991b303c5efc2ee0f343dd38f8614e8b5e69db683923135f85cf60d |
| bw1.js | Obfuscated payload | 18f784b3bc9a0bcdcb1a8d7f51bc5f54323fc40cbd874119354ab609bef6e4cb |
| package.json | Malicious manifest | 167ce57ef59a32a6a0ef4137785828077879092d7f83ddbc1755d6e69116e0ad |
| setup.mjs in infected packages | Worm payload | |
| Unexpected bun process execution | Runtime indicator | |
| .github/workflows/format-check.yml on transient branches | Workflow injection | |
| format-results workflow artifact | Secret exfiltration |
Table 5. File and process indicators.
Table 6 lists the npm indicators from this activity.
| Indicator | Type |
| @bitwarden/cli@2026.4.0 | Malicious package |
| New preinstall: "node setup.mjs" in package.json | Injected hook |
Table 6. npm indicators.
| Affected Package | Versions |
|---|---|
| @redhat-cloud-services/chrome | 2.3.1, 2.3.2 |
| @redhat-cloud-services/compliance-client | 4.0.3, 4.0.4, 4.0.6 |
| @redhat-cloud-services/config-manager-client | 5.0.4, 5.0.5, 5.0.7 |
| @redhat-cloud-services/entitlements-client | 4.0.11, 4.0.12, 4.0.14 |
| @redhat-cloud-services/eslint-config-redhat-cloud-services | 3.2.1, 3.2.2, 3.2.4 |
| @redhat-cloud-services/frontend-components | 7.7.2, 7.7.3, 7.7.5 |
| @redhat-cloud-services/frontend-components-advisor-components | 3.8.2, 3.8.4, 3.8.6 |
| @redhat-cloud-services/frontend-components-config | 6.11.3, 6.11.4, 6.11.6 |
| @redhat-cloud-services/frontend-components-config-utilities | 4.11.2, 4.11.3, 4.11.5 |
| @redhat-cloud-services/frontend-components-notifications | 6.9.2, 6.9.3 |
| @redhat-cloud-services/frontend-components-remediations | 4.9.2, 4.9.3, 4.9.5 |
| @redhat-cloud-services/frontend-components-testing | 1.2.1, 1.2.2, 1.2.4 |
| @redhat-cloud-services/frontend-components-translations | 4.4.1, 4.4.2 |
| @redhat-cloud-services/frontend-components-utilities | 7.4.1, 7.4.2, 7.4.4 |
| @redhat-cloud-services/hcc-feo-mcp | 0.3.1, 0.3.2, 0.3.4 |
| @redhat-cloud-services/hcc-kessel-mcp | 0.3.1, 0.3.2, 0.3.4 |
| @redhat-cloud-services/hcc-pf-mcp | 0.6.1, 0.6.2, 0.6.4 |
| @redhat-cloud-services/host-inventory-client | 5.0.3, 5.0.4, 5.0.6 |
| @redhat-cloud-services/insights-client | 4.0.4, 4.0.5, 4.0.7 |
| @redhat-cloud-services/integrations-client | 6.0.4, 6.0.5, 6.0.7 |
| @redhat-cloud-services/javascript-clients-shared | 2.0.8, 2.0.9, 2.0.11 |
| @redhat-cloud-services/notifications-client | 6.1.4, 6.1.5, 6.1.7 |
| @redhat-cloud-services/patch-client | 4.0.4, 4.0.5, 4.0.7 |
| @redhat-cloud-services/quickstarts-client | 4.0.11, 4.0.12, 4.0.14 |
| @redhat-cloud-services/rbac-client | 9.0.3, 9.0.4, 9.0.6 |
| @redhat-cloud-services/remediations-client | 4.0.4, 4.0.5, 4.0.7 |
| @redhat-cloud-services/rule-components | 4.7.2, 4.7.3 |
| @redhat-cloud-services/sources-client | 3.0.10, 3.0.11, 3.0.13 |
| @redhat-cloud-services/topological-inventory-client | 3.0.10, 3.0.11, 3.0.13 |
| @redhat-cloud-services/tsc-transform-imports | 1.2.2, 1.2.4, 1.2.6 |
| @redhat-cloud-services/types | 3.6.1, 3.6.2, 3.6.4 |
| @redhat-cloud-services/vulnerabilities-client | 2.1.8, 2.1.9, 2.1.11 |
Updated April 27, 2026 at 2:15 p.m. PT to add information about Bitwarden and link to the Cortex Cloud article in the Additional References section.
Updated May 1, 2026 at 4:55 p.m. PT to add information on the Mini Shai-Hulud campaign.
Updated May 20, 2026 at 12:30 p.m. PT to update the Executive Summary with information on two new waves and add a new section on Mini-Shai Hulud May 2026 waves.
Updated May 21, 2026 at 8:45 a.m. PT to add managed threat hunting queries and additional product protection information.
Updated June 2, 2026 at 11:22 a.m. PT to add section on the Red Hat supply chain attack. Added affected packages in the Indicators of Compromise section.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。