Unrelated memory a small Buffer can copy into output: Up to 64 KB (Source: GitHub Advisory Database, GHSA-j22f-vq7h-c4qm (October 1, 2026))
The page that carries more than it was asked to
Most security incidents involve someone breaking in. This one involves a website handing over more than it meant to, in its own ordinary output. No attacker has to defeat a login. A visitor only has to load a public page.
The GitHub Advisory Database published the flaw on October 1, 2026. It affects devalue, a JavaScript library that turns server data into text so it can be sent to the browser. The advisory names SvelteKit and Nuxt as server-rendered frameworks where the problem can appear. It links to CVE-2026-92708.
How the flaw works
devalue's `stringify` and `uneval` functions package data for transport. When they meet a typed array, a block of raw bytes, they do not copy only the bytes the code asked for. They emit the whole backing ArrayBuffer, the larger block of memory the array is a window onto.
In Node.js, a Buffer is a common kind of byte container. Small Buffers do not each get their own memory. They share one process-wide pool. So serializing a tiny Buffer can copy up to 64 KB of whatever else sits in that pool.
The advisory says that can include bytes from other in-flight requests. Its example is a public page whose `load()` function returns a 2-byte Buffer. A small file read with `readFileSync` can do the same. The advisory says the result can put another user's request body or Authorization header into the page's HTML.
Why this is easy to miss
The advisory describes the leak as unauthenticated and silent. Nothing fails, so no error appears in a log. The page renders and looks normal.
It also sits on the output side. The advisory says the library's existing guards against prototype pollution and denial of service, which protect parsing, do not apply here. The problem fires on every server render, not only when the site handles untrusted input.
This belongs to a familiar family of bugs, like Heartbleed: a program returns more memory than it was asked for. The lesson is that a safe-looking public page can still carry private data. What leaks depends on what else the server was doing at that moment.
Who carries the risk
The people exposed are not the site's own visitors reading that page. They are other users whose requests happened to be in memory at the time. Their form submissions or authorization headers could end up in someone else's HTML.
The advisory does not say how often this happens in real deployments. It does not report exploitation in the wild. It describes what a vulnerable page can do. Whether your sites are affected depends on your devalue version and on whether your code serializes Buffers.
What to ask your team
The advisory's remediation is to convert Node Buffer objects to Uint8Array before serializing. It also links to the devalue v5.9.3 release. Put these questions to your engineers:
First, do any of our server-rendered applications, in SvelteKit, Nuxt or elsewhere, depend on devalue? Ask for the installed version, including indirect dependencies.
Second, does any page-loading code return a Buffer or read files with `readFileSync`? Those are the cases the advisory describes.
Third, if a page was exposed, what could have been in memory beside it? Authorization headers suggest that tokens may need to be rotated. Your security team can judge that.
A page can be public and still carry private data. Ask your team to check which pages are built from raw memory.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
