GHSA-fmxq-cgp8-87wp CRITICAL Uncategorized

GHSA-fmxq-cgp8-87wp – Argo CD PreDelete/PostDelete Hook Project Check Bypass

(Updated: ) By wp-post 6 min read

Vulnerability Intelligence Overview

GHSA-fmxq-cgp8-87wp
Advisory Identifier
GHSA-fmxq-cgp8-87wp
Assessed Severity
CRITICAL
Weakness (CWE)
CWE-863
Primary Package
github.com/argoproj/argo-cd/v2 (Go)
Affected Versions
>= 2.10.0, = 3.0.0, < 3.3.15; >= 3.4.0, < 3.4.10; >= 3.5.0, < 3.5.4; >= 3.6.0-rc1, < 3.6.0-rc2
Source Record Published
Last Intelligence Update

Introduction

The advisory GHSA-fmxq-cgp8-87wp (also known as CVE-2026-77459) reports a critical vulnerability in Argo CD. The issue allows PreDelete and PostDelete resource hooks to bypass AppProject destination‑namespace and resource restrictions, potentially letting an attacker create privileged Kubernetes objects during Application deletion.

Vulnerability overview

Attribute Value
OSV advisory ID GHSA-fmxq-cgp8-87wp
CVE identifier and aliases CVE-2026-77459
Summary Argo CD: AppProject destination-namespace and resource restrictions bypassed by PreDelete/PostDelete resource hooks
Affected package names github.com/argoproj/argo-cd/v2, github.com/argoproj/argo-cd/v3
Package ecosystem Go
Published date 2026-10-15T20:19:31Z
Modified date 2026-10-15T20:19:31Z
Severity CRITICAL
Numeric CVSS score Not specified in the supplied OSV record.
CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE identifiers CWE-863
Recorded fixed versions v3.3.15, v3.4.10, v3.5.4, v3.6.0-rc2

Detailed vulnerability explanation

Argo CD validates an Application against its AppProject before creating resources during a normal sync. The validation enforces destination namespaces, cluster servers, and allow/deny lists for both cluster‑scoped and namespaced resources. However, when a PreDelete or PostDelete hook is executed—triggered by the deletion of an Application—the controller creates the hook using its own credentials without performing the AppProject check.

Because the hook runs with the application‑controller’s privileges on the destination cluster, an attacker who can push a malicious hook to the Git repository backing an Application can bypass all project‑level constraints. The hook can create cluster‑scoped objects such as ClusterRoleBinding or resources in namespaces that the AppProject explicitly disallows. The effect is bounded only by the controller’s Kubernetes RBAC permissions, which in typical installations are broad.

Technical analysis

The root cause lies in the code path that handles deletion‑time resource hooks. The creation logic for PreDelete and PostDelete hooks reuses the generic resource‑creation routine but omits the call that enforces the AppProject policy. The vulnerability was introduced when PostDelete hooks were added in commit dcc17f70bf (released in v2.10.0) and later when PreDelete hooks were added in commit 3bf3d8a212 (released in v3.3.0). The omission is present in every release from v2.10.0 onward and in all 3.x branches until the respective patches were back‑ported.

Affected software and versions

Package Ecosystem Introduced Fixed / Last Affected
github.com/argoproj/argo-cd/v2 Go 2.10.0 Last affected: 2.14.21 (no fixed version)
github.com/argoproj/argo-cd/v3 Go 3.0.0 Fixed: 3.3.15
github.com/argoproj/argo-cd/v3 Go 3.4.0 Fixed: 3.4.10
github.com/argoproj/argo-cd/v3 Go 3.5.0 Fixed: 3.5.4
github.com/argoproj/argo-cd/v3 Go 3.6.0-rc1 Fixed: 3.6.0-rc2

Severity and risk interpretation

