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

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


                            CERT-Renater

                Note d'Information No. 2026/VULN1034
_____________________________________________________________________

DATE                : 15/10/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running argo-cd/v3 (Go) versions prior
                           to 3.3.15, 3.4.10, 3.5.4, 3.6.0-rc2,
                     argo-cd/v2 (Go), argo-cd (Go).

====================================================================
https://github.com/argoproj/argo-cd/security/advisories/GHSA-fw5c-w8rc-j7fx
https://github.com/argoproj/argo-cd/security/advisories/GHSA-9v9p-x54c-58gc
https://github.com/argoproj/argo-cd/security/advisories/GHSA-m3vr-7329-44ww
https://github.com/argoproj/argo-cd/security/advisories/GHSA-fmxq-cgp8-87wp
https://github.com/argoproj/argo-cd/security/advisories/GHSA-j6cw-g6p4-7hch
_____________________________________________________________________


A Kustomize Helm config home can run commands in the repo-server
Critical
crenshaw-dev published GHSA-fw5c-w8rc-j7fx 

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

Affected versions
>= 2.1.0

Patched versions
None

github.com/argoproj/argo-cd/v3 (Go)
Affected versions
>= 3.0.0, < 3.3.15 || >= 3.4.0, < 3.4.10 || >= 3.5.0, < 3.5.4 || = 3.6.0-rc1
Patched versions
3.3.15, 3.4.10, 3.5.4, 3.6.0-rc2


Description

Impact

When Kustomize Helm chart rendering is enabled, a kustomization can point
Helm at a directory the repository controls and run a program from that
directory inside argocd-repo-server. Kustomize copies helmGlobals.configHome
into Helm’s config and data directories. Helm then loads a downloader plugin
from <configHome>/.data/plugins with no separate plugin-install step, and
runs it when a helmCharts repository URL uses that plugin’s protocol. The
command runs as the repo-server user and can read repository credentials and
anything else available to that process.

