Skip to content

GHSA-j22f-vq7h-c4qm CVE-2026-92708

devalue: `stringify`/`uneval` serialize shared memory

High npm
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

PackageVulnerableFixed in
devalue
>= 5.1.0, <= 5.9.2
No fix yet
devalue
>= 5.1.0, < 5.9.3
5.9.3

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

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy 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

Is this in your code?

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