Argo CD diff endpoint leaks raw Kubernetes Secret values

TL;DR - Argo CD's ServerSideDiff endpoint skips secret masking and returns raw Kubernetes Secret values in its diff output when an application has argocd.argoproj.io/compare-options: IncludeMutationWebhook=true set. Read-only Argo CD access is sufficient. Patch to 3.2.11 or 3.3.9.

What happened

Argo CD is a GitOps controller for Kubernetes - it continuously compares desired state in Git against live cluster state and reconciles the difference. One of its comparison mechanisms is ServerSideDiff (/application.ApplicationService/ServerSideDiff), which performs a Kubernetes Server-Side Apply dry-run to predict what a sync would change.

The problem is a masking gap specific to that endpoint. Most Argo CD surfaces that return resource state call hideSecretData() to redact Secret values before sending them to the caller. ServerSideDiff builds its response from raw PredictedLive and NormalizedLive fields - and never calls the masking function.

Argo CD has a second line of defence here: removeWebhookMutation() strips out changes introduced by admission webhooks before the response is returned. That function is skipped when the Application carries IncludeMutationWebhook=true. With that annotation present, the Server-Side Apply dry-run response can include Secret values read from etcd via the Kubernetes API server, and those values flow back to the caller verbatim.

Scoring is inconsistent across sources: the GitHub advisory rates this Critical at CVSS 3.1 9.6, while the CVE record lists CVSS 3.1 7.7 (High). Set that debate aside - the primitive is direct Secret exfiltration from your delivery control plane. Treat it as high priority.

Diff endpoints tend to get treated as safe, read-only APIs. This one can become a secrets oracle. Argo CD typically has broad cluster visibility, so an over-permissioned read token can turn into credential spill across workloads.

Who is impacted

• Argo CD 3.2.0 through 3.2.10, and 3.3.0 through 3.3.8.
• Any environment where users can call ServerSideDiff via Argo CD RBAC. The advisory notes that every authenticated Argo CD user gets get access via the default role:catch-all policy, so the bar for exploitation is low.
• Highest risk: Applications already configured with argocd.argoproj.io/compare-options: IncludeMutationWebhook=true. There, only read-only Argo CD access is needed.
• What can be extracted: real Secret values - the advisory specifically calls out service account tokens, TLS certificates, database credentials, and API keys.

What to do now

• Patch first. Upgrade to 3.2.11 or 3.3.9 depending on your release line.

  "Patched versions 3.3.9, 3.2.11" - GitHub advisory GHSA-3v3m-wc6v-x4x3

• Confirm your installed version sits outside the affected ranges (3.2.0 to < 3.2.11, 3.3.0 to < 3.3.9). Check all instances, including non-production clusters.
• Search your Application manifests for argocd.argoproj.io/compare-options: IncludeMutationWebhook=true. Those applications are your highest-priority targets for patching and post-patch review.
• Audit Argo CD RBAC to understand who can invoke /application.ApplicationService/ServerSideDiff and who holds application get permissions. The threat model in the advisory assumes read-only access is sufficient for exploitation.
• If you suspect exposure already, pull Argo CD API and ingress logs and look for calls to ServerSideDiff. Any Secret values that may have been returned to unauthorised callers should be treated as compromised and rotated under your normal incident response process.