Google Threat Intelligence Group (GTIG) assesses with high confidence that large-scale open-source campaigns, including self-spreading worms, are a significant expansion of the supply chain tactic, and it expects the trend to continue through 2026. For anyone who installs packages, the practical meaning of software supply chain dependency risk is that your shipped code can be compromised even when every line you wrote is correct.
What changed in 2026
GTIG says most of the most impactful supply chain compromises it tracked in 2025 and early 2026 involved code repositories, software dependencies and developer tools. It attributes the activity it calls UNC6780, or TeamPCP, to extensive compromises targeting PyPI, npm and Docker Hub from February to May 2026.
The March 2026 incidents
Red Hat's advisory RHSB-2026-001 says multiple widely used open-source projects were affected in March 2026, including LiteLLM, Trivy, Checkmarx KICS, Axios and various npm packages. Red Hat states that no Red Hat products were identified as built or shipped with a compromised version. ActiveState says TeamPCP compromised Trivy on March 19, 2026, then used stolen CI credentials to move into other ecosystems, and StepSecurity describes the same chain. Red Hat lists CVE-2026-33634 for the Trivy incident.
Attribution and what is contested
ActiveState gives Trivy a CVSS score of 9.4. That figure comes from one vendor and has not been checked against NVD, so treat it as unverified. Beyond GTIG's TeamPCP label, attribution of these incidents is uneven and in places single-sourced.
Most of the routes involved are not new. Typosquatting, install-time scripts and stolen maintainer accounts were documented years before 2026. What is newer is the chain in which one compromise yields credentials for the next.
What a software supply chain dependency risk is
Cycode defines software supply chain risk as vulnerabilities introduced through third-party components, open-source dependencies, development tools or misconfigurations, including compromised build environments and public repositories. The research found that this definition matches the academic and government framing. It differs from an ordinary bug in your own code because the flaw enters through code nobody on your team reviewed, and it can arrive at build or install time rather than in your application logic.
Why indirect dependencies are the blind spot
Veracode argues that the real danger often lies in the dependencies of your direct dependencies, and recommends software composition analysis and mapping the full dependency tree. The underlying principle is well supported, but the framing is vendor opinion. The Trivy case shows the problem concretely. According to ActiveState, the attack did not require any developer to do anything wrong, and a dependency of a dependency of a plugin was enough. Those incident details still need primary confirmation. A flaw several layers down is easy to miss because few teams read code they never chose directly.
How malicious code gets into installed packages
Compromised maintainer accounts
A package is only as trustworthy as the accounts that publish it. Someone holding stolen maintainer credentials can push insecure code under a trusted name. The 2018 eslint-scope incident is a documented example. An academic survey estimates it exposed about 4,500 accounts. That is an estimate, not a measured count.
Install-time scripts
Zscaler describes the axios compromise as a malicious dependency carrying a postinstall script, which runs automatically when npm install is executed. In Python, setup.py runs during installation of source distributions, which lets an attacker execute commands at install time.
Typosquatting and dependency confusion
Typosquatting publishes malicious code under a name similar to a popular package. Dependency confusion mimics private or internal package names so that a build pulls the public copy instead. A 2017 campaign called HackTask uploaded about 40 malicious packages and went unnoticed for 12 days, according to the same academic survey, which labels the download figures as estimates.
Why self-spreading worms raise the stakes
StepSecurity describes the TeamPCP loop this way: compromise a widely trusted component, plant a credential stealer, collect secrets that CI/CD runners load into memory, and reuse them for the next compromise. StepSecurity names self-propagation as the biggest driver of acceleration. It cites Shai-Hulud, which compromised more than 500 npm packages in September 2025 by using each victim's stolen npm token to infect packages that victim maintained. TechCrunch reports that attackers aim to compromise developers of popular open-source projects, then use that access to push malicious updates downstream.
For comparison, an academic paper puts the time to discover the 2018 event-stream compromise at 46 days. A worm that reuses stolen tokens can shorten the gap between the first infection and the next, which is why defenders cannot rely on finding one bad package and stopping there.
What the numbers do and do not tell you
The counts in circulation measure different things, so do not add them together. Mend reports 187 npm packages hit by self-spreading malware, with automated republishing using legitimate maintainer credentials. Cybernews, citing Socket, reported 416 flagged packages in a separate wave. StepSecurity tracked 56 open-source supply chain attacks from August 2025 to August 2026, which it says is roughly one every three days since March. That is one vendor's count under its own methodology. Secondary commentary by Digital Applied reports Wiz putting one August 2026 npm worm at more than 400 packages. That is a vendor-stated spread figure, not a victim count.
Evidence on how many organisations were affected is thin. Most published counts are packages, versions or downloads. The SolarWinds Orion compromise is often cited alongside these events, but it was a compromised vendor build and update channel that shipped a delayed-activation trojan affecting thousands of organisations. It was not an open-source dependency and should not be used as evidence of that problem.
What teams can practically do
CISA's 2024 SBOM guidance recommends identifying as many levels of subcomponents as possible. Its 2026 Minimum Elements say an SBOM should provide a comprehensive component listing to support risk-based decisions, and that a recipient can conclude a new vulnerability does not affect them if the component is not listed. That reasoning only holds when the list is complete, so an SBOM is a starting point, not a guarantee.
SBOMs and VEX
CISA's consumption guidance notes that SBOM-listed vulnerabilities can overstate real product risk, and points to VEX (Vulnerability Exploitability eXchange) as a way to show which listed issues are actually exploitable. Critics quoted by Dark Reading say the 2026 changes are directionally right but unlikely to make a significant difference, because standards and tools already capture transitive dependencies. The sources reviewed do not measure whether SBOMs reduce incidents.
Install scripts and lockfiles
Restricting or reviewing install-time scripts addresses the postinstall and setup.py routes described above. Lockfiles and pinned versions reduce surprise changes, but they also slow the adoption of security fixes. Pin everything and you may be slow to patch. Float versions and you accept new code automatically. The research found little practical guidance on managing that trade-off, so each team has to decide where to set it.
Credential hygiene in CI/CD
The TeamPCP pattern makes CI secrets part of the attack surface. Scope build tokens narrowly, rotate any token that a build runner could read, and treat tokens that ran inside a compromised job as exposed.
What is not yet established
No statement from npm, PyPI or GitHub about registry-level responses to the 2026 worms was found, so this article does not describe any platform changes. A cross-level risk model in a 2026 arXiv preprint is a proposal, not consensus. A developer quoted by Cybernews describes a payload that deletes files if a stolen GitHub token is revoked. That is one account, not a documented general behaviour. Original Unit 42 and Singapore CSA documents were not retrieved, so their figures remain unchecked. The publication date of CISA's 2026 SBOM document was not verified. Primary post-incident reports from registries, and published victim counts rather than package counts, would change this picture most.