All versions from v2.1.0 onward are affected, including every currently
supported release. v2.0.5 and earlier are not. The behavior was introduced in
b6d5c23bc (2021-04-20, #6059), the change that upgraded the bundled Kustomize
from 3.9.4 to 4.1.2, and was first released in v2.1.0. Kustomize 4.1.0 is what
first passes helmGlobals.configHome through to Helm
(kubernetes-sigs/kustomize#3784). Deployments that do not pass --enable-helm
to kustomize build are not affected.

Two ways to supply the kustomization, both of which require that an operator
has already enabled --enable-helm:

    Commit it to a Git repository that an Application builds with Kustomize.
    Upload it through POST /api/v1/applications/manifestsWithFiles (argocd app
diff --local --server-side-generate). This needs only Application get on an
existing Application. It does not need permission to update or sync the
Application, or write access to its Git repository.


Patches

A patch for this vulnerability has been released in the following Argo CD
versions:

    v3.6.0-rc2
    v3.5.4
    v3.4.10
    v3.3.15

Kustomize Helm chart rendering still works for ordinary http, https, and oci
chart repositories. The patch points Helm at an empty config and data directory
for every Kustomize build, so helmGlobals.configHome cannot register a plugin.


Workarounds

Do not pass --enable-helm in kustomize.buildOptions. That is a complete
workaround for this issue. Applications that render Helm charts through
Kustomize cannot use it.

Restricting Application get, or blocking
POST /api/v1/applications/manifestsWithFiles, closes only the upload path.
A kustomization committed to Git is still built on the next sync
while --enable-helm is set.


Credits

The Argo CD team would like to thank @hoang-prod for responsibly disclosing
this issue according to our security reporting guidelines.


References

    Introducing commit: b6d5c23bce2f8a46c52975ba438a3b93d242d96c (#6059),
first released in v2.1.0
    Kustomize feature: kubernetes-sigs/kustomize#3784
    Kustomizing Helm charts

For more information

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


Severity
Critical
9.9/ 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
No known CVE

Weaknesses
No CWEs

Credits

    @hoang-prod hoang-prod Reporter
    @leoluz leoluz Remediation developer
    @crenshaw-dev crenshaw-dev Remediation reviewer

_____________________________________________________________________


A Kustomize remote ref can run commands in the repo-server
Critical
crenshaw-dev published GHSA-9v9p-x54c-58gc 

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

Affected versions
>= 2.7.0

Patched versions
None

github.com/argoproj/argo-cd/v3 (Go)
Affected versions
>= 3.0.0, < 3.3.15 || >= 3.4.0, < 3.4.10 || >= 3.5.0, < 3.5.4 || = 3.6.0-rc1
Patched versions
3.3.15, 3.4.10, 3.5.4, 3.6.0-rc2


Description

Impact

Kustomize passes a remote resource, base, or component URL to git fetch, and
appends that URL’s ref or version query value with no -- separator. A value
that starts with -, such as --upload-pack=<command>, is parsed as a Git option.
--upload-pack runs that command inside argocd-repo-server when the remote is a
local transport such as file://. Git does not run it for an https:// remote. A
file:// URL never leaves the pod, and Git returns the command’s output to the
caller in the manifest-generation error. The command runs as the repo-server
user and can read repository credentials and anything else available to that
process.

All versions from v2.7.0 onward are affected, including every currently
supported release. v2.6.15 and earlier are not. The behavior was introduced
in 25badeb7a1 (2023-03-16, #12299), the change that upgraded the bundled
Kustomize from 4.5.7 to 5.0.1, and was first released in v2.7.0. Kustomize
4.5.7 rejects a file:// URL, so this payload does not run there. Kustomize
5.0.0 is what first accepts file:// and hands it to git fetch. Replacing
the repo-server binary with a newer Kustomize does not help: current
Kustomize still passes ref through without --.

Two ways to supply the Kustomization:

    Commit it to a Git repository that an Application builds with Kustomize.
    Upload it through POST /api/v1/applications/manifestsWithFiles
(argocd app diff --local --server-side-generate). This needs only Application
get on an existing Application. It does not need permission to update or sync
the Application, or write access to its Git repository.

Patches

A patch for this vulnerability has been released in the following Argo CD
versions:

    v3.6.0-rc2
    v3.5.4
    v3.4.10
    v3.3.15

The patch keeps Kustomize remote bases working. It places a git wrapper ahead
of the real git on the Kustomize build’s PATH, so the remote URL and ref
cannot be parsed as Git options.


Workarounds

Pin every Application that runs Kustomize to a Kustomize older than 5.0, such
as 4.5.7. Register that binary with kustomize.path.<version> in argocd-cm, and
set spec.source.kustomize.version (or argocd app set <app> --kustomize-version)
on each Application. The binary that actually runs has to be that older one.
Leaving Kustomize 5.x as the default, or as another registered version, leaves
that path open.

Applications that rely on Kustomize 5 features cannot use this pin. Those builds
will fail or drop behavior that 4.5.7 does not have.

Blocking repo-server egress does not prevent this, because a file:// remote never
leaves the pod. Restricting Application get, or blocking
POST /api/v1/applications/manifestsWithFiles, closes only the upload path. A
Kustomization committed to Git is still built on the next sync.

There is no complete workaround besides upgrading.

Credits

The Argo CD team would like to thank @hoang-prod and @yabeow for responsibly
disclosing this issue according to our security reporting guidelines.


References

    Introducing commit: 25badeb7a1e154805340bb7237e0ce671f3772dd (#12299), first released in v2.7.0
    Custom Kustomize versions

For more information

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


Severity
Critical
9.9/ 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
No known CVE

Weaknesses
No CWEs

Credits

    @hoang-prod hoang-prod Reporter
    @yabeow yabeow Reporter
    @leoluz leoluz Remediation developer
_____________________________________________________________________


A Jsonnet import can read files from the repo-server
Critical
crenshaw-dev published GHSA-m3vr-7329-44ww 

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

Affected versions
>= 0.9.0, < 2.0.0

Patched versions
None

github.com/argoproj/argo-cd/v2 (Go)
Affected versions
>= 2.0.0
Patched versions
None

github.com/argoproj/argo-cd/v3 (Go)
Affected versions
>= 3.0.0, < 3.3.15 || >= 3.4.0, < 3.4.10 || >= 3.5.0, < 3.5.4 || = 3.6.0-rc1
Patched versions
3.3.15, 3.4.10, 3.5.4, 3.6.0-rc2


Description

Impact
_____________________________________________________________________
Argo CD evaluates .jsonnet files inside the repo-server with an importer
that can open any path the process can read. import, importstr, and
importbin all use that importer. An absolute path such as
/proc/self/environ, a ../ traversal, or a symlink inside the repository
that points outside it is opened with the repo-server’s own filesystem
permissions. importstr of a device such as /dev/zero reads until the
process runs out of memory. Argo CD redacts generated Secrets, so
placing the file contents in a ConfigMap returns them to the caller.
The data can include the process environment, the projected
service-account token, mounted private keys, and repository credentials.

All versions from v0.9.0 onward are affected, including every currently
supported release. v0.8.2 and earlier are not. The behavior was
introduced in 27471d524 (2018-09-07, #561), the change that added
Jsonnet as an application source, and was first released in v0.9.0.
The import path was limited to a search list for relative paths. That
list does not apply to absolute paths.

Two ways to supply the file:

    Commit a .jsonnet file to a Git repository that an Application builds.
Directory applications evaluate every .jsonnet file in the application
directory.

    Upload it through POST /api/v1/applications/manifestsWithFiles
(argocd app diff --local --server-side-generate). This needs only
Application get on an existing directory Application. It does not need
permission to update or sync the Application, or write access to its
Git repository.


Patches

A patch for this vulnerability has been released in the following
Argo CD versions:

    v3.6.0-rc2
    v3.5.4
    v3.4.10
    v3.3.15

Imports that stay inside the repository still work. The patch resolves
each import, including symlinks, and rejects any path outside the
repository root. It also rejects anything that is not a regular file,
so a device file is not read.


Workarounds

Set jsonnet.enable to "false" in the argocd-cm ConfigMap. Argo CD then
skips .jsonnet files. That covers a file committed to Git and a file
uploaded through POST /api/v1/applications/manifestsWithFiles. YAML and
JSON in a directory application are still applied. An application that
depends on Jsonnet stops rendering those files: they are omitted rather
than rejected, so a directory that contains only Jsonnet syncs without
those manifests.

Credits

The Argo CD team would like to thank @hoang-prod, @arpitjain099,
@key-moon, @MopMonkAI, @Kushalkhemka, @PontusHanssen, @mayank-jangid-moon,
@skigeek16, @opensec-intelligence, @thevilledev, @ShadowByte1, @izhax,
@mikecole-mg, @jake-ciolek, and @vitorespf for responsibly disclosing
this issue according to our security reporting guidelines.


References

    Introducing commit: 27471d524958878e7acc5131fb466b292079cd05 (#561),
first released in v0.9.0


For more information

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

Severity
Critical
9.9/ 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
No known CVE

Weaknesses
No CWEs

Credits

    @hoang-prod hoang-prod Reporter
    @arpitjain099 arpitjain099 Reporter
    @key-moon key-moon Reporter
    @Kushalkhemka Kushalkhemka Finder
    @mayank-jangid-moon mayank-jangid-moon Finder
    @skigeek16 skigeek16 Finder
    @opensec-intelligence opensec-intelligence Tool
    @thevilledev thevilledev Reporter
    @ShadowByte1 ShadowByte1 Reporter
    @izhax izhax Reporter
    @mikecole-mg mikecole-mg Reporter
    @jake-ciolek jake-ciolek Reporter
    @vitorespf vitorespf Reporter
    @leoluz leoluz Remediation developer
    @crenshaw-dev crenshaw-dev Remediation reviewer
_____________________________________________________________________

AppProject restrictions bypassed by PreDelete/PostDelete resource hooks
Critical
crenshaw-dev published GHSA-fmxq-cgp8-87wp 

Package
github.com/argoproj/argo-cd/v2 (Go)
Affected versions
>= 2.10.0
Patched versions
None

github.com/argoproj/argo-cd/v3 (Go)
Affected versions
>= 3.0.0, < 3.3.15 || >= 3.4.0, < 3.4.10 || >= 3.5.0, < 3.5.4 || = 3.6.0-rc1
Patched versions
3.3.15, 3.4.10, 3.5.4, 3.6.0-rc2


Description

Impact

Argo CD checks an Application's AppProject before it creates resources
during a sync. That check covers destination namespaces and servers, 
-scoped resource allow and deny lists, and namespaced resource allow and
deny lists, including resource names. PreDelete and PostDelete hooks
skip it. When the Application is deleted, Argo CD creates those hooks
with the application-controller's credentials on the destination cluster.

All versions from v2.10.0 onward are affected, including every currently
supported release. v2.9.22 and earlier are not. PostDelete hooks were
introduced in dcc17f70bf (2023-12-18, #16595) and first released in
v2.10.0. That creation path has never applied the project check.
PreDelete hooks, added in 3bf3d8a212 (2025-12-05, #22288) and first 
in v3.3.0, use the same path. v3.2.12 and earlier do not have PreDelete
hooks. PreSync, Sync, PostSync, and SyncFail hooks still go through
the project check.

A user who can push to the Git repository an Application syncs from can
commit a hook whose namespace, group, kind, or name the AppProject would
refuse on sync. The controller adds the delete finalizer when it sees the
hook, and the Application stays Synced until someone deletes it. Deleting
the Application creates the hook. What that can reach is bounded by the
application-controller's access to the destination cluster. In a typical
install that access is broad, so a tenant can create a cluster-scoped
object such as a ClusterRoleBinding, or an object in a namespace the
project does not allow. A hook with no deletion policy is removed after
it succeeds. A deletion policy that does not remove the hook on success
leaves the object in the cluster. A hook such as a Job can create further
objects that Argo CD does not clean up.


Patches

A patch for this vulnerability has been released in the following
Argo CD versions:

    v3.6.0-rc2
    v3.5.4
    v3.4.10
    v3.3.15

The fix applies the same AppProject destination and resource checks used
on sync before creating a PreDelete or PostDelete hook.

Argo CD 2.x and 3.0 through 3.2 are out of support and will not receive a
patch. Upgrade to a patched 3.3 or newer release.


Workarounds

There is no configuration setting that applies the project check to delete
hooks while those hooks stay in use.

    Do not grant untrusted users write access to Git repositories that
back Applications in restrictive AppProjects.
    Limit who can delete Applications. Deletion is what runs PreDelete
and PostDelete hooks.
    Tighten the application-controller's Kubernetes access so a hook
cannot reach sensitive namespaces or APIs.


Credits

The Argo CD team would like to thank @RealFakeAccount, @AdamKorcz,
@0xshylines, @thevilledev, @HenriWilliams, @cherez0ff, @ARSB1, and
@zwindler for responsibly disclosing this issue according to our
security reporting guidelines.


References

    PostDelete introducing commit: dcc17f70bf7db973fe480b8b613189b2c5ac4b4b (#16595), first released in v2.10.0
    PreDelete introducing commit: 3bf3d8a2124e772ac651f3fd42375c4e9b8008af (#22288), first released in v3.3.0
    AppProject specification
    Resource hooks

For more information

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

Severity
Critical
9.9/ 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-2026-77459

Weaknesses
Weakness CWE-863

Credits

    @RealFakeAccount RealFakeAccount Reporter
    @AdamKorcz AdamKorcz Reporter
    @0xshylines 0xshylines Reporter
    @thevilledev thevilledev Reporter
    @HenriWilliams HenriWilliams Reporter
    @cherez0ff cherez0ff Reporter
    @zwindler zwindler Reporter

_____________________________________________________________________


Command injection via a repository proxy URL on SSH Git repositories
High
crenshaw-dev published GHSA-j6cw-g6p4-7hch

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

Affected versions
>= 2.11.0

Patched versions
None

github.com/argoproj/argo-cd/v3 (Go)
Affected versions
>= 3.0.0, < 3.3.15 || >= 3.4.0, < 3.4.10 || >= 3.5.0, < 3.5.4 || = 3.6.0-rc1
Patched versions
3.3.15, 3.4.10, 3.5.4, 3.6.0-rc2


Description

Impact

Argo CD runs a shell command in the repo-server when it clones or fetches
an SSH Git repository that has a proxy URL. The proxy host and port are
copied into an SSH ProxyCommand. A host that contains shell metacharacters
breaks out of that command and runs in the repo-server.

All versions from v2.11.0 onward are affected, including every currently 
release. v2.10.20 and earlier are not. The behavior was introduced in
9b27aeb1a4 (2024-01-09, #15864), the change that added SOCKS5 proxy
support for SSH Git URLs, and was first released in v2.11.0.

The repository must use SSH. http, https, and socks5 proxy URLs all take
this path when they are set on an SSH repository. An HTTPS Git repository
uses the proxy as an HTTP proxy and does not build this command.

Anyone who can create or update a repository or a repository credential
template can set the proxy. That includes a project-scoped repository
permission, argocd repo add --proxy, and a repository Secret. A credential
template applies its proxy to every matching SSH repository that does not
have its own credentials. Argo CD runs the command when it tests the
repository connection and on later fetches. The process can read other
Git, Helm, and OCI credentials stored for the repo-server.


Patches

A patch for this vulnerability has been released in the following
Argo CD versions:

    v3.6.0-rc2
    v3.5.4
    v3.4.10
    v3.3.15

The fix stops passing the proxy host and port through a shell.

Argo CD 2.x and 3.0 through 3.2 are out of support and will not receive
a patch. Upgrade to a patched 3.3 or newer release.


Workarounds

There is no setting that keeps SSH repository proxies and removes the
shell command.

    Do not grant repository create or update to untrusted users, including
project-scoped repository access. See RBAC resources and project-scoped
repositories.
    Do not set a proxy on an SSH repository or on a credential template
that matches SSH repositories. The proxy field is documented in Configure
repositories with proxy. Credential templates are documented in Credential
templates. The --proxy flag is documented in argocd repo add.

An HTTPS Git repository with an HTTP proxy does not use this command.
Review existing repository and credential-template Secrets for
unexpected proxy values.


Credits

The Argo CD team would like to thank @kamil-sawicki, @yuvalelarat, @cherez0ff,
@McCaulay, @gehan-psbc, @ria-labs-security, @parameter-ai-security, and
@zwindler for responsibly disclosing this issue according to our security
reporting guidelines.


References

    Introducing commit: 9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205 (#15864),
first released in v2.11.0
    Configure repositories with proxy


For more information

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

Severity
High
8.8/ 10

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

CVE ID
CVE-2026-55797

Weaknesses
Weakness CWE-78

Credits

    @kamil-sawicki kamil-sawicki Reporter
    @yuvalelarat yuvalelarat Reporter
    @cherez0ff cherez0ff Reporter
    @McCaulay McCaulay Reporter
    @ria-labs-security ria-labs-security Reporter
    @parameter-ai-security parameter-ai-security Reporter
    @zwindler zwindler 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 +
=========================================================