Argo CD fixes critical ServerSideDiff bug that exposed Kubernetes secrets

Argo CD has patched a serious ServerSideDiff vulnerability that could let a low-privileged user read Kubernetes Secrets in cleartext. The flaw is tracked as CVE-2026-43824 and affects Argo CD 3.2 and 3.3 releases before the fixed versions.

The issue allows a user with Argo CD application read access to extract sensitive data from managed Kubernetes Secret resources. That can include service account tokens, TLS certificates, database passwords, and API keys.

Administrators should upgrade to Argo CD 3.2.11 or 3.3.9 immediately. The risk is highest in environments where applications use ServerSideDiff with the IncludeMutationWebhook=true compare option and where read-only users or automation tokens can view application state.

What CVE-2026-43824 is

CVE-2026-43824 is a missing authorization and data-masking issue in Argo CD’s ServerSideDiff endpoint. Argo CD normally masks Kubernetes Secret data before returning resource state through its APIs.

The vulnerable ServerSideDiff path did not apply the same masking. As a result, a response could include raw Secret values returned by the Kubernetes API server during a server-side apply dry-run.

This creates a control-plane data leak. A user may not have direct Kubernetes RBAC permission to read Secrets, but they can still receive secret data through Argo CD if they have the right Argo CD application permissions.

At a glance

Detail	Information
CVE	CVE-2026-43824
Advisory ID	GHSA-3v3m-wc6v-x4x3
Affected product	Argo CD
Affected versions	3.2.0 through 3.2.10 and 3.3.0 through 3.3.8
Fixed versions	3.2.11 and 3.3.9
GitHub advisory rating	Critical, CVSS 9.6
CVE record rating	High, CVSS 7.7 from MITRE
Main impact	Cleartext Kubernetes Secret exposure
Access needed	Argo CD application get permission

How the secret leak happens

Argo CD’s ServerSideDiff feature asks the Kubernetes API server to calculate what a resource would look like after a server-side apply dry-run. This helps Argo CD show more accurate diffs, especially when admission controllers or mutation webhooks change resources.

The security problem appears when Argo CD builds the diff response from unmasked predicted and normalized live states. Other Argo CD endpoints call the masking function for Secrets, but the vulnerable ServerSideDiff path did not.

The advisory says Argo CD also has a secondary protection layer that removes mutation webhook changes. That layer is skipped when an application uses the argocd.argoproj.io/compare-options annotation with IncludeMutationWebhook=true.

Why IncludeMutationWebhook=true matters

By default, Server-Side Diff does not include changes made by mutation webhooks. Argo CD supports IncludeMutationWebhook=true for teams that want webhook changes included in diff results.

That option can be useful in real Kubernetes environments, especially where tools mutate workloads during admission. However, in affected Argo CD versions, the same path can expose Secret values when the masking gap is present.

Security testing from Juliet found that a read-only Argo CD account with applications get access could reproduce cleartext Secret exposure when IncludeMutationWebhook=true was present. After upgrading to 3.2.11 or 3.3.9, the same path returned masked Secret data.

Who is most exposed

• Organizations running Argo CD 3.2.0 through 3.2.10.
• Organizations running Argo CD 3.3.0 through 3.3.8.
• Applications using IncludeMutationWebhook=true.
• Applications that manage Kubernetes Secret resources.
• Teams that give CI/CD tools read-only Argo CD tokens.
• Clusters where many users can view Argo CD application state.
• Multi-tenant Argo CD setups with broad default read access.

Why read-only access is not harmless

Many teams treat read-only Argo CD access as safe because users cannot sync applications, change manifests, or update cluster resources. This vulnerability shows why that assumption can fail.

Argo CD sits between Git and Kubernetes. It knows what an application should look like, what exists in the cluster, and how both states differ. That makes its read APIs more sensitive than a normal dashboard view.

If an Argo CD token can read application state, and that state includes managed Secrets, the token may become a path to secret extraction in affected versions. Kubernetes RBAC alone does not fully answer that risk.

What attackers could steal

Secret type	Potential impact
Service account tokens	Cluster access, lateral movement, and API abuse
Database passwords	Unauthorized access to application data
TLS certificates and private keys	Impersonation, traffic interception, and trust abuse
Cloud credentials	Access to storage, compute, registries, or control planes
Third-party API keys	Fraud, data theft, service abuse, or account takeover

What administrators should do now

The main fix is simple: upgrade affected Argo CD deployments. Version 3.2.11 fixes the 3.2 branch, and version 3.3.9 fixes the 3.3 branch.

Teams that cannot patch immediately should remove or disable IncludeMutationWebhook=true on applications until they can upgrade. This mitigation reduces the known exposure path, but it should not replace the patched release.

Security teams should also review Argo CD RBAC. Application read access should go only to users, groups, and automation tokens that truly need it.

Recommended response checklist

• Check every Argo CD instance for its current version.
• Upgrade 3.2.x deployments to 3.2.11.
• Upgrade 3.3.x deployments to 3.3.9.
• Search all Applications for IncludeMutationWebhook=true.
• Identify Applications that manage Kubernetes Secrets.
• Review users and tokens with applications get access.
• Rotate secrets that may have been exposed through Argo CD.
• Check Argo CD API logs for unusual ServerSideDiff activity.
• Reduce broad default read access in multi-tenant environments.

Why secret rotation may be necessary

Upgrading stops the vulnerable behavior, but it does not undo previous exposure. If an attacker already used the flaw, they may still have copied tokens, passwords, certificates, or API keys.

Teams should prioritize rotating secrets from applications that meet the risky pattern: affected Argo CD version, managed Secrets, IncludeMutationWebhook=true, and broad application read access.

High-value credentials deserve priority. That includes cloud keys, production database passwords, registry credentials, and service account tokens with wide cluster permissions.

What this means for GitOps security

Argo CD is a powerful control plane for Kubernetes deployments. It continuously compares the live state of applications with the desired state stored in Git and helps teams keep clusters in sync.

That same visibility makes Argo CD a sensitive system. If its APIs expose more state than intended, attackers may gain access to data they could not read through Kubernetes directly.

This incident is a reminder that GitOps permissions need the same care as Kubernetes permissions. Read-only access can still expose secrets when the control plane holds or returns sensitive state.

FAQ