How severe is CVE-2022-31016?

CVE-2022-31016 has a CVSS score of 6.5/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by CVE-2022-31016?

CVE-2022-31016 affects the following packages: github.com/argoproj/argo-cd (Go), github.com/argoproj/argo-cd/v2 (Go), github.com/argoproj/argo-cd/v2 (Go), github.com/argoproj/argo-cd/v2 (Go), github.com/argoproj/argo-cd/v2 (Go). Ecosystems affected: Go.

How do I fix CVE-2022-31016?

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 CVE-2022-31016 is resolved across your whole dependency graph.

How do I detect CVE-2022-31016 in my Go dependencies?

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.

How do I mitigate CVE-2022-31016 if there is no patch (or I can't update yet)?

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.

Is CVE-2022-31016 actively exploited in the wild?

No public exploit code has been indexed for CVE-2022-31016 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2022-31016?

CVE-2022-31016 has an EPSS (Exploit Prediction Scoring System) score of 0.9%, placing it in the 60th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2022-31016?

CVE-2022-31016 is classified as Uncontrolled Resource Consumption (CWE-400), CWE-770 (CWE-770). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2022-31016 published, and has it been updated?

CVE-2022-31016 was published on June 25, 2022 and was last updated on October 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹

🐹 Go

Not in CISA KEV

MEDIUM severity

CVE-2022-31016 — argo-cd

MEDIUM

CVE-2022-31016 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.

Argo CD vulnerable to Uncontrolled Memory Consumption

Also known asGHSA-jhqp-vf4w-rpwqGO-2022-0495

Published

Jun 25, 2022

Updated

Oct 28, 2026

Affected

5 pkgs

Patched

5 / 5

Exploits

None indexed

Exploitation data as of Nov 7, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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 CVE-2022-31016.

EPSS Exploitation Probability

via FIRST.org ↗

0.9%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs60th percentile — riskier than 60% of all scored CVEsHighest risk

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

5 pkgs affected

🐹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/v2

Real-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

5 total 5 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/argoproj/argo-cd`	≥ 0.7.0&&< 2.1.16	2.1.16`go get github.com/argoproj/argo-cd@v2.1.16`
🐹Go	`github.com/argoproj/argo-cd/v2`	all versions	2.1.16`go 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.10`go 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.5`go 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.1`go get github.com/argoproj/argo-cd/v2@v2.4.1`

Affected Products

1 product · 4 configurations

Application

argo cdargoproj

≥ 2.4.0 && < 2.4.1

range

Detection & mitigation playbook

Open-source dependency

Detect
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 CVE-2022-31016 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.

Red HatModerate

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

### 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](https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/#repository-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 m