Supply Chain Attacks: How One Update Hit OpenAI

A routine software update. No phishing. No sketchy download. Then a security team finds the unthinkable: trusted code has been hijacked, and the breach rode in through the exact channels engineers rely on every day. I walk through the supply chain attacks that piled up across April and May 2026, including poisoned open source packages tied to TanStack and trojanized Daemon Tools installers, plus the rapid-fire abuse of major software registries like NPM, PyPI, and Docker Hub. 

The most important twist is what the malware is hunting. These campaigns aren’t primarily chasing customer data. They’re after the assets sitting on developer laptops and flowing through build servers: developer credentials, API keys, cloud tokens, SSH keys, and the permissions that turn “one compromised machine” into “access everywhere.” I explain why this shift is happening now through two lenses: trust (software is assembled, not written from scratch) and leverage (compromise one popular dependency and you reach everyone who installs it). 

Then we get practical about software supply chain security and CI/CD security. I break down how a poisoned pipeline can still output packages that look legitimate, complete with valid signatures, and why that makes detection so hard. Finally, I lay out five moves you can take right now: build an SBOM, treat CI/CD like production, watch for suspicious dependency changes and too-fresh releases, rotate to short-lived scoped secrets, and patch known-bad tool versions quickly. Subscribe, share this with a developer or leader who approves tooling, and leave a review so more teams stop trusting updates on autopilot.

YouTube more your speed? → https://links.sith2.com/YouTube  
Apple Podcasts your usual stop? → https://links.sith2.com/Apple  
Neither of those? Spotify’s over here → https://links.sith2.com/Spotify  
Prefer reading quietly at your own pace? → https://links.sith2.com/Blog  
Join us in The Cyber Sanctuary (no robes required) → https://links.sith2.com/Discord  
Follow the human behind the microphone → https://links.sith2.com/linkedin  
Need another way to reach me? That’s here → https://linktr.ee/rich.greene

Transcript

A Routine Update Goes Wrong

SPEAKER_00 0:00

May 11th, 2026, an engineer at OpenAI runs a routine update. The kind a developer runs a dozen times a week, the kind nobody thinks about. A few hours later, the security team finds something unexpected on the laptop. Then on another laptop, then comes the disclosure. The engineers did not click a phishing link. They did not download anything sketchy. They installed a piece of code that millions of developers install every week from a source that had been trusted for years. That source had been hijacked.

What A Supply Chain Attack Is

SPEAKER_00 0:34

Welcome to Plain Text with Rich. Today we are talking about supply chain attacks, why they keep piling up through April and May 2026, and honestly the entire year and the years before, and why the people building your software are now the most valuable target on the network. In plain text, a supply chain attack is when an attacker compromises a tool, library, or vendor that you trust so that when you install or update that thing, you also install whatever they put inside it. You didn't get attacked. The thing you depended on did. The attack just wrote in with the update.

Spring 2026 Attack Wave Breakdown

SPEAKER_00 1:15

And this spring was loud. A group called Team PCP poisoned 42 packages from a popular open source library called Tan Stack. 84 malicious versions were published in about six minutes on May 11th. One of those packages, the React router piece, gets pulled down roughly 12 million times a week. Two OpenAI employee devices ended up compromised. OpenAI disclosed it on May 15th. Separate campaign trojanized installers for a Windows tool called Daemon Tools. Researchers at Kaspersky found it had been quietly delivering signed backdoored installers since April 8th. Most infections were noise. About a dozen machines sitting inside government, scientific, and manufacturing organizations got the high-value treatment. And in a 48-hour window back in April, attackers slipped malicious packages into NPM, PyPy, and Docker Hub, three of the biggest software registries on the internet, hit one after another. In every case, the malware was not looking for customer data, it was looking for developers' credentials, API keys, cloud tokens, SSH keys, the stuff sitting on a developer's laptop or running through their build server.

Why Developers Became The Target

SPEAKER_00 2:38

