CVE-2026-82737 in ash
Summary
by MITRE • 09/01/2026
Integer Overflow or Wraparound vulnerability in ash-project ash lets an attacker corrupt a stored vector and crash later reads of it by submitting a vector with more than 65,535 elements.
Ash.Vector.new/1 (lib/ash/vector.ex) encodes a vector as <<dim::unsigned-16, 0::unsigned-16>> followed by the element floats, packing the element count into a 16-bit field without checking its range. A list of more than 65,535 elements wraps the dimension modulo 65,536, so the encoded header records a dimension that disagrees with the number of stored floats. from_binary/1 later reads binary-size(dim)-unit(32) from the wrapped header, so every read of the corrupted value misparses and raises, denying access to the affected record. The fix rejects any vector whose dimension exceeds 65,535.
This issue affects ash: from 2.14.13 before 3.32.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified as an integer overflow or wraparound in the Ash project impacts versions ranging from 2.14.13 up to, but not including, version 3.32.2. This flaw resides within the core data structure handling mechanism for vectors, specifically in the function responsible for initializing new vector instances. The root cause is a failure to validate input constraints during the serialization process. When an attacker submits a vector containing more than sixty-five thousand five hundred and thirty-six elements, the system attempts to encode this dimension into a sixteen-bit unsigned integer field. Because a sixteen-bit field can only represent values from zero to sixty-five thousand five hundred and thirty-five, any value exceeding this limit undergoes modular arithmetic wrapping. This results in the stored header recording a dimension that is mathematically congruent modulo sixty-five thousand five hundred and thirty-six but bears no relation to the actual number of floating-point elements present in the data payload.
This discrepancy between the recorded dimension and the actual element count creates a critical state inconsistency within the application's memory management logic. When subsequent operations attempt to deserialize or read this corrupted vector, they rely on the header information rather than recalculating the size from the raw binary data. The deserialization function reads a specific number of bytes based on the wrapped dimension value, which is significantly smaller than the actual amount of data stored for large vectors. Consequently, the parser misinterprets the binary stream, leading to immediate parsing errors and runtime exceptions whenever the affected record is accessed. This effectively denies access to the underlying data, causing service disruptions or application crashes that can be triggered remotely if user input flows directly into this vector initialization function without adequate sanitization.
From a security classification perspective, this vulnerability aligns with CWE-190, which describes integer overflow or wraparound errors leading to unexpected behavior. The operational impact is primarily categorized under Denial of Service, as the exploitation results in application instability and data unavailability rather than direct code execution or privilege escalation. In terms of adversary tactics, this flaw could be leveraged within ATT&CK technique T1499, Endpoint Denial of Service, by repeatedly submitting oversized vectors to exhaust system resources through repeated crash cycles or error handling overhead. It also touches upon CWE-20, Improper Input Validation, as the application fails to enforce maximum length constraints on user-supplied data structures before processing them into internal formats.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The primary remediation is to upgrade the Ash project dependency to version 3.32.2 or later, where the developers have implemented explicit range checks that reject any vector dimension exceeding sixty-five thousand five hundred and thirty-five elements before serialization occurs. For environments unable to immediately update dependencies, input validation layers should be introduced at the API boundary to enforce strict size limits on array-like inputs destined for vector construction. Additionally, implementing comprehensive logging around these specific data structures can aid in detecting attempted exploitation patterns characterized by unusually large payload sizes. Regular security audits of third-party libraries are essential to identify similar integer handling flaws that may compromise system integrity and availability.