CVE WatchJul 15, 2026

CVE-2026-6388

A flaw was found in ArgoCD Image Updater. This vulnerability allows an attacker, with permissions to create or modify an ImageUpdater resour

CVSS

9.1

Critical

EPSS

0.4%

p29

KEV

—

Exploit Today

0-100

Published: Apr 15, 2026 · Last modified: Jul 15, 2026 · CWE-1220

EPSS · 30d

0.4%EPSS · 30 days0.4%

2026-08-202026-09-17

Technical description

A flaw was found in ArgoCD Image Updater. This vulnerability allows an attacker, with permissions to create or modify an ImageUpdater resource in a multi-tenant environment, to bypass namespace boundaries. By exploiting insufficient validation, the attacker can trigger unauthorized image updates on applications managed by other tenants. This leads to cross-namespace privilege escalation, impacting application integrity through unauthorized application updates.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-86338—

25.2%

——8Ash 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. 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. 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. The fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes. This issue affects ash: from 2.11.0-rc.0 before 3.33.4.1d CVE-2026-774808.8 HIG

43.4%

——13Insufficient granularity of access control in SQL Server allows an authorized attacker to elevate privileges over a network.2d CVE-2026-692676.5 MED

18.5%

——6Insufficient granularity of access control in Windows Connected User Experiences and Telemetry allows an authorized attacker to disclose information locally.13h CVE-2026-668148.8 HIG

35.5%

——11Insufficient granularity of access control in SQL Server allows an authorized attacker to elevate privileges over a network.2d CVE-2026-78230—

16.1%

——5AshAi exposes Ash read actions to language-model tool calls. The read tool accepts an aggregate result type (min, max, sum, avg) that builds an ad-hoc Ash.Query.Aggregate over a named field and returns its raw value. Ash field policies redact forbidden fields on returned records (replacing them with %Ash.ForbiddenField{}), but that redaction does not apply to aggregate values. A tool caller could therefore read a field the calling actor's field policies forbid by requesting it as an aggregate; min/max in particular return an actual field value. This includes fields that are public? true but restricted per-actor by a field policy, such as sensitive PII. The tool's existing check only required the field to be public, which is a separate axis from per-actor field-policy authorization. The fix authorizes the aggregated field against the resource's field policies, so aggregating over a field the actor may not see is refused or scoped to the rows where it is visible. This issue affects ash_ai: from 0.1.0 before 1.0.3.9d CVE-2026-78216—

16.1%

——5AshLua exposes Ash read actions to Lua scripts run through an eval action. A read call accepts an operation (list, min, max, first, sum, avg) that builds an ad-hoc Ash.Query.Aggregate over a named field and returns its raw value. Ash field policies redact forbidden fields on returned records (replacing them with %Ash.ForbiddenField{}), but that redaction does not apply to aggregate values. A script could therefore read a field the calling actor's field policies forbid by requesting it as an aggregate instead of as a field. This includes fields that are public? true but restricted per-actor by a field policy, such as sensitive PII. The prior hardening only enforced the exposed-field allow-list (field visibility), which is a separate axis from per-actor field-policy authorization. The fix authorizes the aggregated field against the resource's field policies, so aggregating over a field the actor may not see is refused or scoped to the rows where it is visible. This issue affects ash_lua: from 0.1.0 before 0.2.2.9d