A vulnerability stemming from floating-point arithmetic precision errors exists in the QuickJS engine's implementation of TypedArray.prototype.indexOf() when a negative fromIndex argument is supplied.

* The fromIndex argument (read as a double variable, $d$) is used to calculate the starting position for the search.


* If d is negative, the index is calculated relative to the end of the array by adding the array's length (len) to d:



$$d_{new} = d + \text{len}$$


* Due to the inherent limitations of floating-point arithmetic, if the negative value $d$ is extremely small (e.g., $-1 \times 10^{-20}$), the addition $d + \text{len}$ can result in a loss of precision, yielding an outcome that is exactly equal to $\text{len}$.


* The result is then converted to an integer index $k$: $k = \text{len}$.


* The search function proceeds to read array elements starting from index $k$. Since valid indices are $0$ to $\text{len}-1$, starting the read at index $\text{len}$ is one element past the end of the array.


This allows an attacker to cause an Out-of-Bounds Read of one element immediately following the buffer. While the scope of this read is small (one element), it can potentially lead to Information Disclosure of adjacent memory contents, depending on the execution environment.
Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Thu, 16 Oct 2025 18:15:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'poc', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Thu, 16 Oct 2025 16:00:00 +0000

Type Values Removed Values Added
Description A vulnerability stemming from floating-point arithmetic precision errors exists in the QuickJS engine's implementation of TypedArray.prototype.indexOf() when a negative fromIndex argument is supplied. * The fromIndex argument (read as a double variable, $d$) is used to calculate the starting position for the search. * If d is negative, the index is calculated relative to the end of the array by adding the array's length (len) to d: $$d_{new} = d + \text{len}$$ * Due to the inherent limitations of floating-point arithmetic, if the negative value $d$ is extremely small (e.g., $-1 \times 10^{-20}$), the addition $d + \text{len}$ can result in a loss of precision, yielding an outcome that is exactly equal to $\text{len}$. * The result is then converted to an integer index $k$: $k = \text{len}$. * The search function proceeds to read array elements starting from index $k$. Since valid indices are $0$ to $\text{len}-1$, starting the read at index $\text{len}$ is one element past the end of the array. This allows an attacker to cause an Out-of-Bounds Read of one element immediately following the buffer. While the scope of this read is small (one element), it can potentially lead to Information Disclosure of adjacent memory contents, depending on the execution environment.
Title Heap out-of-bounds read in js_typed_array_indexOf in QuickJS
Weaknesses CWE-125
References
Metrics cvssV4_0

{'score': 5.9, 'vector': 'CVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L'}


cve-icon MITRE

Status: PUBLISHED

Assigner: Google

Published:

Updated: 2025-10-16T18:02:02.585Z

Reserved: 2025-10-15T08:47:41.878Z

Link: CVE-2025-62492

cve-icon Vulnrichment

Updated: 2025-10-16T18:01:37.972Z

cve-icon NVD

Status : Received

Published: 2025-10-16T16:15:39.620

Modified: 2025-10-16T16:15:39.620

Link: CVE-2025-62492

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

No data.