Kubernetes Secret disclosure through ServerSideDiff in argoproj Argo CD

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. From versions 3.2.0 to before 3.2.11 and 3.3.0 to before 3.3.9, there is a missing authorization and data-masking gap in Argo CD's ServerSideDiff endpoint that allows an attacker with read-only access to extract plaintext Kubernetes Secret data from etcd via the Kubernetes API server's Server-Side Apply dry-run mechanism. This issue has been patched in versions 3.2.11 and 3.3.9.

The CNA and vendor advisory confirm these affected ranges:

• argo-cd from 3.2.0 through before 3.2.11.
• argo-cd from 3.3.0 through before 3.3.9.
• The upstream fixes are confirmed in 3.2.11 for the first branch and 3.3.9 for the second branch. Do not infer the status of parallel branches or downstream builds from those two release points alone.
• Red Hat identifies images for Red Hat OpenShift GitOps 1.19 and 1.20 as fixed in its CSAF data. Red Hat also issued an update for Red Hat OpenShift GitOps 1.20.3 that identifies a fix for this issue. For downstream images, match the vendor erratum and image rather than comparing only the upstream version.

The flaw is in Argo CD's ServerSideDiff gRPC/REST endpoint. Unlike other endpoints that use hideSecretData() to mask Secret values, this endpoint returns the PredictedLive and NormalizedLive states without masking them.

The processing path invokes K8sServerSideDryRunner.Run(), which performs the equivalent of a Server-Side Apply dry-run through the Kubernetes API server. Argo CD normally uses removeWebhookMutation() to remove fields not managed by Argo CD from the dry-run response and merge them with the client-provided, masked live state. That protection is skipped when an Application has the annotation argocd.argoproj.io/compare-options: IncludeMutationWebhook=true.

The resulting dry-run response can therefore contain real Secret values read from etcd and pass them directly into the API response without masking. Successful extraction also depends on Secret data fields being owned by an SSA field manager other than argocd-controller; when argocd-controller is the sole manager, the dry-run removes fields omitted from the target manifest. The exact RBAC policy and Secret scope vary by deployment.

The vulnerability is reachable over the network through the ServerSideDiff gRPC or REST endpoint. An attacker needs an authenticated Argo CD account with enough read-only access to invoke the function; the vendor advisory states that Application get permission is sufficient and that the default role:catch-all policy can grant this access to authenticated users.

No additional user interaction is required, and the supplied record describes the attack complexity as low. For Applications where IncludeMutationWebhook=true is already enabled, read-only Argo CD access can be sufficient to retrieve Secret values when the SSA field-manager ownership condition is also met.

The vendor advisory includes a public proof of concept. The supplied record marks a public exploit as present, but does not identify a campaign, victim, or observed real-world exploitation report.

The confirmed technical outcome is that Kubernetes Secret values can appear in plaintext in a ServerSideDiff response. This directly affects the confidentiality of data stored in Kubernetes and may include credentials used by clusters, workloads, or external services.

The impact crosses the boundary of the Argo CD read permission because a read-only principal may receive Secret data that the endpoint should have masked. If the exposed credential remains valid, a third party may use it for actions outside Argo CD according to that credential's permissions; this is a possible downstream consequence, not a demonstrated direct write capability of the endpoint.

The issue is not described as causing direct availability loss. Actual exposure depends on the relevant Application annotation, Server-Side Apply field ownership, and the permissions attached to each Secret.

The flaw can disclose real Kubernetes Secret values, including service account tokens, TLS certificates, database credentials, and API keys.

Those values may provide access to a Kubernetes cluster or external services if they remain valid and have the relevant permissions. The issue creates a path from read access in Argo CD to sensitive data that the principal may not otherwise be authorized to view.

The directly documented consequence is information disclosure. The advisory does not establish direct modification or service disruption through the endpoint, although exposed credentials may create downstream risk according to their individual privileges.

1. Upgrade Argo CD to 3.2.11 for the 3.2.x branch, or to 3.3.9 for the 3.3.x branch. These are the upstream fixes confirmed by the vendor.
2. If Red Hat OpenShift GitOps is used, apply the applicable Red Hat erratum or image marked fixed for the deployed product branch. For the Red Hat OpenShift GitOps 1.20 branch, Red Hat describes 1.20.3 as containing the fix for this issue. Do not assume another downstream image is fixed without checking its vendor advisory and image details.
3. While upgrading, review and, where operationally appropriate, remove argocd.argoproj.io/compare-options: IncludeMutationWebhook=true from Applications that do not require it. This can restore the masking defense, but it is a temporary risk reduction and not a replacement for patching.
4. Review Application get permissions and reduce access for principals that do not need to invoke ServerSideDiff. This may reduce exposure, but it is not a complete fix.
5. If Secret exposure cannot be ruled out, treat the relevant values as potentially disclosed and rotate tokens, certificates, passwords, or API keys according to the organization's incident-response process. Prioritize Secrets with data fields owned by a manager other than argocd-controller and credentials with broad access.

1. Inventory every Argo CD instance and identify deployments running the affected branches listed in affected_summary.
2. Inspect Application configuration for argocd.argoproj.io/compare-options: IncludeMutationWebhook=true. This is important because the annotation causes Argo CD to skip removeWebhookMutation().
3. Review RBAC to identify principals with Application get permission or access to ServerSideDiff, especially principals receiving access through role:catch-all.
4. For sensitive Secrets, inspect managedFields to determine whether data fields are owned by an SSA field manager other than argocd-controller. This prioritizes Secrets that may survive the dry-run response.
5. If request logging is available, review requests to ServerSideDiff as a precautionary investigation step. The advisory does not define a unique IOC or log pattern, and absence of matching logs does not prove that the deployment is safe.