https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 13:29:40 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-86338 <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&#39;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 == &#34;x&#34;) 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> <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&#39;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 == &#34;x&#34;) 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> https://vulnerability.circl.lu/vuln/fkie_cve-2026-86338 https://vulnerability.circl.lu/vuln/ghsa-h9mg-hh48-hrwv <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&#39;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 == &#34;x&#34;) 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> <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&#39;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 == &#34;x&#34;) 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> https://vulnerability.circl.lu/vuln/ghsa-h9mg-hh48-hrwv