CVE-2026-67579 is a high severity (CVSS 7.4) flaw in Ash, the Elixir framework. A forged keyset pagination cursor can inject a filter expression, leading to SQL injection on AshPostgres or code execution on other data layers. Upgrade to Ash 3.31.3 or later.
What's affected
The record names the product as Ash but gives no version range. The GitHub advisory (GHSA-3gq3-9xm3-c8v3) fills it in: Ash 1.17.0 and later, before 3.31.3, with 3.31.3 as the patched version.
Severity differs. The record scores it 7.4 (High). The advisory labels it High at 7.5 using a CVSS 4.0 rating. Both are High, and the small score gap comes from different scoring versions.
The advisory states no authentication is needed, as long as the attacker can reach a read action that exposes keyset pagination. It also states that this is data layer dependent: SQL injection on AshPostgres, and in-process code execution on the ETS and Simple data layers. It says there is no mitigation other than the framework fix.
How to check if you're exposed
mix deps | grep ash
grep ash mix.lock
The lock file records the exact resolved version, so check it rather than the version range in mix.exs.
Then find read actions that use keyset pagination:
grep -rn "keyset" lib/
Any action with keyset pagination that is reachable over an API, such as a GraphQL or JSON API route, is a candidate. Note which data layer each resource uses, since that decides the impact described in the advisory.
A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.
What to do now
- Upgrade Ash to 3.31.3 or later and rebuild your release.
- List resources with keyset pagination and the endpoints that expose them.
- Check your logs for unusual or oversized page cursor parameters on those endpoints.
- If you cannot upgrade immediately, consider temporarily switching exposed actions to offset pagination. The advisory says only the framework fix closes this, so treat that as risk reduction, not a cure.
- Run your application database user with the least privilege it needs, to limit what an injected query could do.
Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.
Why it matters
There are two weaknesses here. CWE-502 is deserialization of untrusted data, and CWE-89 is SQL injection. The cursor is decoded with a safe mode that blocks new atoms, functions and ports. That is not enough, because a structure built from atoms that already exist in the running application survives decoding.
The decoded element was then spliced into the query filter as a plain value and evaluated, skipping the checks that normally reject private expressions. The lesson is general: a cursor the client sends back is client input, even if your server created it. Sign it or validate its shape. The record does not mark this CVE as known exploited.
Try it yourself
This demo shows how to judge whether a vulnerability is practically exploitable in your own application, not only on paper.
Click through it at your own pace, or open it full screen.
Quick check
Does it matter which data layer I use?
Yes. The advisory describes SQL injection on AshPostgres and in-process code execution on the ETS and Simple data layers.
Is authentication a barrier?
The advisory says no authentication is required, provided the attacker can reach a read action with keyset pagination.
Sources
- https://github.com/ash-project/ash/security/advisories/GHSA-3gq3-9xm3-c8v3
- Record: NVD entry for CVE-2026-67579 (score 7.4, HIGH)
Last reviewed: 18 October 2026.
