CVE-2026-82737: Ash-Project Ash Integer Overflow DoS Vulnerability

CVE-2026-82737 Overview

CVE-2026-82737 is an integer overflow vulnerability [CWE-190] in the ash-project/ash Elixir framework. The flaw resides in Ash.Vector.new/1 inside lib/ash/vector.ex, which packs a vector's element count into an unsigned 16-bit field without range validation. An attacker who submits a vector with more than 65,535 elements causes the dimension header to wrap modulo 65,536. The stored value becomes internally inconsistent, and every subsequent read through from_binary/1 misparses and raises. The result is persistent denial of access to the affected record. The issue affects ash from version 2.14.13 before 3.32.2.

Critical Impact
A single oversized vector write permanently corrupts a stored record, causing all future reads to fail and denying application access to that data until the value is manually purged.

Affected Products

ash-project/ash versions >= 2.14.13 and < 3.32.2
Elixir applications using Ash.Vector for vector storage
Downstream services persisting vectors via the Ash framework

Discovery Timeline

2026-09-01 - CVE-2026-82737 published to NVD
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-82737

Vulnerability Analysis

The vulnerability stems from unchecked integer truncation during vector serialization. Ash.Vector.new/1 encodes a list of floats as the binary <<dim::unsigned-16, 0::unsigned-16>> followed by the packed 32-bit floats. The dim value is computed as list |> length() but written into a 16-bit field. When the caller supplies more than 65,535 elements, the length wraps modulo 65,536, so the stored header describes a dimension that disagrees with the actual number of encoded floats.

Later, from_binary/1 reads binary-size(dim)-unit(32) bytes based on the wrapped header. The mismatch between the recorded dimension and the actual float payload causes the binary match to fail on every read. The record raises on decode, blocking application access to that stored value.

Root Cause

The root cause is missing bounds validation before serializing to a fixed-width integer field. Elixir's length/1 returns an unbounded integer, but the encoder silently truncates the value when constructing the unsigned-16 binary segment. No guard rejected inputs whose length exceeded the maximum representable dimension of 65,535.

Attack Vector

Exploitation requires the ability to submit a list of more than 65,535 float elements to any Ash resource attribute backed by Ash.Vector. The attacker does not need authentication if the surrounding application exposes vector inputs to unauthenticated callers. Once written, the corrupted binary persists in the datastore. Every subsequent read of that record fails, producing a durable denial-of-service on the affected row without further attacker action.

text

     new(:erlang.binary_to_list(binary))
   end
 
+  @max_dimensions 65_535
+
   def new(list) when is_list(list) do
     dim = list |> length()
-    bin = for v <- list, into: "", do: <<v::float-32>>
 
-    {:ok, %Ash.Vector{data: <<dim::unsigned-16, 0::unsigned-16>> <> bin, dimensions: dim}}
+    if dim > @max_dimensions do
+      {:error, :invalid_vector}
+    else
+      bin = for v <- list, into: "", do: <<v::float-32>>
+
+      {:ok, %Ash.Vector{data: <<dim::unsigned-16, 0::unsigned-16>> <> bin, dimensions: dim}}
+    end
   rescue
     _ ->
       {:error, :invalid_vector}

Source: ash-project/ash commit cef5eb7. The patch introduces the @max_dimensions 65_535 constant and rejects any input list whose length exceeds that bound, returning {:error, :invalid_vector} before the truncating binary encode occurs.

Detection Methods for CVE-2026-82737

Indicators of Compromise

Application error logs showing repeated match failures or raises originating from Ash.Vector.from_binary/1.
Records that consistently fail to load while adjacent records in the same resource decode normally.
Write requests containing vector payloads with more than 65,535 float elements.

Detection Strategies

Inspect stored Ash.Vector binaries and flag any where the header-declared dimension multiplied by four does not equal the length of the trailing float payload.
Instrument the application layer to log the element count of incoming vector inputs and alert when a request exceeds the 65,535 threshold.
Review dependency manifests (mix.exs, mix.lock) for ash versions in the vulnerable range >= 2.14.13, < 3.32.2.

Monitoring Recommendations

Track error rates and exception traces referencing Ash.Vector decode failures over time.
Monitor request bodies at the ingress layer for oversized array or list parameters bound to vector attributes.
Correlate corrupted-record read failures with the originating write event to identify the source account or client.

How to Mitigate CVE-2026-82737

Immediate Actions Required

Upgrade ash to version 3.32.2 or later across all Elixir services that use the framework.
Audit persisted Ash.Vector values and remove or repair records whose stored dimension disagrees with the payload size.
Add input validation at the application boundary to reject vector inputs longer than 65,535 elements before they reach Ash.

Patch Information

The fix is in commit cef5eb7b0693f04d1699a36e02a4e09ce1e7bffe and shipped in ash3.32.2. See the GitHub Security Advisory GHSA-68q3-w4w3-2gfv and the Erlang Ecosystem Foundation CNA record for the authoritative advisory.

Workarounds

Enforce a maximum list-length check on any user-controlled input mapped to an Ash.Vector attribute before calling Ash.Vector.new/1.
Restrict write access to vector-backed resources to authenticated, trusted callers until the upgrade is deployed.
Add schema-level constraints in upstream validation layers (for example, changeset validations) that cap vector dimensions at 65,535.

bash

# Upgrade ash to the fixed release
mix deps.update ash
# Verify the installed version is >= 3.32.2
mix deps | grep ash