Argo CD CVE-2026-77459: Delete Hooks Bypass the Boundaries of the AppProject

TL;DR — 90 seconds

• What: Argo CD creates PreDelete and PostDelete hooks without checking destination, namespace and allowed resources against the AppProject (CVE-2026-77459, CWE-863). The application-controller creates the objects with its own credentials.
• Severity: CVSS 9.9 with the vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Three further critical advisories in the same release hit the repo-server, including CVE-2026-113709, where with --enable-helm active the get permission on an Application is already enough to run code there.
• Who is affected: Instances from 2.10.0 to 2.14.21, 3.0.0 to 3.3.14, 3.4.0 to 3.4.9, 3.5.0 to 3.5.3 and 3.6.0-rc1 on which people outside the platform team may write to tracked repositories.
• What to do: Upgrade to 3.5.4, 3.4.10, 3.3.15 or 3.6.0-rc2. There is no patch for 2.x and 3.0 to 3.2, where the only way is an upgrade to 3.3 or newer.
• What would have protected you: a small group of people with write access to tracked repositories, a review rule for delete hooks and --enable-helm only where it is really needed.
• Exploitation: As of October 31, none of the vulnerabilities is in the CISA KEV catalog, and no reports of attacks are known.

Delete hooks without AppProject checks

In Argo CD, an AppProject limits where an Application may deploy. It defines target clusters, namespaces and allowed resource types, and during a normal sync Argo CD checks every object against these rules. In multi-team setups, the AppProject is therefore the actual tenant boundary.

Besides normal manifests, Argo CD supports resource hooks, manifests with the annotation argocd.argoproj.io/hook that run at specific points of a sync. According to the docs, the PostDelete type has existed since v2.10 and runs after all resources of an Application have been deleted. PreDelete runs before that, and only when the whole Application is deleted.

This is exactly where the bug was. According to the CVE description, Argo CD creates PostDelete hooks without checking destination, namespace and the resource allow and deny lists from the AppProject. Anyone who can write to an Application's repository can therefore commit a delete hook with a target that is actually forbidden to them. When the Application is deleted, the application-controller creates the object with its own credentials. Argo CD still checks the other hook types PreSync, Sync, PostSync and SyncFail correctly, so the flaw only affects the path that runs on deletion.

PreDelete hooks are affected in the same way. According to the GHSA text, they were added in version 3.3.0 and use the same path as PostDelete, which has never applied the project check since its introduction in 2.10.0. Version 2.9.22 and earlier are not affected. The advisory also describes why the attack can go unnoticed for so long: the controller adds the delete finalizer as soon as it sees the hook, and the Application stays Synced until someone deletes it. In a typical installation the controller has broad access, so a tenant can, for example, create a cluster-scoped object such as a ClusterRoleBinding.

Affected versions and prerequisites

The 3.5.4 release notes list all eight advisories. The two missing from the table are rated moderate and concern the extension proxy RBAC and oversized OCI manifests. According to the advisory for CVE-2026-55797, there are no more patches for Argo CD 2.x and 3.0 to 3.2.

The details of the three repo-server flaws come from the CVE records of October 20, which all carry the same vector and therefore CVSS 9.9. For CVE-2025-61560 the picture is thinner: the CVE record names neither vendor nor fix and only lists version 3.0.6, the score of 8.1 comes from CISA, and Red Hat rates the flaw as moderate. That 3.5.4 fixes it is taken from the release notes.

The controller as the attacker's tool

With the hook bypass, the application-controller works for the attacker, because it creates the objects with its credentials for the target cluster. According to the CVE description, this reaches cluster-scoped resources and forbidden namespaces, and objects created by a hook Job count too. Only the controller's permissions set the limit.

What makes the attack inconspicuous is above all the timing. The hook sits in the repository and only takes effect when someone deletes the Application, which can be weeks after the commit. A review that only looks at sync results notices nothing.

The three repo-server flaws target a different spot. According to the release notes, two of them run commands in the repo-server and the third reads files there. Why that weighs heavily is stated explicitly in the advisory for CVE-2026-55797: the repo-server can read other teams' Git, Helm and OCI credentials. Taking it over therefore gives access to the sources of all teams.

CVE-2026-113709: Helm plugins from the repository in the repo-server

