critical

CVE-2023-40029

ArgoCD: secrets can be leak through kubectl.kubernetes.io/last-applied-configuration

Published 7 Sep 2023Modified 17 Jun 2026CWE 200, 532

In the Trivy database since at least 24 Oct 2026, 07:11 UTCWhen it arrived before that build is not recorded.

Severity by source

NVD9.6CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

GHSA9.9CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L

Red Hat9.9CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L

Bitnami9.6CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

Trivy's own label is CRITICAL. Rated critical by NVD, GHSA, Red Hat, Bitnami.

Description

Argo CD is a declarative continuous deployment for Kubernetes. Argo CD Cluster secrets might be managed declaratively using Argo CD / kubectl apply. As a result, the full secret body is stored in`kubectl.kubernetes.io/last-applied-configuration` annotation. pull request #7139 introduced the ability to manage cluster labels and annotations. Since clusters are stored as secrets it also exposes the `kubectl.kubernetes.io/last-applied-configuration` annotation which includes full secret body. In order to view the cluster annotations via the Argo CD API, the user must have `clusters, get` RBAC access. **Note:** In many cases, cluster secrets do not contain any actually-secret information. But sometimes, as in bearer-token auth, the contents might be very sensitive. The bug has been patched in versions 2.8.3, 2.7.14, and 2.6.15. Users are advised to upgrade. Users unable to upgrade should update/deploy cluster secret with `server-side-apply` flag which does not use or rely on `kubectl.kubernetes.io/last-applied-configuration` annotation. Note: annotation for existing secrets will require manual removal.

Affected packages and fixed versions

Source	Package	Fixed in
bitnami::Bitnami Vulnerability Database	argo-cd	2.6.15, 2.7.14, 2.8.3
go::GitHub Security Advisory Go	github.com/argoproj/argo-cd/v2	2.6.15, 2.7.14, 2.8.3

References

All 12 references

What Attestkeep does with this

Inside your cluster, without you opening a spreadsheet.

KnowsThe scanner refreshes its vulnerability database every six hours.

FindsEvery admitted image is rescanned every 24 hours by default (scan.rescanInterval). When Trivy rates this vulnerability critical for the image's package source, it appears in the image's findings by name. Findings without a fix are left out unless includeUnfixed is on.

Tells youA critical_finding event goes to the channels subscribed to it: e-mail, Slack, Teams, a webhook, Jira, GitLab or GitHub.

RefusesWith a policy that blocks critical findings, a pod with this image is refused at admission, a rollback to it included. Pods already running are not evicted.

RecordsEach decision is recorded with the policy that ran and its hash, then sealed under a signed checkpoint.

Try Attestkeep

Read the docs