On this page · 8 sections
Summary. In four days in July 2026, two npm supply chain attacks showed why perimeter thinking fails. On 11 July attackers published malicious versions of the jscrambler packages using stolen credentials, with 1,479 downloads before removal. On 14 July, Microsoft Threat Intelligence caught a compromise of the AsyncAPI organisation: 5 poisoned package versions across 4 package names, republished within about 90 minutes, each carrying a loader that ran at import time rather than through an install script. That timing matters, because npm v12, the biggest redesign of npm in its 16-year history, ships this month and blocks install scripts by default. It would not have stopped the AsyncAPI payload. Supply chain attacks now cost $4.91 million per breach on average and take 267 days to contain, per IBM, and Cybersecurity Ventures put global damage near $60 billion in 2025. This is a playbook for defending a real software supply chain, and where eCorpIT helps teams that would rather not learn it during an incident.
What broke in July 2026
The two July incidents are worth reading together, because they attack different layers.
The jscrambler compromise on 11 July was the familiar shape. Attackers used stolen publishing credentials to push malicious versions of the package and its plugins. Those versions carried hidden native binaries that ran during installation or use, targeting developer workstations, CI/CD pipelines and build systems to harvest credentials and secrets. It is the pattern the whole industry has spent a year building defences against.
The AsyncAPI compromise three days later was different, and more instructive. According to Microsoft's analysis, the attacker did not break into npm at all. A misconfigured GitHub Actions pull_request_target workflow ran attacker-controlled pull request code, which exposed the project's asyncapi-bot publishing token. The attacker then rode the project's own release pipeline. The poisoned packages, @asyncapi/specs, @asyncapi/generator, @asyncapi/generator-components and @asyncapi/generator-helpers, were published through the legitimate GitHub Actions OIDC release workflows and carried valid provenance attestations, even though the commits that triggered them were unauthorised. Provenance signed the wrong thing correctly.
The payload was a hidden detached Node process that fetched an 8.2 MB second stage from IPFS and decrypted a modular runtime. One accuracy note that most coverage got wrong: in the build Microsoft analysed, the credential-harvesting module was present but disabled. Persistence and command-and-control were live; data collection was dormant. The capability targeted more than 100 environment variables, including GITHUB_TOKEN, NPM_TOKEN, AWS keys, ANTHROPIC_API_KEY and OPENAI_API_KEY, plus files like .npmrc, .aws/credentials and kubeconfig. It could have been switched on remotely at any time.
Why blocking install scripts is necessary but not sufficient
npm v12 is a genuine improvement. It sets allowScripts off by default, so npm install no longer runs preinstall, install or postinstall lifecycle scripts, including native node-gyp builds, unless the project explicitly allowlists them. It also stops installing Git dependencies and remote sources by default. GitHub is phasing out long-lived publish tokens too: from early August 2026, granular access tokens lose the ability to publish directly and can only stage a publish that a human approves with 2FA, with a second tightening scheduled for January 2027. Every team running npm install in CI should audit its allowlist now using npm 11.16.0 warnings, before upgrade day breaks pipelines.
Here is the catch. The AsyncAPI packages declared no lifecycle hooks at all. As Microsoft's researchers wrote, "because the trigger is an import rather than an install script, the common npm install --ignore-scripts mitigation does not neutralize it." The loader executed the moment any build imported the module. Blocking install scripts is real progress against install-time malware, and does nothing against import-time malware. The same report is blunt about why scanners missed it: "the absence of lifecycle hooks is a deliberate evasion choice. Security tooling that focuses on preinstall/postinstall auditing will not flag these packages."
| Attack vector | July 2026 example | When code runs | Does npm v12 stop it? |
|---|---|---|---|
| Install script (postinstall) | jscrambler | During npm install | Yes, blocked by default |
| Native binary at install/use | jscrambler plugins | Install or first use | Partly; native builds need allowlist |
| Import-time loader | AsyncAPI | On import/require in a build | No |
| Pipeline takeover (OIDC) | AsyncAPI root cause | In your trusted CI | No; carries valid provenance |
| Stolen publish token | jscrambler | At publish | Reduced by staged publish, Aug 2026 |
The defense-in-depth playbook
No single control covers this. A working software supply chain programme layers cheap, boring controls so that any one failure is contained.
Fix dependency hygiene first. Pin exact versions, commit lockfiles, and install with npm ci. Add a cooldown so a release must age before your builds accept it. npm's own min-release-age feature and a floor of npm CLI 11.10.0 or later blunt the day-zero window that both July attacks exploited.
Block malicious packages at install. SBOM-first scanning with Syft plus Grype gives visibility, and a behavioural scanner such as Socket or OSV-Scanner flags packages that suddenly add network calls, install hooks or, importantly, import-time execution. Our note on defending CI against AI-hallucinated packages covers the slopsquatting variant of this.
Move to provenance, but do not trust it blindly. Adopt OIDC trusted publishing or staged publishing with human approval instead of long-lived tokens, and sign artifacts with Sigstore (cosign, Fulcio, Rekor) against SLSA build levels. We detail the setup in our guide to OIDC trusted publishing and cache-poisoning hardening. The AsyncAPI case proves provenance is necessary, not sufficient: it attested a compromised build honestly.
Harden your own release pipeline. The AsyncAPI breach started with a pull_request_target misconfiguration, a class of GitHub Actions bug called a pwn request. Review workflow triggers, restrict token scopes, require protected environments and approvals for publish jobs, and alert on anomalous automated publishes. Our deep dive on npm 12 install-script blocking in CI/CD pairs with this.
Contain the blast radius. Isolate secrets from build steps, restrict CI egress so a poisoned dependency cannot phone home, and purge shared npm and yarn caches after any incident. Rotate credentials from a clean host if a build ever imported a suspect version.
| Control layer | What it stops | Example tooling | Relative effort |
|---|---|---|---|
| Version pinning + lockfiles + cooldown | Day-zero malicious releases | npm ci, min-release-age | Low |
| Malicious-package scanning | Install and import-time payloads | Socket, OSV-Scanner, Grype | Low to medium |
| Provenance and signing | Tampered artifacts | Sigstore, SLSA, OIDC publish | Medium |
| Pipeline hardening | Pwn requests, token theft | Protected environments, scoped tokens | Medium |
| Secrets and egress isolation | Exfiltration after compromise | CI egress rules, secret managers | Medium to high |
What it costs if you get this wrong
The business case is not subtle. Compiled supply chain attack data for 2026 puts the average software supply chain compromise at $4.91 million with a 267-day lifecycle to identify and contain (IBM), records a 742% rise in attacks between 2019 and 2024 (CISA), and shows third-party involvement in breaches doubling from 15% to 30% in a single year (Verizon). Cybersecurity Ventures estimated global costs near $60 billion in 2025, with industry projections approaching $81 billion in 2026 (Juniper Research). The controls above cost a fraction of one incident. The real cost is usually the cleanup and the 267 days, not the tooling.
India-specific considerations
For Indian enterprises and startups, two rules sharpen the priority. CERT-In's directions require reporting cyber incidents within 6 hours of detection, so an unmonitored build pipeline is a compliance risk, not just a security one. The Digital Personal Data Protection Act 2023 (DPDP) adds duties around personal data that a leaked credential can expose. An SBOM and a monitored release pipeline are the fastest way to answer the two questions a regulator or customer will ask after an incident: what was in the build, and how did it get there. Teams shipping AI features should also read our secure AI-assisted development and AppSec service, since model-generated code widens the same attack surface.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based, senior-led engineering organisation, founded in 2021 and assessed at CMMI Level 5, that hardens software supply chains for startups and enterprises. We map your dependency and build attack surface, roll out SBOMs, malicious-package scanning and OIDC-based signed publishing, and lock down CI/CD workflows against the pipeline-takeover pattern that hit AsyncAPI. As an AWS, Microsoft, Google and Kaspersky technology partner, we design aligned with CERT-In and DPDP requirements rather than bolting security on afterwards. To review your pipeline before an incident does, talk to our engineering team.
References
_Last updated: 23 July 2026._