Here's the question worth sitting with. Why did attackers suddenly stop targeting your production systems and start targeting the people who build them? Well, I think there's two reasons. The first reason is trust. Modern software is not written from scratch, it's assembled. A normal business application might pull in, I don't know, 800 third-party pieces of code that some volunteers maintain in their spare time. Your developers trust those pieces. Your build servers trust your developers. Your production systems trust your build servers. Compromise the right ingredient and you ride a chain of trust straight to the inside. The second reason is leverage. Comprising one company, well, it gets you one company. Compromising one popular library gets you everyone who uses it. The Tanstack package, the attacker's poison, again, is pulled down 12 million times a week. Do the math, right? It's easy math. Effort goes down, blast radius goes

CI/CD The Poisoned Conveyor Belt

SPEAKER_00 3:48

up. Now, here is the part that surprises a lot of leaders. The Tanstack attackers never stole anyone's password. They never fished a maintainer. They did not break into anyone's account. What they did again was hijack the automated assembly line. Now, that assembly line has a name. It is called CICD, short for continuous integration and continuous delivery. Now, in plain text for that, it is the conveyor belt that takes a developer's code, builds it, packages it, signs it, and ships it out to the world. Almost every modern engineering team has one, right? If you could for a moment picture a factory. The recipe gets approved by the chef, but nobody has tampered with the conveyor belt between the kitchen and the loading dock. Every dish the chef makes still gets her signature on the label, except by the time it leaves the building, the recipe has been quietly changed. This is what happened. The malicious code was published by the legitimate pipeline with the legitimate signature, by the legitimate identity. The conveyor belt was poisoned, not the chef. That is also why this kind of attack is so hard to catch. Every guardrail downstream looks at the package and says, yes, this is signed. Yes, this comes from the right place. Yes, this is the right team. By the system's own rules, it is.

Five Practical Moves To Reduce Risk

SPEAKER_00 5:17

Most organizations still treat developer laptops and build pipelines like ordinary employee IT, but they are not ordinary. Anything they can produce, signed, trusted code, is a high value target worth saying out loud. So what do we actually do about it? I'm going to give you five potential moves. Move number one, and this is for leaders, get an inventory of what your software depends on. It's called a software bill of materials or an SBOM. Think of it as the ingredients label on the back of a serial box. If you do not know what is in your software, you cannot tell whether one of those ingredients just got recalled. A move number two is also for leaders. Treat your CICD pipeline like production because it is. Same access review, same monitoring, same incident response plan. If your build server can sign code that ships to customers, it is not an IT system. In my mind, it is a crown jewel. A move number three is for developers. When a package was published, matters, all right? A version reviewed last month is safer than a release that dropped six hours ago. Get alerts when something in your dependency tree changes unexpectedly. Move number four is also again for developers. Make secrets short-lived and scoped. Long-lived API keys sitting in environment variables are the prize for a lot of folks. Tokens that expire in an hour are a much smaller payday for an attacker. And number five, or move number five, is for everyone. If you use Daemon Tools, update it today. Versions 12.5.0.2421 through 12.5.0.2434 are the bad ones. Version 12.6.0.2445 and later is clean, at least for now. And this applies to the home gamer, the IT admin, and the manufacturing engineering or engineer reading this or listening while on their lunch break.

Recap Plus Updates And Listener Ask

SPEAKER_00 7:26

To recap, a supply chain attack compromises the things you trust. So the attack rides in with the update. The spring of 2026 has been one wave after another. If you've been reading or watching or listening to the news, the targets are not your production servers, they are your developers, your build pipelines and the open source libraries you assemble your software from. The leverage for the attacker is enormous, right? The fix starts with knowing what is in your sys or not in your system, but in your software and treating the machines that build it like the high value targets they are. Now, if you are listening in a browser, thank you. If you are listening in whatever app you're using right now, please hit subscribe and the follow button if you enjoyed this. All right, it is the single best way to make sure you do not miss the next one. If you enjoyed this episode, please share with someone who would actually benefit. A developer on your team, a leader who signs off on tooling decisions, anyone who has ever hit install without thinking twice about it. Email, DM, or comment with the strangest, oldest, or most surprising package buried in your dependency tree. I want to hear what you find. As always, every message gets read and answered. This has been Plain Text with Rich. 10 minutes or less, one topic, no panic. I will see you next time.