GHSA-274v-mgcv-cm8j: Argo CD GitOps Engine does not scrub secret values from patch errors

The analysis focused on two commits: one in argoproj/argo-cd (primarily test and dependency updates) and one in argoproj/gitops-engine (core logic changes). The vulnerability involves exposing secret values in error messages and diff views when an invalid Kubernetes Secret is synced.

1. Commit 7e21b91e9d0f64104c8a661f3f390c5e6d73ddca (gitops-engine):

   • pkg/diff/diff.go (NormalizeSecret function): The changes here directly address how stringData in Secrets is handled. The previous logic could lead to raw stringData (if invalid) being exposed in diffs. The patch ensures better normalization and encoding, preventing this exposure. This aligns with the 'diff view' part of the vulnerability and the commit message 'Invalid secrets with stringData exposes the secret values in diff'.
   • pkg/utils/kube/kube.go (cleanKubectlOutput function): This function is modified to add a regex (kubectlErrOutMapRegexp) to strip map[...] patterns from error messages. This directly addresses the 'error messages' part of the vulnerability, as confirmed by the commit message 'map[] in error output exposes secret data in last-applied-annotation & patch error'. The vulnerability was that such error messages were not being adequately sanitized before this change.

2. Commit 6f5537bdf15ddbaa0f27a1a678632ff0743e4107 (argo-cd):

   • This commit updates gitops-engine to the version containing the fix.
   • It adds an end-to-end test (TestMaskValuesInInvalidSecret) which explicitly creates an invalid secret and verifies that sensitive data is not present in manifests, diffs, or error messages (app.Status.OperationState.Message). This test confirms the exploitation scenario and the expected outcome of the fix in gitops-engine.

Based on these patches and commit messages, NormalizeSecret was vulnerable due to its insufficient processing of potentially malformed secret data leading to exposure in diffs. The error reporting mechanism, whose output is cleaned by cleanKubectlOutput, was vulnerable because it previously allowed error messages containing sensitive data (formatted as map structures) to be exposed. cleanKubectlOutput was modified to mitigate this by adding specific sanitization for these patterns.