--- title: "CVE-2026-48931 Shouldn't Have Been a CVE" url: https://daily.dev/posts/cve-2026-48931-shouldn-t-have-been-a-cve-vsmdypf65 source_url: https://adventures.nodeland.dev/archive/cve-2026-48931-shouldnt-have-been-a-cve type: article source: "Adventures in Nodeland" published: 2026-07-02T14:03:11.838Z updated: 2026-08-24T06:50:10.094Z tags: ["security", "nodejs"] reading_time: 15 upvotes: 57 comments: 3 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # CVE-2026-48931 Shouldn't Have Been a CVE **[Adventures in Nodeland](https://daily.dev/sources/nodeland)** · 15 min read · 57 upvotes · 3 comments ## Summary Matteo Collina, maintainer of Node.js's HTTP stack and undici, reflects on CVE-2026-48931 — an HTTP/1.1 response queue poisoning issue in http.Agent. He argues the fix (a freeSocketDataGuard) was good hardening but should never have been classified as a CVE, because the underlying race is an inherent HTTP/1.1 protocol property shared by every client, not a Node.js-specific bug. The guard he wrote introduced a publicly observable 'data' listener on idle sockets, which caused node-fetch@2 to emit false ERR_STREAM_PREMATURE_CLOSE errors, breaking Google API auth, Firebase CLI, Backstage, and official Node.js Docker images. A follow-up fix replaced the public listener with an internal onread hook. He also discusses the broader structural problem: AI-generated security reports that pass all surface checks are flooding maintainers, making shallow reviews more likely and causing well-intentioned but misclassified CVEs. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community discussion Top comments from developers on daily.dev. **@qwertydiy** · 5 upvotes > Does the CVE definiation ever per se mater anymore. Most people use sites like exploitdb these days anyways. **@pdfopsdev** · 1 upvotes > The CITGM gap might be the sharpest lesson here: the canary set is curated around actively maintained modules, but abandonment is exactly what makes a regression expensive — node-fetch v2 is not shipping fixes, so everyone downstream was stuck until the onread rework got backported. A canary list weighted by reverse-dependency count would keep v2 near the top no matter how dead its commit history looks. The other underrated observation is the release-channel asymmetry: an ordinary change soaks on Current for weeks before touching LTS, while a security release lands on every line the same day.... ## Similar posts on daily.dev - [Node.js — Node.js 26.3.1 \(Current\)](https://daily.dev/posts/node-js-node-js-26-3-1-current--hp8siu0zv) · Node.js · 3 upvotes · 1 comments - [Node.js — Node.js 26.5.1 \(Current\)](https://daily.dev/posts/node-js-node-js-26-5-1-current--hx951gecs) · Node.js · 25 upvotes · 0 comments - [Node.js — Node.js 24.18.1 \(LTS\)](https://daily.dev/posts/node-js-node-js-24-18-1-lts--w2vuxe7f2) · Node.js · 33 upvotes · 5 comments - [Node.js — Node.js 24.17.0 \(LTS\)](https://daily.dev/posts/node-js-node-js-24-17-0-lts--8fmsqbwyz) · Node.js · 0 upvotes · 0 comments - [Vulnerability or Not a Vulnerability?](https://daily.dev/posts/vulnerability-or-not-a-vulnerability--7nlwcl1io) · JFrog · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#nodejs](https://daily.dev/tags/nodejs) [View this post on daily.dev](https://daily.dev/posts/cve-2026-48931-shouldn-t-have-been-a-cve-vsmdypf65)