The advisory’s database‑specific severity is marked **CRITICAL**. The provided CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) reflects a high‑impact, network‑accessible attack where the attacker needs low privileges and no user interaction, and the vulnerability can affect confidentiality, integrity, and availability across the entire cluster (scope: Changed).

Who should investigate

  • Site reliability engineers (SREs) managing Argo CD deployments.
  • DevSecOps teams responsible for GitOps pipelines.
  • Security architects overseeing Kubernetes RBAC policies.
  • Application owners who define AppProject policies.

How to check whether an application is affected

  1. Identify the Argo CD version running in your cluster: 
    kubectl -n argocd get deployment argocd-server -o jsonpath='{.spec.template.spec.containers[0].image}'
  2. Parse the image tag (e.g., argoproj/argocd:v3.2.12) to obtain the version.
  3. Compare the discovered version against the affected ranges listed above. Versions between 2.10.0 and 2.14.21 (inclusive) and any 3.x version prior to the fixed releases (3.3.15, 3.4.10, 3.5.4, 3.6.0-rc2) are vulnerable.
  4. For CI/CD pipelines that pull Argo CD binaries directly, inspect the version command: 
    argocd version --client
  5. Run a software composition analysis (SCA) scan on your container images or Helm charts to surface the Argo CD version automatically.

Remediation and mitigation

  • Upgrade Argo CD to a version that includes the patch. The following releases contain the fix:
    • v3.3.15
    • v3.4.10
    • v3.5.4
    • v3.6.0-rc2 (and later releases)
  • For the 2.x line, no patch is available. Consider migrating to a supported 3.x release.
  • Restrict write access to Git repositories that serve as the source of truth for Argo CD Applications. Only trusted users should be able to push commits that define resource hooks.
  • Limit who can delete Applications, as deletion triggers the vulnerable hooks.
  • Apply principle‑of‑least‑privilege (PoLP) to the application‑controller ServiceAccount. Ensure it cannot create cluster‑scoped resources unless explicitly required.

Post‑remediation verification

  1. Re‑run the version discovery steps to confirm the upgraded version is at least the fixed version.
  2. Regenerate your SBOM (CycloneDX or SPDX) for the Argo CD deployment and verify that the package entry reflects the patched version.
  3. Rescan the deployment with your SCA tooling to ensure the vulnerability is no longer reported.
  4. Test the deletion of a sample Application that contains a PreDelete hook and confirm the hook respects AppProject restrictions (no unauthorized resources are created).
  5. Document the upgrade and verification steps in your change‑management system for audit purposes.

Developer and DevSecOps recommendations

  • Enable automated vulnerability scanning of container images and Helm charts that include Argo CD.
  • Adopt dependency pinning for the Argo CD version in Helm values or manifests to avoid accidental upgrades to vulnerable releases.
  • Integrate SBOM generation into your CI pipeline and monitor the SBOM for newly disclosed advisories.
  • Configure CI/CD gates that block merges of commits introducing new resource hooks unless the author is trusted.
  • Maintain up‑to‑date RBAC policies for the application‑controller ServiceAccount, limiting its ability to create cluster‑wide resources.

Explore on cve.sbom.guru

Authoritative references

Key takeaways

  • Advisory ID: GHSA-fmxq-cgp8-87wp (CVE‑2026‑77459).
  • Vulnerability allows PreDelete/PostDelete hooks to bypass AppProject checks, potentially creating privileged Kubernetes resources.
  • All Argo CD versions from 2.10.0 to 2.14.21 and 3.x releases prior to the patched versions are affected.
  • Fixed in v3.3.15, v3.4.10, v3.5.4, and v3.6.0‑rc2. No patch for 2.x line.
  • Verify your deployment version, upgrade to a patched release, restrict Git repo write access, and tighten controller RBAC.

Freshness note

Vulnerability records can be updated over time. Always consult the authoritative advisory page on cve.sbom.guru and the original GitHub Security Advisory for the latest information, patches, and remediation guidance.