Argo CD ServerSideDiff exposes Kubernetes Secret data through annotations

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. From 3.2.0 until 3.2.12, 3.3.10, and 3.4.2, Argo CD ServerSideDiff can expose Kubernetes Secret values embedded in the kubectl.kubernetes.io/last-applied-configuration annotation because HideSecretData(target, live,...) does not fully sanitize ResourceDiff.TargetState and LiveState predicted live Secret objects, allowing sensitive data, stringData, and annotations to appear in UI or CLI diffs. This issue is fixed in versions 3.2.12, 3.3.10, and 3.4.2.

• Argo CD package github.com/argoproj/argo-cd/v3, 3.2 branch: affected from 3.2.0 through 3.2.11; fixed in 3.2.12.
• 3.3 branch: affected from 3.3.0-rc1 through 3.3.9; fixed in 3.3.10.
• 3.4 branch: affected from 3.4.0-rc1 through 3.4.1; fixed in 3.4.2.
• The vendor advisory includes the pre-release branches listed above. The status of other branches is not established by the available evidence.

Argo CD ServerSideDiff builds ResourceDiff.TargetState and LiveState from Kubernetes server-side dry-run output. A predicted live Secret can carry forward the kubectl.kubernetes.io/last-applied-configuration annotation, which may contain a JSON-serialized manifest when the Secret was previously created or updated with client-side apply. The masking path calls HideSecretData(target, live, ...), but only rewrites the annotation on the live argument; the first argument can be predictedLive and remain unsanitized. As a result, raw Secret data, stringData, and sensitive annotations can survive into UI or CLI diff output. The preconditions include a Kubernetes Secret with the relevant annotation and an authenticated principal able to request or view application diffs; the available evidence does not establish every possible RBAC combination. The fix removes the annotation from both comparison sides and applies masking symmetrically to Secret objects.

• The affected functionality is reachable through Argo CD ServerSideDiff and is reflected in application diffs in the UI or CLI.
• Authentication is required: the advisory identifies authenticated Argo CD users who can view application diffs as the affected access group.
• The normalized record indicates network reachability, existing privileges, and no user interaction. Practical exploitation still depends on a Secret with the relevant annotation and use of ServerSideDiff.
• The vendor advisory includes a public proof of concept. The supplied evidence does not name a campaign, victim, or specific real-world exploitation.

The confirmed technical outcome is disclosure of Kubernetes Secret values to an authenticated user who may not otherwise be authorized to view them. The disclosure path runs through ServerSideDiff results and can appear in both UI and CLI diffs. If an exposed Secret value remains usable, the consequence could extend to unauthorized access to services or resources protected by that value, depending on how the organization uses it. The advisory describes read exposure and does not document the ability to modify Secrets, change configuration, or reduce availability.

Authenticated Argo CD users who can view application diffs may see Secret values that Argo CD intended to mask. Exposed content can include Secret data embedded in the annotation, stringData, and sensitive annotations, including credentials or tokens if they were stored there. If the values remain usable, the organization may need to rotate secrets, review access, and assess dependent systems. The documented effect is loss of confidentiality; the available evidence does not describe data modification or service disruption.

1. Upgrade according to the deployed branch: use 3.2.12 for the 3.2 branch, 3.3.10 for the 3.3 branch, or 3.4.2 for the 3.4 branch. Do not assume that a fix for one branch covers parallel branches.
2. If using 3.2.12, plan migration because the release page marks the 3.2 series as end of life.
3. Review diffs displayed before the upgrade. If Secret values may have been exposed, rotate the related credentials, tokens, or keys and assess systems that use them.
4. The available evidence identifies patched releases rather than a separate vendor workaround. Do not substitute an unconfirmed configuration change for upgrading.

1. Inventory Argo CD Server and CLI versions, then compare each instance with the affected branches in affected_summary.
2. Review Applications using ServerSideDiff=true or operational workflows that run argocd app diff --server-side-diff.
3. Identify Kubernetes Secrets with the kubectl.kubernetes.io/last-applied-configuration annotation, especially Secrets previously created or updated with client-side apply. In an access-controlled review, check whether the annotation contains a serialized manifest, data, stringData, or sensitive annotations.
4. Review historical UI and CLI diffs for unmasked Secret values inside kubectl.kubernetes.io/last-applied-configuration. Do not copy discovered values into new tickets or logs.
5. As a precaution, review audit or access records for users with application-diff permissions. The absence of matching log evidence does not prove that exposure did not occur.