Detailed write-ups
Mini Shai-Hulud: a second self-replicating npm worm hits @antv (May 20)
Microsoft Threat Intelligence detailed the May 19 npm wave that began at 01:56 UTC and ran for exactly one hour: a compromised maintainer account on the popular @antv visualization library family pushed 639 malicious versions across 323 unique packages. The marker string — “Shai-Hulud: Here We Go Again” — confirms this is a follow-on to the 2024 Shai-Hulud worm, with the same self-propagation pattern: once installed, the package uses harvested npm tokens to publish itself further into the maintainer’s other packages.
The clever (and concerning) wrinkle: the malicious versions generate cryptographically valid Sigstore provenance attestations. The familiar green “verified” badge appears on npm. Provenance attests that the package was built in a trusted workflow — not that the workflow was uncompromised. The attack also exfiltrates GitHub Actions secrets, AWS keys, npm tokens, and any other environment variables the build environment had access to, then uses them to extend the worm’s reach.
What to do this week: block @antv/* versions published between 01:56 and 02:56 UTC May 19, 2026 in your registry; rotate any npm publish token, GitHub token, AWS key, or cloud credential that may have touched a build using those packages; treat provenance attestations as one signal of many, not as proof of safety; subscribe to your registry’s rapid-response advisory feed if you haven’t.
Sources: Microsoft Security Blog
Compromised Nx Console v18.95.0 weaponizes VS Code against developers (May 19)
On May 18, attackers published Nx Console version 18.95.0 to the VS Code Marketplace — an extension with 2.2 million installs across professional developer machines. The release carried a 498KB obfuscated payload that fetched its second stage from a dangling orphan commit in the legitimate nrwl/nx GitHub repository, neatly bypassing repo-monitoring tools that only watch reachable refs.
The credential harvester is targeted at the modern AI-augmented developer: 1Password vaults, Claude Code (Anthropic) configuration files, npm tokens, GitHub credentials, AWS profiles, SSH keys, and browser-stored cloud-provider credentials. The campaign is linked to TeamPCP — the same actor cluster behind the May 11 TanStack npm compromise that subsequently led to the Grafana codebase exfiltration (see next story). VS Code extensions, like browser extensions, have effectively full read access to anything the developer can read; this attack is a direct demonstration of why “trusted developer tools” is increasingly an oxymoron.
What to do this week: audit installed VS Code (and JetBrains, Cursor, Windsurf) extensions on developer machines; pin extensions to known-good versions or require a security review before auto-update; treat ~/.config/Claude, 1Password CLI tokens, and IDE-stored credentials as high-value secrets that need short rotation; consider moving credentials out of files and into hardware-backed agents (1Password CLI biometric unlock, GitHub Codespaces ephemeral creds, AWS SSO) where possible.
Sources: The Hacker News
Grafana confirms full codebase exfiltration via missed token rotation (May 18)
Grafana Labs publicly confirmed that attackers downloaded its source code via a GitHub workflow token leaked during the May 11 TanStack/TeamPCP npm supply-chain compromise. The token should have been rotated when TanStack disclosed the breach — it wasn’t. On May 16, the CoinbaseCartel data-theft group claimed the haul and attempted extortion. Grafana refused to pay and chose disclosure instead.
The DevSecOps lesson is structural, not technical. The attack succeeded not because of a missing security tool, but because of a missing process: no rapid “every CI token that touched the compromised dependency in the last N days” rotation playbook. Every team thinks it has one. Almost none do. The token in question was a long-lived GitHub Actions token with broad repo-read scope — precisely the kind of credential that’s supposed to be ephemeral by 2026 but, in practice, still litters most production workflows.
What to do this week: inventory long-lived CI/CD tokens with read access to source repos; replace them with short-lived OIDC federation wherever your CI platform supports it; write a one-page “upstream package compromise” runbook that lists the exact GitHub/npm/PyPI/registry token classes to rotate within 24 hours of any disclosed compromise in your dependency graph; subscribe to GitHub’s and your registry’s security advisory feeds and make sure they page someone.
Sources: BleepingComputer
CISA opens KEV catalog nominations to vendors and researchers (May 22)
CISA launched a public web form letting researchers, vendors, and industry partners submit candidate entries for the Known Exploited Vulnerabilities (KEV) catalog. Until now, additions were almost entirely driven by CISA’s own intelligence channels — with predictable lag. The new form (alongside the existing vulnerability@cisa.dhs.gov mailbox) opens a faster, structured submission path, while keeping the inclusion bar intact: an assigned CVE, confirmed in-the-wild exploitation, and remediation guidance.
For DevSecOps teams the implications are operational, not theoretical. Your SCA and dependency-scanning tooling almost certainly already consumes KEV as a prioritization signal — Snyk, Aikido, Sonatype, Veracode, GitHub Advanced Security, GitLab, JFrog Advanced Security, Mend, and Black Duck all integrate it. A faster-moving KEV means faster-moving alerts in your scanners and, downstream, more frequent rebuild/redeploy churn driven by exploit-validation rather than CVSS scores alone. Two questions worth asking your team: (1) is anyone on your team in a position to submit KEV nominations from your incident-response data, not just consume them? (2) when KEV adds a CVE you have in your dependency graph, what’s your SLA from KEV-add to deployed patch?
What to do this week: confirm your dependency scanner uses KEV as a high-priority signal (not just CVSS); document a KEV-driven patch SLA (24 hours is the new federal default; many private orgs are 7–14 days — the DBIR 2026 found only 26% of CISA KEV entries get patched at all); identify the engineer or analyst on your team who would be the right channel for submitting KEV candidates back to CISA when your IR or threat-hunting work uncovers active exploitation.
Sources: Help Net Security · CISA announcement
npm ships 2FA-gated “staged publishing” in direct response to the wave (May 23)
In a direct platform-level answer to the Mini Shai-Hulud / TeamPCP / Nx Console campaigns covered above, GitHub rolled out staged publishing for npm to general availability. Instead of a direct publish that makes a package immediately installable, the prebuilt tarball lands in a stage queue and a human maintainer must pass a 2FA challenge to approve it before consumers can install it. Crucially, the approval requirement applies even to CI/CD-originated publishes and to OIDC trusted-publishing flows — meaning a compromised CI token alone is no longer enough to ship malicious versions to your downstream users.
A second change introduces three new install-source flags mirroring the existing --allow-git: --allow-file (local paths and tarballs), --allow-remote (HTTPS URLs/tarballs), --allow-directory (local directories). This lets organizations apply an explicit-allowlist policy to every non-registry install source, closing the “but it was just a local tarball” loophole that several recent attacks have exploited.
Prerequisites: publish access to the package; the package must already exist on the registry (brand-new packages can’t be staged); maintainer account 2FA enabled; npm CLI 11.15.0+. GitHub recommends pairing staged publishing with trusted publishing using OIDC for strongest protection. What to do this week: turn on 2FA across every npm maintainer account that has publish rights on packages your team produces or relies on; enable staged publishing on your highest-risk libraries first; update CI runners to npm 11.15.0+; review your npm install invocations and tighten install-source flags to the minimum your build actually needs.
Sources: The Hacker News · GitHub changelog
Three ways operational debt will break your AI strategy — and how to recover (May 22)
A platform-engineering counterpoint to the week’s attack stories. Debora Cambe argues that the same accumulated shortcuts that have always broken software systems — undocumented changes, unmonitored services, stale runbooks, drifted environments — break faster and harder in AI-augmented production, because AI agents amplify both the velocity of change and the blast radius of bad assumptions. Three categories of operational debt do most of the damage: (1) observability debt: you cannot see what your agents are doing or why; (2) governance debt: agents have privileges, secrets, and tool access that no human signed off on; (3) runbook debt: nothing on-call has practiced for the failure modes agents create.
The four-step recovery framework: inventory (every agent, model, MCP server, and credential touching production), instrument (decisions, tool calls, retries, and outcomes), gate (require human approval for irreversible actions and credential issuance), and rehearse (failure-mode tabletops specifically for agentic systems — what happens when the model is wrong, the tool is wrong, or both?). Reads as the platform-engineering complement to this week’s supply-chain stories: secure your dev tooling, and keep your AI ops resilient. The two halves of the DevSecOps mandate.
What to do this week: spend an hour producing a one-page agent inventory for any AI agent your team has put into a production-facing workflow; identify the three highest-risk gaps in that inventory (uncredentialed agent, unlogged tool call, missing rollback); write a single tabletop scenario for an agent-induced incident and run it with on-call.
Sources: The New Stack
|
