Nx supply‑chain breach (S1ngularity): malicious Nx packages published to npm via stolen publish token

Key update

On August 26, 2025 attackers published malicious versions of multiple Nx packages to npm for about four hours after exploiting a GitHub Actions workflow injection to steal an NPM publishing token. The malicious packages included postinstall code that scanned local machines for secrets and used local AI CLIs (reported examples: Claude, Gemini) to help identify files for exfiltration, then uploaded results to public GitHub repositories. Nx has removed the poisoned packages, revoked tokens, published a detailed postmortem and advisory, and moved publishing to npm Trusted Publishers / OIDC with manual approvals.

Why it matters

This is a high‑impact supply‑chain compromise with direct developer consequences: Nx is widely used in JavaScript/TypeScript monorepos and CI pipelines, so a short window of poisoned packages amplified risk across many developer machines and CI systems. The incident shows three connected failure modes that you need to treat as practical threats: unsafe GitHub Actions patterns (pull_request_target plus unsanitized input and overly broad workflow permissions), long‑lived/over‑privileged publish credentials, and malware that leverages local AI developer tools as part of its reconnaissance/exfiltration toolkit.

For practitioners, the immediate operational actions are straightforward and urgent: confirm whether you installed any of the affected Nx package versions and treat any system with those versions as potentially compromised; rotate and revoke any exposed tokens and credentials (GitHub and npm), inspect GitHub audit/security logs for unexpected repositories or CLI activity, clean package and NPX caches, and update to the patched Nx releases. On the CI/DevOps side, eliminate patterns that enable this vector: avoid pull_request_target for untrusted inputs, minimize workflow permissions (default to read-only tokens), remove workflow_dispatch from publish pipelines that accept untrusted triggers, prefer OIDC and short‑lived credentials for registry publishing, require explicit manual approvals for releases originating from forks or external contributors, and add provenance checks for published artifacts. Finally, treat local developer environments as potential exfiltration targets: limit plaintext secrets on dev machines, use credential managers, and monitor for unusual outbound activity or freshly created public repositories that might contain leaked data.

This incident is a reminder that supply‑chain hygiene requires both secure CI patterns and rapid incident playbooks; upgrading tooling alone isn’t enough unless publishing flows and workflow permissions are locked down and token lifetimes are constrained.

Source

• Source