Argo CD EUVD-2026-43648

The attacker must have network reachability to the Argo CD repo-server service, which by design requires no authentication (CWE-306); this is the core enabling condition. Default deployments of the argo-helm chart before version 10.0.0 shipped with global.networkPolicy.create=false, meaning no NetworkPolicy restricted the repo-server and it was reachable from any pod on the cluster network - exactly the configuration this fix targets. Limiting factors: exploitation is adjacent-network (AV:A), so the attacker needs a position on the cluster/pod network rather than arbitrary internet access; and the escalation from repo-server RCE to deploying malicious resources on managed clusters occurs only 'under certain conditions' (cache manipulation), so full cluster compromise is not guaranteed in every deployment. The vendor vector lists PR:L while the description and CWE-306 imply no authentication is required - treat the auth precondition as unconfirmed and verify with Red Hat.

The signals are strong but partially conflicting and must be reconciled. The vendor CVSS is 8.9 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L), yet both the description ('unauthenticated attacker') and the assigned CWE-306 (Missing Authentication) indicate PR:N rather than the PR:L in the vector - this discrepancy should be verified with Red Hat, and if PR:N holds the real severity is higher than 8.9. The vector's AV:A (adjacent) is consistent with repo-server being an internal cluster service rather than an internet-facing endpoint, which is the single biggest limiting factor on real-world risk. No KEV listing and no confirmed public exploit code mean this is not yet confirmed actively exploited; however, a public CodeQL-based research write-up (Synacktiv) and a 'unpatched flaw' news article materially raise the odds of near-term exploit development. No EPSS score was provided, so probabilistic exploitation likelihood is unknown. Net: this is a genuine high priority for any Kubernetes environment running Argo CD/OpenShift GitOps because impact is cluster-wide (scope change) and preconditions are modest for anyone with a foothold on the cluster network - but it is not an internet-wide, unauthenticated-from-anywhere emergency on the level of an externally exposed AV:N RCE.

An attacker who has landed a low-privilege pod or otherwise gained access to the Kubernetes cluster network reaches the unauthenticated Argo CD repo-server and sends crafted input that triggers code execution within that component. Using that foothold they tamper with cached rendered manifests so that the application controller subsequently deploys attacker-chosen Kubernetes resources (e.g., privileged workloads) across managed clusters, escalating to full cluster compromise. No public exploit code is identified at time of analysis, though a detailed technical write-up (Synacktiv, using CodeQL) is publicly available.