One of the three repo-server flaws has since received its own CVE number and deserves a closer look, because it needs very few permissions. CVE-2026-113709 (GHSA-fw5c-w8rc-j7fx) was published on October 20 and carries CVSS 9.9 with the vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. According to the CVE description, every version from 2.1.0 up to before 3.3.15, 3.4.10, 3.5.4 and 3.6.0-rc2 is affected, but only where an operator has enabled --enable-helm for Kustomize builds.

The mechanism exploits a property of Helm. Helm supports so-called downloader plugins that load charts over their own protocols, and it looks for plugins in its data directory. Kustomize can include Helm charts via helmCharts, and with helmGlobals.configHome a Kustomization defines where Helm finds its configuration and data directories. If this path points into the repository, Helm loads a downloader plugin from <configHome>/.data/plugins according to the CVE description, without it ever having been installed, and runs its program in argocd-repo-server as soon as a chart URL uses the plugin's protocol. The command runs as the repo-server user and can read repository credentials and anything else the process can see.

The second delivery path is notable. Besides a commit to a repository that an Application builds, the files can be uploaded via POST /api/v1/applications/manifestsWithFiles, which argocd app diff --local --server-side-generate also uses. According to the description, the get permission on an existing Application is enough for this, without update, sync or repository write permissions. In many instances almost all users have read access to Applications, for example when policy.default in argocd-rbac-cm is set to role:readonly and thus applies to every signed-in user. This turns a read permission into an execution permission in the repo-server, which holds the Git, Helm and OCI credentials of all teams.

The CVE description also names the origin. Kustomize 4.1.0 first passed helmGlobals.configHome through to Helm, and Argo CD 2.1.0 switched to Kustomize 4.1.2 with PR #6059. The flaw therefore did not originate in Argo CD itself, but through a new option of an embedded component that passed an input field from the repository all the way into Helm's plugin lookup. According to the 3.5.4 release notes, Kustomize builds with Helm ignore helmGlobals.configHome since the fix, and Helm plugins from that directory no longer run. Charts from standard http, https and oci repositories are not affected.

For hardening, this leads above all to one question: do you really need --enable-helm? Argo CD sets the option via kustomize.buildOptions in the argocd-cm ConfigMap, and where it is absent, the instance is not affected according to the CVE description. If you need Helm charts in Kustomize, you should additionally allow the repo-server only the Git, Helm and OCI sources it actually uses via NetworkPolicy, so that an executed plugin cannot freely send stolen credentials outside. I derive this from the mechanism, it is not a recommendation from the advisory. The related CVE-2026-113708 shows the limit of this measure: there, according to the CVE record, the attacker can get the output of their command back through manifest-generation errors, without any outbound connection. An egress rule therefore only limits part of the damage. With an EPSS estimate of 0.53 percent on October 30 and no KEV entry, the acute danger is smaller than with the hook bypass, but the fix is in the same versions.

Upgrade, behaviour changes and interim measures

The only complete fix is the upgrade to 3.5.4, 3.4.10 or 3.3.15, and if you test release candidates, use 3.6.0-rc2. There is no patch for 2.x and 3.0 to 3.2, where the only way is an upgrade to 3.3 or newer.

You should check two behaviour changes before rolling out. According to the release notes, Kustomize builds with Helm now ignore helmGlobals.configHome, so Helm plugins from that directory no longer work, while standard http, https and oci chart repositories are unaffected. Argo CD also now rejects OCI manifests larger than 4 MiB.

Until the upgrade is in place, the risk can be lowered depending on the vulnerability, but not removed. For CVE-2026-77459, the attacker needs write access to a repository that an Application reads. According to the advisory, there is no setting that subjects delete hooks to the project check while they are in use. It therefore recommends keeping this group small, restricting who can delete Applications and narrowing the application-controller's Kubernetes permissions so that a hook cannot reach sensitive namespaces and APIs. For CVE-2026-113709, instances without --enable-helm are not affected according to the CVE description. If you do not build Helm charts via Kustomize, remove the option from kustomize.buildOptions in argocd-cm.

For CVE-2026-55797, the advisory says there is no setting that keeps proxies for SSH repositories while removing the shell call. Instead it names two steps: untrusted users must not create or update repositories, including through project-scoped repository permissions, and no proxy should be set on SSH repositories or matching credential templates. For CVE-2026-113708 and CVE-2026-113672, the CVE records name no setting that replaces the upgrade. For CVE-2026-113708, according to the record, replacing Kustomize with a newer version is not enough either, because the missing option separator in the git fetch call remains. Both flaws can also be exploited via manifestsWithFiles with mere read access to an Application, so a small group of people with write access helps little here.

