<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T21:01:47.202551+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-86338</id>
    <title>fkie_cve-2026-86338</title>
    <updated>2026-09-29T21:01:47.225350+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>Ash field_policies are documented to protect against filter-based information disclosure: when a field the actor may not see is referenced in a filter, it is replaced with an expression that evaluates to nil, so a filter cannot be used as a yes/no oracle to read a value the actor cannot see.</p>
<p>This nilling was applied to attributes but not to calculations or aggregates. A user-supplied filter reference to a calculation or aggregate carries an Ash.Query.Calculation / Ash.Query.Aggregate struct, which the authorizer's reference replacement did not match (it only matched the Ash.Resource.* structs), so the filter ran against the real value.</p>
<p>As a result, an actor whose field policies forbid a calculation or aggregate can still filter by it (for example filter(secret_calc == "x") or filter(comment_count == n)) and learn the value from whether rows match — an oracle that recovers field-policy-protected values one probe at a time. Filtering is commonly exposed to lower-privileged actors (for example via AshGraphql or AshJsonApi filter arguments), which is exactly the surface field policies are meant to protect.</p>
<p>The fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes.</p>
<p>This issue affects ash: from 2.11.0-rc.0 before 3.33.4.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-86338"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-h9mg-hh48-hrwv</id>
    <title>GHSA-h9mg-hh48-hrwv</title>
    <updated>2026-09-29T21:01:47.225452+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>Ash field_policies are documented to protect against filter-based information disclosure: when a field the actor may not see is referenced in a filter, it is replaced with an expression that evaluates to nil, so a filter cannot be used as a yes/no oracle to read a value the actor cannot see.</p>
<p>This nilling was applied to attributes but not to calculations or aggregates. A user-supplied filter reference to a calculation or aggregate carries an Ash.Query.Calculation / Ash.Query.Aggregate struct, which the authorizer's reference replacement did not match (it only matched the Ash.Resource.* structs), so the filter ran against the real value.</p>
<p>As a result, an actor whose field policies forbid a calculation or aggregate can still filter by it (for example filter(secret_calc == "x") or filter(comment_count == n)) and learn the value from whether rows match — an oracle that recovers field-policy-protected values one probe at a time. Filtering is commonly exposed to lower-privileged actors (for example via AshGraphql or AshJsonApi filter arguments), which is exactly the surface field policies are meant to protect.</p>
<p>The fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes.</p>
<p>This issue affects ash: from 2.11.0-rc.0 before 3.33.4.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-h9mg-hh48-hrwv"/>
  </entry>
</feed>
