How 30 Seconds of Metadata Would Have Caught the Axios Attack. 13 Jun, 2026 March 31, 2026, two malicious axios versions live for ~3 hours, a RAT on every machine that ran a fresh install. Then the turn — the signal that something was wrong was sitting in public registry metadata the entire time. What happened: The factual spine, kept short. Maintainer’s PC compromised through social engineering and a RAT, npm credentials stolen, versions 1.14.1 and 0.30.4 published manually, malicious dependency pulling a cross-platform trojan. The signal everyone walked past: legitimate axios releases publish through an automated pipeline that stamps the registry with a trusted-publisher block and ties the version to a specific commit. The malicious versions had none of that — a manual token push, no matching pipeline run, no repo tag. The actual registry fields (_npmUser, the trusted-publisher / provenance block, gitHead). Why nobody caught it in time: Here’s the uncomfortable part: the check is obvious in hindsight, and almost nobody could have run it in time. Think about what catching this manually would actually require. Every time you run npm install, you’d need to pull the registry metadata for axios — and for every one of its dependencies, and their dependencies, down the whole tree. For each one, you’d compare the publisher against the package’s normal release process, look for a matching commit, and check whether the provenance block is present and consistent. Then you’d do it again on the next install, because a version that was clean yesterday can be republished today. No human does this. Not because developers are careless, but because it’s structurally impossible by hand. A modern project has hundreds to thousands of transitive dependencies. The malicious axios versions were live for about three hours — faster than any human review cycle, and most people who got hit weren’t reviewing anything. They ran an install, or a CI job did, and the trojan was already resolving before anyone could have looked. This is the real shape of the problem. The signal was public, cheap to check, and sitting in plain JSON. The gap wasn’t knowledge. It was that nobody had automated the one check that mattered and put it in the path of the install. What actually would have worked: Strip it down to a principle: a provenance-mismatch check, run automatically at install time, flags this entire class of attack before a single line of package code executes. The logic is simple enough to state in a sentence. For each package version about to be installed, ask whether it was published the way this package is normally published — through its established automated pipeline, with a matching source commit and a consistent provenance record. If a package that always ships through a verified pipeline suddenly appears via a manual token push with no commit behind it, that’s not a curiosity. That’s the signal. Stop, and surface it to the developer before the install proceeds. Run on the axios versions, that check fires immediately. The malicious 1.14.1 had none of the provenance fingerprint that legitimate axios releases carry. It would have been flagged in the half-second before install, not in the postmortem three hours later. I want to be precise about the scope of this claim, because precision is the whole point. This check catches this class of attack: a stolen credential used to publish outside the normal pipeline. It is very good at that, and that class is common. But it is not a universal answer. There is a harder version of this problem — an attack where the malicious package ships with perfectly valid provenance, because the pipeline itself was subverted. That one breaks the assumption this entire check rests on. It has already happened, and it’s what I want to write about next. The takeaway The axios attack wasn’t sophisticated in the way that matters here. The malicious versions announced themselves in the registry metadata the moment they were published — wrong publisher, no matching commit, missing provenance. Anyone who looked would have seen it. The reason it worked is that looking, at the speed and scale modern dependency trees demand, isn’t something a person can do. The check is cheap. It just has to be automated and sitting in the path of every install, on by default. That gap is the whole story — and it’s a fixable one.