fix(deps): update module github.com/argoproj/argo-cd/v3 to v3.1.8 [security] #255
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v3.1.2->v3.1.8GitHub Vulnerability Alerts
CVE-2025-55191
Summary
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/repository_secrets.gofile. For example, in thesecretToRepoCredfunction. The issue manifests as a concurrent map access panic:The race condition occurs due to:
A valid API token with
repositoriesresource permissions (create,update, ordeleteactions) 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 denial-of-service state, disrupting all GitOps operations. Default ArgoCD configuration is vulnerable.
The affected code was originally introduced in PR #6103 and released in v2.1.0.
This data race was addressed by deep-copying the
Secretobjects before reading/writing.Credits
This vulnerability was found, reported and fixed by:
@thevilledev
The Argo team would like to thank him for his responsible disclosure and constructive communications during the resolve of this issue.
CVE-2025-59531
Summary
Unpatched Argo CD versions are vulnerable to malicious API requests which can crash the API server and cause denial of service to legitimate clients.
With the default configuration, no
webhook.bitbucketserver.secretset, Argo CD’s /api/webhook endpoint will crash the entire argocd-server process when it receives a Bitbucket-Server push event whose JSON fieldrepository.links.cloneis anything other than an array.A single unauthenticated curl request can push the control-plane into CrashLoopBackOff; repeating the request on each replica causes a complete outage of the API.
Details
If links.clone is a string, number, object, or null, the first type assertion panics:
interface conversion: interface {} is string, not []interface {}
The worker goroutine created by startWorkerPool lacks a recover, so the panic terminates the whole binary.
PoC
Save as payload-panic.json - note the non-array links.clone.
{ "eventKey": "repo:refs_changed", "repository": { "name": "guestbook", "fullName": "APP/guestbook", "links": { "clone": "boom" } }, "changes": [ { "ref": { "id": "refs/heads/master" } } ] }curl -k -X POST https://argocd.example.com/api/webhook \ -H 'X-Event-Key: repo:refs_changed' \ -H 'Content-Type: application/json' \ --data-binary @​payload-panic.jsonObserved crash (argocd-server restart):
Mitigation
If you use Bitbucket Server 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 Bitbucket Server, you can set the webhook secret to a long, random value to effectively disable webhook handling for Bitbucket Server payloads.
apiVersion: v1 kind: Secret metadata: name: argocd-secret type: Opaque data: + webhook.bitbucketserver.secret: <your base64-encoded secret here>For more information
Credits
Discovered by Jakub Ciolek at AlphaSense.
CVE-2025-59537
Summary
Unpatched Argo CD versions are vulnerable to malicious API requests which can crash the API server and cause denial of service to legitimate clients.
With the default configuration, no
webhook.gogs.secretset, Argo CD’s /api/webhook endpoint will crash the entire argocd-server process when it receives a Gogs push event whose JSON fieldcommits[].repois not set or is null.Details
Users can access
/api/webhookwithout authentication, and when accessing this endpoint, theHandlerfunction parses webhook type messages according to theheader (e.g. X-Gogs-Event)andbodyparameters provided by the user. TheParsefunction simply unmarshals JSON-type messages. In other words, it returns a data structure even if the data structure is not exactly matched.The
affectedRevisionInfofunction parses data according to webhook event types(e.g.gogsclient.PushPayload). However, due to the lack of data structure validation corresponding to these events, an attacker can cause a Denial of Service (DoS) attack by sending maliciously crafted data. because of Repository is Pointer Type.PoC
payload-gogs.json
{ "ref": "refs/heads/master", "before": "0000000000000000000000000000000000000000", "after": "0a05129851238652bf806a400af89fa974ade739", "commits": [{}] }An attacker can cause a DoS and make the argo-cd service unavailable by continuously sending unauthenticated requests to
/api/webhook.Mitigation
If you use Gogs 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 Gogs, you can set the webhook secret to a long, random value to effectively disable webhook handling for Gogs payloads.
apiVersion: v1 kind: Secret metadata: name: argocd-secret type: Opaque data: + webhook.gogs.secret: <your base64-encoded secret here>For more information
Credit
Sangjun Song (s0ngsari) at Theori (theori.io)
CVE-2025-59538
Summary
In the default configuration,
webhook.azuredevops.usernameandwebhook.azuredevops.passwordnot 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:
{ "eventType": "git.push", "resource": { "refUpdates": [], "repository": { "remoteUrl": "https://example.com/dummy", "defaultBranch": "refs/heads/master" } } }curl call:
curl -k -X POST https://argocd.example.com/api/webhook \ -H 'X-Vss-ActivityId: 11111111-1111-1111-1111-111111111111' \ -H 'Content-Type: application/json' \ --data-binary @​payload-azure-empty.jsonObserved 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
Credits
Discovered by Jakub Ciolek at AlphaSense.
Release Notes
argoproj/argo-cd (github.com/argoproj/argo-cd/v3)
v3.1.8Compare Source
Quick Start
Non-HA:
HA:
Release Signatures and Provenance
All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.
Release Notes Blog Post
For a detailed breakdown of the key changes and improvements in this release, check out the official blog post
Upgrading
If upgrading from a different minor version, be sure to read the upgrading documentation.
Changelog
Bug fixes
c63c2d8: fix(docs): include v3.1 upgrade docs (#23529) [backport] (#24799) (@SJrX)b2fa7dc: fix: #24781 update crossplane healthchecks to V2 version (cherry-pick #24782 for 3.1) (#24783) (@argo-cd-cherry-pick-bot[bot])41eac62: fix: Clear ApplicationSet applicationStatus when ProgressiveSync is d… (#24715) (@aali309)38808d0: fix: allow for backwards compatibility of durations defined in days (cherry-pick #24769 for 3.1) (#24771) (@argo-cd-cherry-pick-bot[bot])54bab39: fix: update ExternalSecret discovery.lua to also include the refreshPolicy (cherry-pick #24707 for 3.1) (#24712) (@argo-cd-cherry-pick-bot[bot])Other work
5c466a4: Merge commit from fork (@crenshaw-dev)1a023f1: Merge commit from fork (@crenshaw-dev)761fc27: Merge commit from fork (@crenshaw-dev)e20828f: Merge commit from fork (@thevilledev)Full Changelog: argoproj/argo-cd@v3.1.7...v3.1.8
v3.1.7Compare Source
Quick Start
Non-HA:
HA:
Release Signatures and Provenance
All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.
Release Notes Blog Post
For a detailed breakdown of the key changes and improvements in this release, check out the official blog post
Upgrading
If upgrading from a different minor version, be sure to read the upgrading documentation.
Changelog
Bug fixes
4081e29: fix(server): validate new project on update (#23970) (cherry-pick #23973 for 3.1) (#24662) (@argo-cd-cherry-pick-bot[bot])c26cd55: fix: Progress Sync Unknown in UI (cherry-pick #24202 for 3.1) (#24643) (@argo-cd-cherry-pick-bot[bot])2e4458b: fix: limit number of resources in appset status (#24690) (#24696) (@alexmt)f3d59b0: fix: resolve argocdService initialization issue in notifications CLI (cherry-pick #24664 for 3.1) (#24681) (@argo-cd-cherry-pick-bot[bot])Other work
7f92418: ci(release): only set latest release in github when latest (cherry-pick #24525 for 3.1) (#24685) (@argo-cd-cherry-pick-bot[bot])Full Changelog: argoproj/argo-cd@v3.1.6...v3.1.7
v3.1.6Compare Source
Quick Start
Non-HA:
HA:
Release Signatures and Provenance
All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.
Release Notes Blog Post
For a detailed breakdown of the key changes and improvements in this release, check out the official blog post
Upgrading
If upgrading from a different minor version, be sure to read the upgrading documentation.
Changelog
Bug fixes
b46a57a: fix(oci): loosen up layer restrictions (cherry-pick #24640 for 3.1) (#24649) (@argo-cd-cherry-pick-bot[bot])468870f: fix: Ensure that symlink targets are not made absolute on extracting a tar (#24145) - backport/cherry-pick to 3.1 (#24519) (@leh-ppi)cb95745: fix: correct post-delete finalizer removal when cluster not found (cherry-pick #24415 for 3.1) (#24590) (@argo-cd-cherry-pick-bot[bot])2b3df7f: fix: use informer in webhook handler to reduce memory usage (#24622) (#24626) (@alexmt)Documentation
4ef5663: docs: Delete dangling word in Source Hydrator docs (cherry-pick #24601 for 3.1) (#24603) (@argo-cd-cherry-pick-bot[bot])Full Changelog: argoproj/argo-cd@v3.1.5...v3.1.6
v3.1.5Compare Source
Quick Start
Non-HA:
HA:
Release Signatures and Provenance
All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.
Release Notes Blog Post
For a detailed breakdown of the key changes and improvements in this release, check out the official blog post
Upgrading
If upgrading from a different minor version, be sure to read the upgrading documentation.
Changelog
Documentation
0415c60: docs: Update URL for HA manifests to stable. (#24454) (@Kelketek)Other work
9a3235e: fix(3.1): change the appset namespace to server namespace when generating appset (#24478) (@nitishfy)c21141a: fix(cherry pick 3.1): RunResourceAction: error getting Lua resource action: built-in script does not exist #24491 (#24500) (@FourFifthsCode)3320f1e: fix(cherry-pick-3.1): Do not block project update when a cluster referenced in an App doesn't exist (#24450) (@OpenGuidou)Full Changelog: argoproj/argo-cd@v3.1.4...v3.1.5
v3.1.4Compare Source
Quick Start
Non-HA:
HA:
Release Signatures and Provenance
All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.
Release Notes Blog Post
For a detailed breakdown of the key changes and improvements in this release, check out the official blog post
Upgrading
If upgrading from a different minor version, be sure to read the upgrading documentation.
Changelog
Dependency updates
206d57b: chore(deps): bump gitops-engine (#24418) (@agaudreault)Full Changelog: argoproj/argo-cd@v3.1.3...v3.1.4
v3.1.3Compare Source
Quick Start
Non-HA:
HA:
Release Signatures and Provenance
All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.
Release Notes Blog Post
For a detailed breakdown of the key changes and improvements in this release, check out the official blog post
Upgrading
If upgrading from a different minor version, be sure to read the upgrading documentation.
Changelog
Full Changelog: argoproj/argo-cd@v3.1.2...v3.1.3
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.