StepSecurity's blog reports on software supply chain attacks, including compromised GitHub Actions and npm packages.
HN links it for reports on incidents such as Shai-Hulud variants, compromised npm packages, and worms that plant AI coding agent config files.
We (StepSecurity) published a full analysis of both payload stages: https://www.stepsecurity.io/blog/chaindrop-npm-worm
Some additional detail from our analysis:
1. Provenance did not fail, it worked as designed and still shipped malware. The initial 11 packages were published through npm OIDC Trusted Publishing with valid SLSA attestations. The attacker compromised the maintainer's GitHub account and let the projects' own release workflows publish. Provenance proves which commit was built, not that the commit was authorized.
2. There is a booby trap on remediation: the worm installs a watcher that fires an attacker payload when the stolen GitHub token gets revoked. Remove the token monitor first, then rotate.
3. Persistence goes beyond node_modules. It writes .claude/settings.json (SessionStart hook) and .vscode/tasks.json (runOn: folderOpen), each re-executing the dropper. Check repo dotfiles too.
4. No C2 domain to sinkhole: exfil endpoints resolve at runtime from an Ethereum contract. Observed domain is npm-cache.com, but the operator can rotate it and push new code to infected hosts.
If you're auditing: look for setup.mjs, a 727,680 byte Math_Symbol.js (math_init.js in the second wave), and "preinstall": "node setup.mjs" in package.json. Careful, regenerate-unicode-properties ships a legitimate 1 KB Math_Symbol.js; the malicious one is over 700 KB.
Full IOC and package list in the post, updated as the campaign develops.
No, the reference to May 19 in the article is about a previous supply chain attack against AntV (https://www.stepsecurity.io/blog/shai-hulud-here-we-go-again-mass-npm-supply-chain-attack-hits-the-antv-ecosystem). I think there may be some copy-paste mistakes where they reused part of that previous article and didn't contextualize it correctly.
The npm package `@redhat-cloud-services/chrome` version 2.3.1, which was part of this current supply chain attack, was published on June 1. The malicious package version is no longer listed on npmjs.com's web UI since it was taken down, but the publish date of 2.3.1 can still be seen in https://registry.npmjs.org/@redhat-cloud-services/chrome by searching for the version number there, and the publish date was 2026-06-01T10:54:42.121Z.
I find the article extremely annoying for not having a clear timeline of when these malicious package versions were available.
> This is why I avoid using non-official actions where possible and always set a version for the action.
Those are good practices. I would add that pinning the version (tag) is not enough, as we learnt with the tj-actions/changed-files event. We should pin the commit sha.[0]. Github states this in their official documentation [1] as well:
> Pin actions to a full length commit SHA
> Pin actions to a tag only if you trust the creator
[0] https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised#recovery-steps
[1] https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions
https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-again-azure-functions-action-and-72-other-repositories-disabled-after-supply-chain-attack-targeting-ai-coding-agents mentions that it plants `.claude/settings.json`, `.gemini/settings.json`, `.cursor/rules/setup.mdc`, and `.vscode/tasks.json` to execute its payload as a setup task.
VSCode will be used by plenty of non-AI-using developers, and the credential harvester is not specific to AI API tokens, but that 3/4 of the targets are AI coding tools is I assume where the claim comes from.
Please, someone explain how it's possible to add obfuscated file to so many repositories? Do they don't have any code reviews?
Also, the title is misleading, setup adds config to be auto executed by people who work on the repo. They would have to use vscode/cursor/claude/gemini. People who use codex / opencode / other harnesses are safe I guess.
Details: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-again-azure-functions-action-and-72-other-repositories-disabled-after-supply-chain-attack-targeting-ai-coding-agents
Thread on the post from main rust blog: https://news.ycombinator.com/item?id=49372853
Direct post link: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/
Initial report: https://github.com/rustsec/advisory-db/issues/3161
Other vendor posts:
* https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-chain-attack
* https://research.jfrog.com/post/arrayref-proc-macro1-crates-io/
* https://www.aikido.dev/blog/two-popular-rust-crates-arrayref-and-append-only-vec-compromised-in-supply-chain-attack