The malware was signed by Red Hat
This week, credential-stealing code reached developers wearing Red Hat's name. The threat didn't come from outside your circle of trust — it came from inside it. You can't vet your way out of that. You can keep your credentials out of reach.
This week, code signed by Red Hat tried to steal your credentials.
Attackers got into a Red Hat developer's account and published tampered versions of official Red Hat packages. The moment a machine installed one, hidden code ran automatically and reached for everything valuable it could find — cloud keys, access tokens, logins, anything that opens a door. Then it used what it stole to spread.
Notice the shape of this. Red Hat wasn't the target — you were. Their name, their trusted account, the install pipeline you've used a thousand times without thinking: those weren't the casualty. They were the weapon. The attack didn't sneak past your circle of trust. It walked in the front door wearing a badge you issued yourself. That's what makes supply-chain attacks different from everything else — the danger isn't a stranger you can block, it's the vendor you already decided to trust, delivering the payload for you. And this was Red Hat: one of the most security-mature companies alive, with real review and real budget. The bad code shipped under their name anyway.
So here's the conclusion you don't get to dodge: if Red Hat can't guarantee that what you install from them is clean, nobody can. Not your framework, not your CI vendor, not the dependency three levels down you've never read. You will eventually run code you didn't write and couldn't fully vet. That's not a process failure — it's what building on other people's software is.
Keep scanning. Keep pinning versions. Keep vetting. All of it is worth doing — just don't rely on it, because this week none of it would have helped: the malware arrived pre-trusted. The real question isn't how to keep the bad code out. It's this: when bad code runs on your machine, have you protected your secrets?
For almost everyone, the honest answer is no. Look at what this attack grabbed — environment variables, tokens sitting in files, and then it walked up to the cloud secret managers and asked them to hand over their contents. That's how credentials live in 2026: piled in one place, in plain reach of whatever happens to be running. One bad install doesn't take one secret. It takes all of them, then spreads.
The fix is to stop keeping your credentials where your code can grab them. Keep them at arm's length.
That's the whole idea behind how Clavitor works. Your secrets don't live in your environment; nothing waits in a .env file to be read. A program — or an AI agent — never holds the credential. It gets the ability to use one, fetched fresh the instant it's needed — never stored, never cached — from one of our 21 locations across six continents, so the nearest copy is always milliseconds away, scoped to the single secret it was granted, every access logged. When a malicious install script feels around for keys, it finds an empty room.
And we assume a credential gets caught eventually, so what an agent carries is nearly useless if it's stolen. It works only from the machine it was issued to — lift it and run it from the attacker's own servers, and it's refused. It's rate-limited and watched: a few secrets a minute, so it can't vacuum your vault, and the moment it reaches past its normal handful it trips an alert and locks. A worm's entire strategy — grab everything fast, use it everywhere — hits a wall.
No promises of immunity: if a credential is in active use the instant the malware runs, that one can be caught — no architecture rewrites physics. But that's the point. The Red Hat attack was devastating because one install could drain a whole secret store and weaponize it. Arm's length, plus a credential pinned to one machine and throttled to a trickle, turns "they took everything and spread" into "they may have caught one key in flight, and it worked nowhere else." That's the distance between a catastrophe and a footnote.
The malware was signed by Red Hat. You won't out-vet that. Assume the code gets in — and make sure that when it does, your secrets aren't sitting there waiting for it.
(Tracked publicly as "Miasma," a variant of the Shai-Hulud family of self-spreading npm worms. The technical write-ups are worth your time; this post is about the part that doesn't change from one to the next.)
Sources: