GHSA-j22f-vq7h-c4qm CVE-2026-92708
devalue: `stringify`/`uneval` serialize shared memory
- Severity
- 7.5 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.73%
- Chance of exploitation in the next 30 days. Higher than 54.09% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
- CWE-226 Sensitive Information in Resource Not Removed Before Reuse
- Fix
5.9.3- Upgrade devalue to this version or later
Description
Impact
stringify and uneval serialize a typed array by emitting its backing ArrayBuffer, not just the view. In the case of a Node Buffer object, the backing buffer is a process-wide shared pool, meaning unrelated memory can be serialized into a response that is then sent to the client. For a Node Buffer the backing store is Node's process-wide shared pool, so serializing a small Buffer copies up to 64 KB of unrelated process memory — including bytes from other in-flight requests — into the output. In an SSR framework (SvelteKit, Nuxt) a public page whose load() returns a 2-byte Buffer, or a small file read with readFileSync, ships another user's request body / Authorization header in its HTML. Unauthenticated, silent, ~43,000× amplification.
This is serialization-side, so the parse/unflatten prototype-pollution and DoS guards do not apply — it fires on every SSR render, not only when parsing untrusted input.
Workarounds
Convert Node Buffer objects to Uint8Array:
payload = {
- buffer
+ buffer: new Uint8Array(buffer)
}
Affected versions
npm
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
devalue npm → 5.9.3
- npm
npm install devalue@5.9.3- yarn
yarn add devalue@5.9.3- pnpm
pnpm add devalue@5.9.3
Severity breakdown
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
How to prevent it
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CWE-226: Sensitive Information in Resource Not Removed Before Reuse
The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.
How to prevent it
- Architecture and Design, Implementation: During critical state transitions, information not needed in the next state should be removed or overwritten with fixed patterns (such as all 0's) or random data, before the transition to the next state.
- Architecture and Design, Implementation: When releasing, de-allocating, or deleting a resource, overwrite its data and relevant metadata with fixed patterns or random data. Be cautious about complex resource types whose underlying representation might be non-contiguous or change at a low level, such as how a file might be split into different chunks on a file system, even though "logical" file positions are contiguous at the application layer. Such resource types might require invocation of special modes or APIs to tell the underlying operating system to perform the necessary clearing, such as SDelete (Secure Delete) on Windows, although the appropriate functionality might not be available at the application layer.
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-hx4r-w6wj-j8fg devalue: Residual sparse-array CPU amplification in uneval | Medium | Also affects devalue |
| GHSA-mcm9-63f2-9j32 devalue: Repeated primitive strings cause quadratic expansion in uneval | High | Also affects devalue |
| GHSA-wf3x-273g-mvxv devalue: Sparse arrays emitted by uneval cause eager allocation when evaluated | Low | Also affects devalue |
| GHSA-r9w8-h9r3-54w4 devalue: Custom ArrayBuffer revivers can bypass typed-array allocation validation | High | Also affects devalue |
| GHSA-x5rw-q4pp-hg5g devalue: stringifyAsync can cause an unhandled rejection despite a caught returned promise | High | Also affects devalue |
| GHSA-4q55-j62x-fr9h devalue: Malformed null-prototype object keys bypass __proto__ rejection via property-key coercion | Medium | Also affects devalue |
| GHSA-9rgm-9g3h-6x36 Svelte devalue: DoS via malformed input | Medium | Also affects devalue |
| GHSA-77vg-94rm-hx3p Svelte devalue: DoS via sparse array deserialization | High | Also affects devalue |
Credits: LipezJ, elliott-with-the-longest-name-on-github
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor