GHSA-6p4m-hw2h-6gmw
HIGHController reconciles apps outside configured namespaces when sharding is enabled
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/argoproj/argo-cd/v2🐹github.com/argoproj/argo-cd/v2Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
All Argo CD versions starting with 2.5.0-rc1 are vulnerable to an authorization bypass bug which allows a malicious Argo CD user to deploy Applications outside the configured allowed namespaces.
Description of exploit
Reconciled Application namespaces are specified as a comma-delimited list of glob patterns. When sharding is enabled on the Application controller, it does not enforce that list of patterns when reconciling Applications. For example, if Application namespaces are configured to be argocd-*, the Application controller may reconcile an Application installed in a namespace called other, even though it does not start with argocd-.
Reconciliation of the out-of-bounds Application is only triggered when the Application is updated, so the attacker must be able to cause an update operation on the Application resource.
Limitations
This bug only applies to users who have explicitly enabled the "apps-in-any-namespace" feature by setting application.namespaces in the argocd-cmd-params-cm ConfigMap or otherwise setting the --application-namespaces flags on the Application controller and API server components. The apps-in-any-namespace feature is in beta as of this Security Advisory's publish date.
The bug is also limited to Argo CD instances where sharding is enabled by increasing the replicas count for the Application controller.
Finally, the AppProjects' sourceNamespaces field acts as a secondary check against this exploit. To cause reconciliation of an Application in an out-of-bounds namespace, an AppProject must be available which permits Applications in the out-of-bounds namespace.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
- v2.5.8
- v2.6.0-rc5
Workarounds
Running only one replica of the Application controller will prevent exploitation of this bug.
Making sure all AppProjects' sourceNamespaces are restricted within the confines of the configured Application namespaces will also prevent exploitation of this bug.
Credits
Thanks to ChangZhuo Chen (@czchen) for finding the issue and for contributing the fix!
References
For more information
- Open an issue in the Argo CD issue tracker or discussions
- Join us on Slack in channel #argo-cd
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/argoproj/argo-cd/v2 | ≥ 2.5.0-rc1&&< 2.5.8 | 2.5.8 |
| 🐹Go | github.com/argoproj/argo-cd/v2 | ≥ 2.6.0-rc4&&< 2.6.0-rc5 | 2.6.0-rc5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/argoproj/argo-cd/v2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/argoproj/argo-cd/v2 to 2.5.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6p4m-hw2h-6gmw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-6p4m-hw2h-6gmw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-6p4m-hw2h-6gmw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6p4m-hw2h-6gmw in your dependencies?
O3 detects GHSA-6p4m-hw2h-6gmw across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.