devtake.dev

Red Hat's npm namespace and Arch's AUR were both backdoored within two weeks of each other

A worm hijacked Red Hat's npm namespace, a rootkit spread through 1,500 Arch AUR packages, and a SOC 2-certified AI gateway shipped malware. Registries are under fire.

Luca Reinhardt · · 4 min read · 5 sources
Cargo loader moving freight onto an aircraft, a stand-in for the software supply chain
US Air Force / Public domain via Wikimedia Commons · Source

Three supply-chain attacks hit the registries developers pull from daily, all inside two weeks. Red Hat’s npm namespace got backdoored. Arch Linux watched a rootkit spread through its archive. A startup whose security badge meant nothing shipped a credential stealer. The trusted middle layer of open-source distribution is the target now, not the code at either end.

Here’s why that combination matters more than any single incident. A worm in one package is a bad week. Three near-simultaneous compromises of the channels developers trust by default, npm namespaces, a Linux distro’s build archive, and a third-party audit badge, is a signal that attackers have moved past hunting typo-squats and started subverting the systems meant to make packages safe to install. The defense advice that worked last year (“install from official sources, check the badge”) is exactly what failed here.

What hit what

IncidentWhat happenedWho’s exposedSource
Red Hat npm worm96 versions across 32 @redhat-cloud-services packages backdoored via a hijacked maintainer accountAnyone who installed the affected versions in early JuneRed Hat RHSB-2026-006
Arch AUR rootkit~1,500 AUR packages tampered to fetch an eBPF rootkit through a malicious npm dependencyArch users who built affected AUR packages with yay or paruArch Linux
Certified LiteLLMBackdoored releases of a popular AI gateway that carried a fast-tracked SOC 2 badgeTeams that trusted the certification as a security signalOX Security

Red Hat’s own npm channel got backdoored

On June 1, attackers pushed malicious commits through a compromised maintainer’s GitHub account into three RedHatInsights repositories, then let Red Hat’s own CI/CD pipeline publish the poisoned builds. Security firm Aikido counted 96 backdoored versions across 32 packages in the @redhat-cloud-services scope, with a combined 116,991 weekly downloads. The payload, a worm Aikido calls Miasma (a Greek-mythology reskin of the Shai-Hulud family), sweeps for AWS keys, GCP and Azure credentials, GitHub tokens, SSH keys, npm publish tokens, and .env files.

The detail defenders should sit with: because the packages went out through the real pipeline using GitHub Actions OIDC tokens, they shipped with valid SLSA provenance attestations. Red Hat says no production console was affected, noting its publication process strips install-time scripts before deployment, and it pulled the bad versions after disclosure. The signed-malware part is what makes this one different.

Arch Linux: 1,500 AUR packages, one rootkit

Arch’s community archive took a different route to the same place. Attackers adopted orphaned AUR packages through the standard ownership process, then rewrote each package’s PKGBUILD to run npm install atomic-lockfile during build. That dependency, traced by Sonatype in a campaign it named Atomic Arch, bundled a native Linux binary that loads an eBPF payload to hide its own files, processes, and network activity, rootkit behavior, while harvesting GitHub credentials, SSH keys, Vault tokens, and browser cookie stores.

The count climbed from a few dozen to roughly 1,500 packages across multiple waves between June 11 and 12. Arch responded fast, temporarily freezing new account creation, package updates, and adoptions while it scrubbed malicious commits. The team’s guidance stayed blunt: “We continue to encourage all users of AUR packages to review all PKGBUILD and install script changes when updating, especially during this time.” As of this week, Arch believes the incident is contained. Anyone who built an affected package since June 11 should assume local secrets are gone.

The badge that meant nothing

The third one isn’t about a hijacked account. A trust signal failed instead. LiteLLM, a widely used open-source AI gateway, shipped malicious releases that stole cloud, CI/CD, and crypto-wallet credentials. The compromised build was likely downloaded close to 47,000 times before removal. The twist that made it a story: LiteLLM carried a SOC 2 certification from a Y Combinator audit startup that sold compliance in under 60 days rather than the usual 6 to 12 months. Later analysis of the auditor’s leaked records described 533 reports across 455 companies running 99.8% identical content.

A SOC 2 badge attests to a company’s internal controls. It was never a malware scan of the package you install. This case made that gap impossible to ignore: buyers were treating a fast-tracked audit as a security guarantee it never was.

Our pick: worry about Red Hat first

If you only harden against one of these, make it the Red Hat pattern. The Arch attack is loud and local; a careful maintainer who reads PKGBUILD diffs catches it, and Arch’s lockdown bought time. The certification story is a procurement lesson, treat audit badges as one input, not proof. The Red Hat compromise is the one that breaks the model most teams actually rely on.

Those packages were signed, attested, and published from the genuine namespace through the genuine pipeline. Every automated check a careful org runs, provenance verification, trusted-publisher policies, namespace allowlists, would have waved them through. The lesson connects to a run of npm and PyPI package attacks we’ve tracked, and to how a stolen token turned a VS Code zero-day into supply-chain reach: provenance proves where a build came from, not whether the account behind it was the attacker. Pin versions, watch for off-cadence releases from trusted scopes, and rotate any credential that touched a CI runner in early June. Signed does not mean safe, and the tampered-download playbook is climbing the trust chain.

Share this article

Quick reference

AUR
Arch User Repository, a community archive of build recipes (PKGBUILD scripts) that helpers like yay and paru run to compile and install software.
SLSA provenance
A signed record of how and where a package was built, meant to prove an artifact came from a trusted pipeline rather than a tampered one.

Sources

Mentioned in this article