In April 2026, cyber threat assessment firms discovered malicious code in open-source npm packages. By the time Australian Federal Police and the FBI arrested two alleged members of TeamPCP, over 1,000 organizations worldwide had been compromised. The attackers stole more than 500,000 credentials and exfiltrated at least 300 gigabytes of data.
This was a supply chain attack targeting the trust model that most development teams rely on every day.
What Happened
TeamPCP allegedly compromised more than 180 npm packages using a self-replicating worm called Shai-Hulud. The worm spread through the dependency chain, infecting downstream packages and any application that used them. Once inside an environment, it harvested credentials and exfiltrated data.
The group also quickly turned public exploits into attack tools before most organizations could patch.
Timeline
April 2026: Threat assessment companies flagged suspicious code in open-source packages. An investigation began with Australian Federal Police and FBI collaboration.
Date of arrests not specified in source: Two alleged TeamPCP members were arrested in Australia.
Between detection and arrest, the campaign continued to spread, affecting organizations that hadn't implemented package verification or supply chain security controls.
Which Controls Failed or Were Missing
The scale of this incident highlights several missing or ineffective controls:
No package integrity verification. Most affected organizations likely pulled npm packages without verifying signatures or checksums. When Shai-Hulud infected a package, it spread to every system that ran npm install without verification.
Missing Software Bill of Materials (SBOM). Without an SBOM, you can't answer basic questions: What packages are you using? Which versions? What dependencies do they pull in? When a supply chain attack hits, you're flying blind.
No dependency scanning in CI/CD. If your pipeline doesn't scan dependencies for known malicious code or suspicious behavior before deployment, you're trusting every package maintainer and every contributor to that maintainer's dependencies.
Inadequate credential management. The theft of 500,000+ credentials suggests widespread use of hardcoded secrets, credentials in environment variables accessible to running code, or insufficient secrets management. Once inside, Shai-Hulud had access to whatever credentials the application could reach.
Lack of network segmentation. The 300+ gigabytes of exfiltrated data indicates that compromised systems had broad network access. Proper segmentation would limit what an attacker can reach from a compromised application server.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining an inventory of bespoke and custom software and third-party software components. This isn't optional if you handle payment data. You need to know what you're running.
Requirement 6.4.3 requires that public-facing web applications are protected from attacks through automated technical solutions or manual code reviews. That includes protecting against supply chain compromises that affect your web applications.
NIST Cybersecurity Framework v2.0 calls for supply chain risk management under the Identify function. You should assess risks from third-party components and implement controls to detect compromised software.
ISO/IEC 27001 Control 8.30 (Outsourcing) and Control 5.19 (Information security in supplier relationships) require managing security risks from external dependencies. Open-source packages count as supplier relationships, even if you're not paying for them.
OWASP Top 10 2021 A06:2021, Vulnerable and Outdated Components directly addresses this risk. If you're pulling in packages without verification and without tracking what's in your dependency tree, you're violating basic application security principles.
Lessons and Action Items for Your Team
Build an SBOM for every application. Use tools like Syft, CycloneDX, or SPDX generators. Your SBOM should capture direct dependencies and transitive ones. Update it with every build.
Implement package verification. Configure your package manager to verify signatures. For npm, use npm audit signatures. For Python, verify wheel signatures with sigstore. If a package can't be verified, don't pull it into production.
Scan dependencies in your CI/CD pipeline. Tools like Snyk, Dependabot, or Socket.dev can flag known vulnerabilities and suspicious package behavior before code reaches production. Make this a blocking check, not a warning you ignore.
Isolate secrets from application runtime. Don't let application code access credentials it doesn't need. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) with role-based access. If Shai-Hulud compromises your app, it shouldn't be able to harvest database credentials for unrelated systems.
Segment your network. A compromised web server shouldn't have access to your entire internal network. Implement zero-trust principles. Require authentication and authorization for every connection, even internal ones.
Monitor for unusual data exfiltration. The 300+ gigabytes didn't leave unnoticed because monitoring caught it (if it had, the number would be lower). Set up egress monitoring. Alert on large data transfers to unexpected destinations.
Patch quickly when exploits go public. TeamPCP operationalized public exploits fast. Your window between disclosure and exploitation is shrinking. If you're patching on a monthly cycle, you're giving attackers weeks of opportunity.
Test your incident response for supply chain scenarios. Run a tabletop exercise: "A package you deployed last week is flagged as malicious. What do you do?" If your team doesn't have a clear answer, build that playbook now.
The arrests in this case came after the damage was done. International law enforcement collaboration matters, but it won't protect your systems. That's your job. Start with the SBOM and package verification. Everything else builds from there.