Detection and verification

What determines vulnerability is the version of the Argo CD components in the cluster, not that of the CLI. If it is below the fixed versions, the instance is affected. For CVE-2026-113709, it also matters whether kustomize.buildOptions in argocd-cm contains the --enable-helm option.

You will find traces of a hook bypass in your Applications' repositories. Search them for the annotation argocd.argoproj.io/hook with the values PreDelete or PostDelete and compare namespace and resource type with the AppProject for each hit. A hook with a foreign namespace or a cluster-scoped resource type is suspicious. This search is my own conclusion and not vendor guidance.

For CVE-2026-55797, the advisory recommends reviewing repository and credential template Secrets for unexpected proxy values. According to the Argo CD docs, these Secrets carry the label argocd.argoproj.io/secret-type with the value repository or repo-creds. A proxy on an SSH URL stands out, especially with special characters in the host.

The Argo CD team has not published any IoCs. As of October 31, none of the vulnerabilities is in CISA's KEV catalog, and I found no reports of attacks in the wild. On October 30, EPSS estimated the probability of exploitation in the next 30 days at 0.50 percent for CVE-2026-77459, 0.53 to 0.84 percent for the three repo-server flaws and 1.87 percent for CVE-2026-55797.

Recommendation for operators

Act now if several teams or tenants share one Argo CD instance and AppProjects draw the line between them. The same applies if people outside the platform team may write to tracked repositories, create repositories or, with --enable-helm active, read Applications. Then schedule the upgrade before the next regular maintenance window. Instances on 2.x or 3.0 to 3.2 also need an upgrade path.

Monitoring is enough if only a small, trusted team writes to all tracked repositories and manages the repositories. The upgrade remains mandatory but can go into the regular window. Check the changes for Helm in Kustomize and for OCI manifests beforehand.

In the end, what I say about every vulnerability applies: patches and updates belong in automation. When Renovate or Dependabot propose new versions of the Argo CD Helm chart and images as merge requests and the pipeline tests them against a staging instance, a release like 3.5.4 is a matter of hours rather than weeks. A cooldown period for routine updates protects against compromised releases, and you exempt security updates from it. The behaviour changes in this release show the benefit particularly well, because a build that relied on Helm plugins from helmGlobals.configHome then fails in staging and not in production. If you update by hand, on the other hand, you easily get stuck on versions without patches, as is now happening to users of 2.x and 3.0 to 3.2, and then have to risk a big jump across several minor versions at once.

Conclusion

Argo CD's October release closes eight vulnerabilities, four of them critical, and the hook bypass hits the core of the tenant model. A rule that only applies on the main path is no boundary, and that holds beyond Argo CD for every policy check in deployment. CVE-2026-113709 adds a second lesson. A new option in an embedded component can pass a field from the repository all the way to a place where code is loaded, without anything having changed in your own code. If you use AppProjects to separate teams, you should therefore upgrade now and then review who may write to which repositories and which build options the repo-server really needs.

Sources

• GitHub: Argo CD release v3.5.4 (6 October 2026)
• GitHub advisory GHSA-fmxq-cgp8-87wp (CVE-2026-77459)
• OSV: CVE-2026-77459
• OpenCVE: CVE-2026-77459
• OSV: GHSA-j6cw-g6p4-7hch (CVE-2026-55797)
• GitHub advisory GHSA-9v9p-x54c-58gc
• GitHub advisory GHSA-fw5c-w8rc-j7fx (CVE-2026-113709)
• OSV: CVE-2026-113709
• OSV: CVE-2026-113708
• OSV: CVE-2026-113672
• OpenCVE: CVE-2025-61560
• CISA: Known Exploited Vulnerabilities Catalog
• Argo CD docs: Kustomizing Helm charts
• Argo CD PR #6059: upgrade to kustomize 4.1.2
• Kustomize PR #3784
• FIRST EPSS: CVE-2026-113709
• GitHub advisory GHSA-m3vr-7329-44ww
• Argo CD docs: Sync Phases and Waves
• Argo CD docs: Declarative Setup
• Security Online: Four Critical Argo CD Vulnerabilities Fixed