CVE-2026-70395
lowpriority · track · 0EPSS 0.002 · 9 %ileEUUSEPSS · scored 2026-10-27
Improper Neutralization of Special Elements in Data Query Logic vulnerability in ash-project ash allows an attacker to forge a relationship to a record they cannot name, and to recover the secret value used to look it up. When manage_relationship is used with on_lookup: :relate on a belongs_to relationship, the client-supplied lookup value is passed to Ash.Query.filter/2 without being cast to the attribute type. A nested map submitted where a scalar is expected is therefore interpreted as a filter predicate rather than a literal, so a lookup for a specific record becomes a query for any record matching a condition. The same path omits Ash.Query.limit(1), leaving Ash.read_one/2 able to distinguish no match from one match from several, which turns comparison predicates into an oracle for the lookup value. Authorization is unaffected; the destination read policy still applies. This issue affects ash: from 1.52.0-rc.11 before 3.31.1.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (3)
Products and version ranges known to be affected.
advisories (1)
Vendor and ecosystem advisories describing this.
- EEF-CVE-2026-70395Predicate injection in manage_relationship belongs_to lookup discloses secret lookup keys in Ash2026-08-09vendor · osvUS
## Summary Improper Neutralization of Special Elements in Data Query Logic vulnerability in ash-project ash allows an attacker to forge a relationship to a record they cannot name, and to recover the secret value used to look it up. When `manage_relationship` is used with `on_lookup: :relate` on a `belongs_to` relationship, the client-supplied lookup value is passed to `Ash.Query.filter/2` without being cast to the attribute type. A nested map submitted where a scalar is expected is therefore interpreted as a filter predicate rather than a literal, so a lookup for a specific record becomes a query for any record matching a condition. The same path omits `Ash.Query.limit(1)`, leaving `Ash.read_one/2` able to distinguish no match from one match from several, which turns comparison predicates into an oracle for the lookup value. Authorization is unaffected; the destination read policy still applies. This issue affects ash: from 1.52.0-rc.11 before 3.31.1. ## Configurations A `belongs_to` relationship must be managed with `manage_relationship` using `on_lookup: :relate`, and the lookup value must come from client input.
also known as (3)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (12)
External citations — patches, advisories, analysis.
- https://cna.erlef.org/cves/CVE-2026-70395.htmlcnnvd
- https://github.com/ash-project/ash/commit/09f42593035bceb0f6153dd7ee45cc49d108300acnnvd
- https://github.com/ash-project/ash/security/advisories/GHSA-vvp6-3wv6-833jcnnvd
- https://osv.dev/vulnerability/EEF-CVE-2026-70395cnnvd
- https://cna.erlef.org/cves/CVE-2026-70395.htmlenisa_euvd
- https://github.com/ash-project/ash/commit/09f42593035bceb0f6153dd7ee45cc49d108300aenisa_euvd
- https://github.com/ash-project/ash/security/advisories/GHSA-vvp6-3wv6-833jenisa_euvd
- https://osv.dev/vulnerability/EEF-CVE-2026-70395enisa_euvd
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan