A critical vulnerability in Argo CD’s ServerSideDiff endpoint, tracked as CVE-2026-42880 and scored CVSS 9.6, allows any authenticated user with read-only access to extract plaintext Kubernetes Secret data directly from etcd through the Kubernetes API server’s Server-Side Apply dry-run mechanism.
Organizations running Argo CD versions 3.2.0 through 3.3.8 are exposed and must patch immediately to versions 3.3.9 or 3.2.11, both released on April 30, 2026.
Disclosed publicly as GHSA-3v3m-wc6v-x4x3 and credited to researcher hoang-prod, the flaw stems from a missing authorization and data-masking gap inside the ServerSideDiff gRPC/REST endpoint (/application.ApplicationService/ServerSideDiff).
Unlike every other Argo CD API endpoint GetManifests, GetManifestsWithFiles, GetResource, and PatchResource all of which call hideSecretData() to mask Kubernetes Secret values before returning data, the ServerSideDiff handler was added to the 3.2.x codebase without this critical masking call.
CVE-2026-42880: Argo CD ServerSideDiff Vulnerability
The result is that the endpoint constructs its response using raw, unmasked PredictedLive , and NormalizedLive states, exposing a complete secret .data fields to any caller that can reach the API endpoint. This single missing line of code for an uncalled function drives a CVSS score of 9.6 and enables full cluster credential exposure.
Argo CD does have a partial defense mechanism called removeWebhookMutation(), which normally strips non-Argo CD-managed fields from the Server-Side Apply (SSA) dry-run response and merges them with the client-provided, masked live state.
This defense prevents real Secret values from leaking unless the targeted Application carries the annotation argocd.argoproj.io/compare-options: IncludeMutationWebhook=true.
When IncludeMutationWebhook=true is set, the ignoreMutationWebhook flag becomes false, and the removeWebhookMutation() Defense is entirely skipped:
if o.ignoreMutationWebhook {
predictedLive, err = removeWebhookMutation(predictedLive, live, o.gvkParser, o.manager)
}The raw Kubernetes SSA dry-run response containing real Secret values read directly from etcd is returned in the API response with no masking.
For extraction to succeed, the Secret’s .data fields must be owned by at least one non-Argo CD SSA field manager, such as kube-controller-manager (common for service account tokens) or external-secrets-operator.
When a second field manager exists, the API server includes those field values in the merged dry-run response, and Argo CD hands them back to the attacker in base64-encoded, trivially decodable form.
The severity of CVE-2026-42880 is compounded by its extremely low privilege requirement. Any authenticated Argo CD user with applications get access to the default role: catch-all policy is sufficient to trigger the exploit. No admin credentials, no special tooling, or victim interaction are required.
The categories of sensitive data exposed through this vulnerability include:
- Service account tokens owned by
kube-controller-manager - TLS certificates and private keys managed by cert-manager or similar operators
- Database passwords synced by external-secrets-operator
- API keys and third-party service credentials
- Repository credentials stored as Kubernetes Secrets
The CVSS Scope: Changed (S:C) metric in the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N reflects this cascading impact: an attacker who begins with a compromised Argo CD viewer token ends up with credentials that reach far beyond the Argo CD system itself, often granting access to production databases, cloud providers, and third-party APIs.
The most realistic threat scenario involves opportunistic lateral movement after a CI/CD service account token, frequently found in GitHub Actions logs, build artifacts, or misconfigured secrets vaults, is leaked.
The official proof-of-concept (PoC) published alongside the advisory demonstrates automated extraction of all managed secrets in an application via the gRPC endpoint, covering service account tokens, TLS certificates, and database credentials, in under 2 minutes using only basic tooling.
Affected Versions
| Branch | Vulnerable Range | Patched Version |
|---|---|---|
| Argo CD 3.3.x | 3.3.0 – 3.3.8 | 3.3.9 |
| Argo CD 3.2.x | 3.2.0 – 3.2.10 | 3.2.11 |
Organizations should upgrade immediately using Helm or raw manifests. For Helm-based deployments:
helm upgrade argocd argo/argo-cd --version 3.3.9 -n argocdIf upgrading is not immediately possible, the safest interim mitigation is to remove the IncludeMutationWebhook=true annotation from all affected applications. Administrators can audit exposed applications cluster-wide using:
kubectl get applications -A -o json | jq '.items[] | select(.metadata.annotations["argocd.argoproj.io/compare-options"] | contains("IncludeMutationWebhook=true")) | .metadata.name'Additionally, teams should review ArgoCD audit logs for unexpected calls to /api/v1/applications/*/resource-tree/diff from service accounts outside normal deployment windows, which may indicate exploitation attempts.
As a longer-term hardening measure, project-level RBAC should restrict which accounts can view which applications, ensuring not every CI/CD job holds access to production application diffs.
The vulnerability is classified under two CWEs: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-212 (Improper Removal of Sensitive Information Before Storage or Transfer).
The fix implemented in 3.3.9 and 3.2.11 is architecturally simple, a single hideSecretData() call added to the ServerSideDiff response handler, confirming that this was a gap in code review during the feature’s introduction in the 3.2.x development cycle rather than a systemic design flaw.
No evidence of active in-the-wild exploitation has been published as of May 2026. Still, the low barrier to entry makes this vulnerability highly actionable for attackers once the advisory is public.
FAQ
Q1: Does this vulnerability affect Argo CD v2.x users?
No CVE-2026-42880 exclusively affects Argo CD 3.2.0 through 3.3.8, as the vulnerable ServerSideDiff feature with IncludeMutationWebhook=true support was introduced only in the 3.x series.
Q2: Is the vulnerability exploitable without the IncludeMutationWebhook=true annotation?
The annotation is required to bypass the removeWebhookMutation() defense; without it, secret values are still filtered out from the SSA dry-run response in most cases.
Q3: Can disabling ServerSideDiff globally mitigate the vulnerability without upgrading?
Removing the IncludeMutationWebhook=true annotation is the most targeted workaround, though patching to 3.3.9 or 3.2.11 remains the only complete remediation recommended by the Argo CD team.
Q4: What CVSS score is assigned to CVE-2026-42880, and why is it rated so high?
It carries a CVSS score of 9.6 (Critical) due to network-accessible exploitation, low privilege requirements, no user interaction, changed scope, and a high confidentiality and integrity impact across the broader Kubernetes cluster.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
