QuickJS CVE-2025-62496

Exploitation requires the embedding application to pass attacker-controllable input into QuickJS BigInt string parsing (js_bigint_from_string) AND to permit an extremely large input - a decimal (radix-10) string of approximately 79,536,432 digits or more (on the order of 80 MB) needed to overflow the signed 32-bit computation (n_digits*27+7). The primary limiting factors are: (1) the application must accept/forward multi-tens-of-megabytes strings to BigInt conversion, which default input-size limits or sane application validation will prevent; (2) reliable code execution (beyond a crash) requires heap grooming, reflected in the High attack complexity; (3) the published vector further constrains exploitation to adjacent access, low privileges, and passive user interaction, implying a particular deployment rather than open remote script execution. Against an embedding that freely runs untrusted scripts with no input-size cap, the effective barrier is chiefly the massive-input requirement and exploit reliability, not authentication.

Signals are mixed and point to a moderate, non-urgent priority rather than an emergency. The input CVSS 4.0 base score is 7.1 (High) with a notably constrained vector (AV:A adjacent, AC:H, AT:P, PR:L, UI:P), meaning the provider modeled this as requiring adjacent network access, high complexity, a specific attack condition, low privileges, and passive user interaction - a demanding chain, not trivial remote exploitation. CWE-190 (integer overflow) leading to a heap out-of-bounds write is memory corruption with code-execution potential, which raises impact. Countervailing the severity: there is NO CISA KEV listing (no confirmed active exploitation) and no EPSS score was provided, so exploitation-probability cannot be quantified from the input. A public POC does exist (Google issue tracker 434193016, reported by Google's CVE coordination team), so the bug is understood and reproducible, but POC availability is distinct from in-the-wild use. A key limiting factor largely independent of the CVSS vector is the trigger condition itself: it requires parsing a BigInt from a string of roughly 79,536,432+ decimal digits (an ~80 MB input), which most applications will never accept from untrusted sources. CONFLICT TO VERIFY: a JavaScript-engine memory-corruption bug triggered purely by script execution would normally be modeled network-reachable and unauthenticated (AV:N/PR:N), yet the supplied 4.0 vector uses AV:A/PR:L/UI:P - this discrepancy suggests the published metrics reflect a specific embedding/deployment assumption rather than the generic 'engine runs untrusted script' case; verify the intended attack surface with the embedder/vendor.

An attacker who can supply JavaScript (or a BigInt string input) to an application embedding QuickJS crafts a script that calls BigInt parsing on a decimal string of ~79.5 million or more digits, triggering the 32-bit integer overflow in js_bigint_from_string, which under-allocates the JSBigInt limb buffer and then writes past it, corrupting the heap. A public proof-of-concept exists on Google's issue tracker, so the trigger is documented and reproducible; successful weaponization to code execution would still require heap grooming, consistent with the High attack complexity in the CVSS vector.