Why npm audit Suddenly Flagged axios and undici in Late September (2026)

Picture it: you ran npm audit on a Monday and got a clean report. You ran it again on Thursday and axios had a dozen advisories, undici had ten more, and nothing in your repo had changed.

That's what happened to a lot of Node projects at the end of September. We pulled the advisory records to see why, and then tested the one bug in the batch we thought most readers would actually hit.

What actually changed on 28-30 September

npm audit sends your dependency tree to the npm registry's bulk advisory endpoint and prints whatever comes back. In practice that list tracks the GitHub Advisory Database: these entries started showing up in audit output once GitHub had reviewed them. When the list gains an entry, every project with a matching version goes red, whether or not that project changed.

According to the advisory records in OSV, the database added, between 25 September and 3 October:

The date that matters is a different one. Each GitHub advisory page carries several dates, and the one labelled Published is usually not the one labelled Published to the GitHub Advisory Database.

The fixes came first

Take the two biggest batches.

undici. GHSA-rfgv-xxqx-mfg5 shows "Published Sep 4, 2026" and "Published to the GitHub Advisory Database Sep 29, 2026". The fixed releases, undici 6.28.1, 7.29.1 and 8.10.2, all went up on the npm registry on 4 September. So the patch existed for more than three weeks before npm audit could tell you about it.

axios. GHSA-3pq3-5fj3-cg6v, the HTTP/2 proxy bypass, shows "Published Sep 16, 2026" and "Published to the GitHub Advisory Database Sep 30, 2026". The fix, axios 1.20.0, was on npm from 26 August, three weeks before the advisory itself. All 12 axios advisories in the batch carry that same 16 September publication date. (Two of them also cover the old 0.x line, whose fix, 0.34.0, only landed on 16 September.)

Fix first, advisory second, database entry last. The gap between disclosure and database was about two weeks for axios and three and a half for undici. What made this batch feel like an outbreak was that the last step landed for dozens of advisories in the same three days.

Most of these need a feature you probably don't use

We went through the axios and undici advisories in the batch. A lot of them only fire when you've turned something on:

• axios HTTP/2 proxy bypass needs httpVersion: 2. In axios 1.19.0 the HTTP adapter sets httpVersion = 1 when you don't pass one.
• axios data: URL ReDoS needs you to pass untrusted URL strings straight into axios.
• axios maxRedirects: 0 bypass only matters if you rely on that option as an SSRF guard while using the fetch adapter.
• undici TLS bypass needs BalancedPool with a function-valued connect or tls option.
• undici cookie disclosure needs interceptors.cache(), in its default shared mode, in front of an untrusted or multi-user upstream.

That doesn't mean ignore them. It means npm audit fix is the whole job for most apps, and you don't need to spend an evening proving reachability for each line.

The exception is the one that needs nothing turned on.

The undici bug that kills the process

CVE-2026-19534 (High, 7.5) is a crash in undici's WebSocket client. If a server answers the handshake with a Sec-WebSocket-Protocol header the client never asked for, undici throws a TypeError inside a microtask with no try/catch. That's an uncaught exception, and the Node process exits. The advisory says it hits the default new WebSocket(url), with no subprotocol requested.

It covers undici from 6.7.0 up to the fixed releases. And this is where npm audit stops helping.

Node has its own copy

Node's global WebSocket and fetch don't load undici from your node_modules. They run on a copy compiled into Node itself. You can see its version:

node -p "process.versions.node + ' bundles undici ' + process.versions.undici"

npm audit only reads your lockfile, so it never sees that copy. A project with zero dependencies can pass npm audit and still be running a vulnerable undici.

We crashed it

We wrote a 10-line TCP server that completes a WebSocket handshake and adds Sec-WebSocket-Protocol: evil, then pointed Node's built-in WebSocket at it. No npm packages involved.

So the fix works, and on old Node the crash is real. Your onerror handler doesn't save you either: the throw happens before undici gets as far as calling it.

Going by the bundled copy in each Node release tag, Node 22.23.3 (released 23 September) ships undici 6.28.1, Node 24.21.0 and later ship 7.29.1, and Node 26.12.0 ships 8.11.2. Node 22.23.2 still ships 6.28.0, which is inside the affected range.

The five-minute check

Why AI-built apps sit right in the blast radius

axios is the HTTP client AI assistants reach for by default, and undici arrives through other packages even when you never asked for it. Neither is in a founder's head as "a dependency I chose". So the red report reads like something broke, the natural reaction is to ask the assistant to "fix the vulnerabilities", and the assistant runs npm audit fix and stops.

That handles node_modules. It doesn't touch the Node runtime, and an agent working from the audit output has no reason to look there, because the audit output never mentions it.

A dependency report describes what's in the lockfile, not what's answering requests. Most of the time those line up. This is one of the times they don't.