devalue EUVD-2026-119454

Exploitation requires that a true JavaScript sparse array (an array with holes/empty slots) be created on the server AND then serialized via devalue's uneval or stringify functions. The vendor explicitly states the chief limiting factor: mainstream wire formats (JSON, form/query encoding) cannot represent sparse arrays, so an attacker cannot simply submit one over the network - the sparse array must arise from server-side logic the attacker can influence. There is no authentication requirement in the supplied PR:N vector, but the practical barrier (reaching a code path that both constructs a sparse array server-side and passes it to devalue serialization) is substantial and application-specific. Affected: devalue <= 5.6.2; the only complete fix is upgrading to 5.6.3.

The signals point to a severity-vs-real-risk gap. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) with VA:H yields an 8.7 (High) score driven entirely by availability impact, but the advisory itself states exploitation is 'extremely difficult to take advantage of in practice' because an attacker must first get a sparse array created on the server - something the GHSA explicitly says is 'impossible in every mainstream wire format' (JSON, form-encoding, query strings, etc. cannot represent array holes) - and that array must then be passed through devalue's uneval or stringify. This precondition is a strong real-world limiter that the input's AC:L/AT:N does not capture; the base vector arguably understates attack requirements. No CISA KEV listing and no EPSS score are provided, and no PoC or exploit reference appears in the input (only vendor/VulnCheck advisories), so there is no public exploit identified at time of analysis and no evidence of active exploitation. The vuln.today decision label is 'this_week' rather than act_now/emergency, consistent with a patchable, non-emergency DoS. Net: this is a legitimate availability bug worth patching on a normal cadence, not a high-urgency actively-exploited threat; the headline 8.7 overstates practical risk given the sparse-array precondition.

An application using devalue serializes server-side state to the client with uneval or stringify; if an attacker can influence that state such that a genuine JavaScript sparse array (one with holes) is constructed on the server, serializing it triggers CPU and/or memory amplification that exhausts the Node.js process and denies service. In practice this requires a code path that both creates a sparse array server-side and feeds it to devalue, since standard wire formats cannot transmit sparse arrays. No public exploit code is identified at time of analysis.