Breaking News: The Python package Lightning and the NPM package intercom-client were infected by the recent wave of Shai-Hulud-related attacks, stealing credentials, API keys, and spreading itself across the Python & NPM ecosystems.
Affected Packages
Currently 2.6.2 and 2.6.3 are quarantined. Revert to 2.6.1 or lower.
| Package name | Affected versions | Fixed versions |
| lightning | 2.6.2, 2.6.3 | <=2.6.1 |
| intercom-client (npm) | 7.0.4 | <=7.0.3 |
Overview
The Python package lightning was infected by a new Shai-Hulud variant uploaded to PyPI. The variant transforms from running Python to running JavaScript, and deploys the same infostealer logic seen in recent Shai-Hulud-related attacks.
Another package was affected as well during the incident – intercom-client (npm).
Who is Affected
Anyone who installed the “Lightning” Python package versions 2.6.2 or 2.6.3 is affected, as is anyone who installed intercom-client version 7.0.4.
Impact
- Lightning has over 8.3M monthly downloads, and 2.1M weekly downloads
- intercom-client has over 1.3M monthly downloads, and 300K weekly downloads.
- Number of public repositories with stolen credentials on GitHub rose from 1,200 to 1,800 between the SAP and the lightning incidents
Recommended Actions
Immediate Actions:
- Rotate your keys and add 2FA to your accounts
- Check for public GitHub repositories containing “Shai-Hulud” related strings
- Downgrade the Lightning package to 2.6.1 or below
- Treat the machine and any connected token, environment variable and API key as compromised
Infection Analysis
OX Security identified over 1,800 repositories created by the attacker containing stolen developer credentials – a combined total following the recent attack on the SAP NPM packages.
Repositories containing exfiltrated data on GitHub can be identified by the string “A Mini Shai-Hulud has Appeared” in the repository description.
Technical Analysis
This sample is a Node/Bun supply-chain tool, not a single “one URL beacon.” It:
- Collects secrets from the environment using several scanners (GitHub Actions-oriented flows, npm tokens, etc.). Regexes include npm_… and ghp_ / gho_ / ghs_… GitHub tokens.
- Exfiltrates collector output in batches over HTTPS to an obfuscated host and path (Iy(“…”) decoding), via a Gq “sender” pipeline wired into Aq.dispatch (flush when the buffer exceeds ~100 KB).
- Uses valid npm tokens against registry.npmjs.org to resolve the account, enumerate packages the token can write to, then download, patch, and republish tarballs – so sensitive material and package metadata are sent to npm, and the trojanized artifact is published there, not only “to attacker.”
- Uses GitHub tokens with Octokit to (a) validate scopes and, when workflow scope exists, harvest GitHub Actions–related material into results returned as scanner success; (b) optionally run _G to push attacker-controlled files (e.g. .vscode, .claude paths) to many branches via GraphQL “commit on branch” style APIs – writing into repos as well as reading/exfiltrating where the workflow collector applies.
“Exfiltrates” includes: tokens and derived metadata → operator HTTPS endpoint; npm token + package list + publish payloads → npm; GitHub Actions harvest → collector batch → same operator path; malicious repo content → GitHub.
The malware builds a remote endpoint (domain/path from decoded blobs, port 443), instantiates sender objects (cEf, REf), and hooks the collector’s dispatch to Gq.dispatch. Scanner results buffered in Aq are flushed to that infrastructure once the batch is large enough – this is the primary exfil channel for collected payloads (not the literal token strings in this block; those appear inside the batched objects produced by scanners).
As shown in the image above, the exfiltration domain is obfuscated. We deobfuscated it and determined that the data is being exfiltrated to: https://zero[.]masscan[.]cloud:443/v1/telemetry
Looking into this part of the malware:
Decoding that blob with the same scheme as C2 yields exactly: A Mini Shai-Hulud has Appeared.
Any scan hit with matches.npmtoken is handled immediately: tokens are passed to l4f (registry validation/enumeration) and the structured result is logged and fed to Iq.execute for download/republish. The same ingest path also buffers the full scan result object for flush → dispatch, so npm-related findings can also be exfiltrated in bulk to the operator, not only used locally.
With a bearer npm_ token, the code calls /-/whoami, org/package APIs, and maintainer search on registry.npmjs.org. The returned object { packages, valid, authToken } is exactly what gets logged and drives Iq – so username, package names, and the live token are the sensitive payload (operator logs + later batch exfil + abuse toward npm).
This scanner is tied to the github/actions surface. It looks for ghp_/gho_-style PATs (and npm_ in the same pattern table). After GET /user, it checks OAuth scopes; if workflow is present, it streams O6f(this[“ghClient”]) and returns success({ results }) – Actions-oriented material (the code path labels it as secrets collection) is packaged as results for the collector → dispatch path, i.e. exfiltration of GitHub-side findings to the operator-controlled HTTPS sink, alongside whatever else was buffered.
Conclusion
Recent waves of Shai-Hulud malware continue to spread across popular package managers, as discussed in our previous report on the SAP Shai-Hulud malware variant. The recent flood of supply chain attacks should raise a red flag for security teams around the world — and especially for PyPI and npm, the ability to detect and prevent malicious packages before they are served should be a top priority, in order to protect users from attacks that are becoming more frequent every day.
)
