Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The original fix for GHSA-3v3m-wc6v-x4x3 is incomplete. argocd app diff --server-side-diff can still expose Kubernetes Secret values embedded in the kubectl.kubernetes.io/last-applied-configuration annotation. The prior fix masks top-level Secret data in ServerSideDiff responses, but it does not fully sanitize Secret data stored inside the last-applied-configuration annotation. If a Secret was previously created or updated using client-side apply, that annotation may contain raw data, stringData, and sensitive annotations. These values can be shown in UI/CLI diffs. Details The ServerSideDiff endpoint returns ResourceDiff.TargetState / LiveState based on server-side dry-run output. Kubernetes server-side dry-run can return a full predicted live Secret object that carries forward existing live annotations, including: kubectl.kubernetes.io/last-applied-configuration For Secrets created with client-side apply, that annotation can contain a JSON-serialized Secret manifest with…
Recommended action: Upgrade to 3.4.2, 3.3.10 or 3.2.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-cd/v3 >= 3.2.0, < 3.2.11; >= 3.3.0, < 3.3.9
Fixed in
3.3.93.2.11· Vendor fix available
Issue
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. Details Argo CD masks Secret data in every endpoint that returns Kubernetes resource state except one. All the other endpoints such as GetManifests, GetManifestsWithFiles, GetResource and PatchResource utilize hideSecretData() to mask the returned secret value. The vulnerable function ServerSideDiff gRPC/REST endpoint (/application.ApplicationService/ServerSideDiff) constructs its response with raw, unmasked PredictedLive and NormalizedLive states: A user only requires RBAC to call this ServerSideDiff function. Every authenticated Argo CD user has get access via the default role:catch-all policy. However, Argo CD has a defense layer called removeWebhookMutation() that normally strips non-Argo CD-managed fields from the…
Recommended action: Upgrade to 3.3.9 or 3.2.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In the default configuration, webhook.azuredevops.username and webhook.azuredevops.password not set, Argo CD’s /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty. The slice index [0] is accessed without a length check, causing an index-out-of-range panic. A single unauthenticated HTTP POST is enough to kill the process. Details If the attacker supplies "refUpdates": [], the slice has length 0. The webhook code has no recover(), so the panic terminates the entire binary. PoC payload-azure-empty.json: curl call: Observed crash: Mitigation If you use Azure DevOps and need to handle webhook events, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. If you do not use Azure DevOps, you can set the webhook secrets to long, random values to effectively disable webhook handling for Azure DevOps payloads. For more information Open an issue in the…
Recommended action: Upgrade to 3.2.0-rc2 (pre-release), 3.1.8 or 3.0.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A race condition in the repository credentials handler can cause the Argo CD server to panic and crash when concurrent operations are performed on the same repository URL. Details The vulnerability is located in numerous repository related handlers in the util/db/repositorysecrets.go file. For example, in the secretToRepoCred function. The issue manifests as a concurrent map access panic: The race condition occurs due to: 1. Concurrent repository credential operations (create/update/delete) accessing the same map 2. Kubernetes informer re-syncs happening simultaneously 3. Background watchers updating the same secret data 4. No mutex protection for map access A valid API token with repositories resource permissions (create, update, or delete actions) is required to trigger the race condition. Impact This vulnerability causes the entire Argo CD server to crash and become unavailable. Attackers can repeatedly and continuously trigger the race condition to maintain a…
Recommended action: Upgrade to 3.2.0-rc2 (pre-release), 3.1.8 or 3.0.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-cd/v3 < 3.0.14; >= 3.1.0-rc1, < 3.1.2
Fixed in
3.1.23.0.14· Vendor fix available
Issue
Argo CD API tokens with project-level permissions are able to retrieve sensitive repository credentials (usernames, passwords) through the project details API endpoint, even when the token only has standard application management permissions and no explicit access to secrets. Component: Project API (/api/v1/projects/{project}/detailed) Vulnerability Details Expected Behavior API tokens should require explicit permission to access sensitive credential information. Standard project permissions should not grant access to repository secrets. Actual Behavior API tokens with basic project permissions can retrieve all repository credentials associated with a project through the detailed project API endpoint. Note: This vulnerability does not only affect project-level permissions. Any token with project get permissions is also vulnerable, including global permissions such as: p, role/user, projects, get, , allow Steps to Reproduce 1. Create an API token with the following…
Recommended action: Upgrade to 3.1.2 or 3.0.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.