# More, and More Extensive, Supply Chain Attacks

Open source components are getting compromised a lot more often. I did some counting, with a combination of searching, memory, and AI assistance, and we had two in 2026-Q1 ( [trivy](https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/), [axios](https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan)), after four in 2025 ( [shai-hulud](https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack), [glassworm](https://www.truesec.com/hub/blog/glassworm-self-propagating-vscode-extension), [nx](https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7p-598c), [tj-actions](https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog-action-setup)), and very few historically \[1\]:

[![](https://www.jefftk.com/major-open-source-trust-chain-attacks-v2.png)](https://www.jefftk.com/major-open-source-trust-chain-attacks-v2-big.png)

Earlier attacks were generally compromises of single projects, but some time around [Shai-Hulud](https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack) in 2025-11 there started to be a lot more ecosystem propagation. Things like the [Trivy compromise](https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/) leading to the [LiteLLM](https://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html) compromise and (likely, since it was three days later and by the same attackers) [Telnyx](https://www.trendmicro.com/en_us/research/26/c/teampcp-telnyx-attack-marks-a-shift-in-tactics.html). I only counted the first compromise in chain in the chart, but if we counted each one the increase would be much more dramatic. Similarly, I only counted glassworm for 2025, when it came out, but it's [still going](https://www.bleepingcomputer.com/news/security/glassworm-malware-hits-400-plus-code-repos-on-github-npm-vscode-openvsx/).

In January I told a friend something like: "I'm surprised we're not seeing more AI-enabled cyberattacks. It seems like AIs have gotten to the point that they'd really be helping bad actors here, but it all still feels pretty normal and I don't understand why." While it's always hard to call the departure of an exponential from a noisy baseline, if this is AI helping with attacks we should expect this rate of increase to continue.

Other data points that have me expecting security to get worse before it gets better:

*   Linux [is seeing](https://lwn.net/Articles/1065620/) a large increase in real security reports:
    
    > We were between 2 and 3 per week maybe two years ago, then reached probably 10 a week over the last year with the only difference being only AI slop, and now since the beginning of the year we're around 5-10 per day depending on the days (fridays and tuesdays seem the worst). Now most of these reports are correct, to the point that we had to bring in more maintainers to help us.
    
    We're seeing the defender side, but attackers can use the same tooling.
*   Claude Opus 4.6 [seems to be](https://red.anthropic.com/2026/zero-days/) actually good at finding and exploiting holes:
    
    > When we pointed Opus 4.6 at some of the most well-tested codebases (projects that have had fuzzers running against them for years, accumulating millions of hours of CPU time), Opus 4.6 found high-severity vulnerabilities, some that had gone undetected for decades.
    
*   AI agents eagerly pull in unvetted dependencies if they seem like they'd solve the problem at hand, and while humans do this too the agents massively speed up this process.
    

But I do think it will get better: while I'm not an expert here, I see many factors that favor defenders:

*   I think it's pretty likely that security bugs in major software are for the first time being identified faster than they're being written.
    
*   Checking package updates for vulnerabilities was never something most people did, but automated systems could plausibly do it well.
    
*   Most programmers are pretty terrible reviewing code in enough detail to notice something [underhanded](https://en.wikipedia.org/wiki/Underhanded_C_Contest), but LLMs excel at this kind of attention to detail.
    
*   Developer education is hard, model education is much less so. I remember how long it took for SQL injections to go from a known attack to something most programmers knew not to do; it's way easier to keep LLMs from doing this.
    
*   Dependency cooldowns are very simple, but would [help a lot](https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns).
    
*   Migration to more robust systems is more automatable. Automated conversion [from C to Rust](https://syzygy-project.github.io/), switching to [TrustedTypes](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API), etc.
    

I wish defenders in biology had the same structural advantages!

  
\[1\] Here's my attempt at earlier years, all with a bar of "compromise of a widely used open-source trust path that forced action well beyond the directly compromised maintainer or project":

*   2024: [polyfill.io](https://blog.qualys.com/vulnerabilities-threat-research/2024/06/28/polyfill-io-supply-chain-attack), [xz](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)
*   2022: [pytorch](https://pytorch.org/blog/compromised-nightly-dependency/)
*   2021: [ua-parser-js](https://www.truesec.com/hub/blog/uaparser-js-npm-package-supply-chain-attack-impact-and-response)
*   2018: [event-stream](https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor/)
*   2016: [ke-ranger](https://unit42.paloaltonetworks.com/new-os-x-ransomware-keranger-infected-transmission-bittorrent-client-installer/), [linux mint](https://www.bitdefender.com/en-us/blog/hotforsecurity/tampered-linux-mint-iso-linked-on-official-website)
*   2011: [vsftpd](https://www.cvedetails.com/cve/CVE-2011-2523/)