DoS through large manifest files in Argo CDGHSA-jhqp-vf4w-rpwq
MEDIUMGHSA-jhqp-vf4w-rpwq is a medium-severity (CVSS 6.5) Uncontrolled Resource Consumption vulnerability in github.com/argoproj/argo-cd. A fix is available for github.com/argoproj/argo-cd — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-jhqp-vf4w-rpwq.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
github.com/argoproj/argo-cd🐹github.com/argoproj/argo-cd/v2🐹github.com/argoproj/argo-cd/v2🐹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 versions of Argo CD starting with v0.7.0 are vulnerable to an uncontrolled memory consumption bug, allowing an authorized malicious user to crash the repo-server service. The repo-server is a critical component of Argo CD, so crashing the repo-server effectively denies core Argo CD services (such as syncing Application updates).
To achieve denial of service, the attacker must be an authenticated Argo CD user authorized to deploy Applications from a repository which contains (or can be made to contain) a large file.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
- v2.4.1
- v2.3.5
- v2.2.10
- v2.1.16
The patch introduces a new reposerver.max.combined.directory.manifests.size config parameter, which you should tune before upgrading in production. It caps the maximum total file size of .yaml/.yml/.json files in directory-type (raw manifest) Applications. The default max is 10M per Application. This max is designed to keep any single app from consuming more than 3G of memory in the repo-server (manifests consume more space in memory than on disk). The 300x ratio assumes a maliciously-crafted manifest file. If you only want to protect against accidental excessive memory use, it is probably safe to use a smaller ratio.
If your organization uses directory-type Applications with very many manifests or very large manifests then check the size of those manifests and tune the config parameter before deploying this change to production. When testing, make sure to do a "hard refresh" in either the CLI or UI to test your directory-type App. That will make sure you're using the new max logic instead of relying on cached manifest responses from Redis.
Workarounds
There is no workaround besides upgrading.
To mitigate the issue, carefully limit 1) who can configure repos (determined by RBAC), 2) which repos are allowed (determined by Project limitations), and 3) who has push access to those repos (determined by your SCM provider configuration).
Credits
Disclosed by ADA Logics in a security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.
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 | ≥ 0.7.0&&< 2.1.16 | 2.1.16go get github.com/argoproj/argo-cd@v2.1.16 |
| 🐹Go | github.com/argoproj/argo-cd/v2 | all versions | 2.1.16go get github.com/argoproj/argo-cd/v2@v2.1.16 |
| 🐹Go | github.com/argoproj/argo-cd/v2 | ≥ 2.2.0&&< 2.2.10 | 2.2.10go get github.com/argoproj/argo-cd/v2@v2.2.10 |
| 🐹Go | github.com/argoproj/argo-cd/v2 | ≥ 2.3.0&&< 2.3.5 | 2.3.5go get github.com/argoproj/argo-cd/v2@v2.3.5 |
| 🐹Go | github.com/argoproj/argo-cd/v2 | ≥ 2.4.0&&< 2.4.1 | 2.4.1go get github.com/argoproj/argo-cd/v2@v2.4.1 |
Affected Products
argo cdargoprojDetection & 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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/argoproj/argo-cd to 2.1.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jhqp-vf4w-rpwq is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat OpenShift GitOps 1.3 | openshift-gitops-1/argocd-rhel8:v1.3.12-1 | RHSA-2022:5187 |
| Red Hat OpenShift GitOps 1.3 | openshift-gitops-1/argocd-rhel8:v1.3.11-4 | RHSA-2022:5192 |
| Red Hat OpenShift GitOps 1.4 | openshift-gitops-1/argocd-rhel8:v1.4.9-3 | RHSA-2022:5153 |
| Red Hat OpenShift GitOps 1.5 | openshift-gitops-1/argocd-rhel8:v1.5.3-2 | RHSA-2022:5152 |
Frequently Asked Questions
Is GHSA-jhqp-vf4w-rpwq in your dependencies?
Find it across Go, including transitive dependencies.