How severe is GHSA-r4pg-vg54-wxx4?

No CVSS score has been assigned to GHSA-r4pg-vg54-wxx4 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-r4pg-vg54-wxx4?

GHSA-r4pg-vg54-wxx4 affects the following packages: github.com/cert-manager/cert-manager (Go), github.com/cert-manager/cert-manager (Go), github.com/cert-manager/cert-manager (Go). Ecosystems affected: Go.

How do I fix GHSA-r4pg-vg54-wxx4?

Update github.com/cert-manager/cert-manager to 1.12.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r4pg-vg54-wxx4 is resolved across your whole dependency graph.

How do I detect GHSA-r4pg-vg54-wxx4 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/cert-manager/cert-manager, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-r4pg-vg54-wxx4 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 GHSA-r4pg-vg54-wxx4 actively exploited in the wild?

No public exploit code has been indexed for GHSA-r4pg-vg54-wxx4 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 GHSA-r4pg-vg54-wxx4?

GHSA-r4pg-vg54-wxx4 has an EPSS (Exploit Prediction Scoring System) score of 0.7%, placing it in the 52th 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 GHSA-r4pg-vg54-wxx4?

GHSA-r4pg-vg54-wxx4 is classified as Improper Input Validation (CWE-20). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-r4pg-vg54-wxx4 published, and has it been updated?

GHSA-r4pg-vg54-wxx4 was published on November 20, 2024 and was last updated on September 10, 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

cert-manager ha a potential slowdown / DoS when parsing specially crafted PEM inputsGHSA-r4pg-vg54-wxx4

Fix: cert-manager/cert-manager#7400

GHSA-r4pg-vg54-wxx4 is a Improper Input Validation vulnerability in github.com/cert-manager/cert-manager. A fix is available for github.com/cert-manager/cert-manager — see the affected versions and patch details below.

Also known asCVE-2024-12401GO-2024-3282

Published

Nov 20, 2024

Updated

Sep 10, 2026

Affected

3 pkgs

Patched

3 / 3

Exploits

None indexed

Exploitation data as of Nov 2, 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 GHSA-r4pg-vg54-wxx4.

EPSS Exploitation Probability

via FIRST.org ↗

0.7%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs52th percentile — riskier than 52% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

3 pkgs affected

🐹github.com/cert-manager/cert-manager🐹github.com/cert-manager/cert-manager🐹github.com/cert-manager/cert-manager

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

cert-manager packages which call the standard library pem.Decode() function can take a long time to process specially crafted invalid PEM data.

If an attacker is able to modify PEM data which cert-manager reads (e.g. in a Secret resource), they may be able to use large amounts of CPU in the cert-manager controller pod to effectively create a denial-of-service (DoS) vector for cert-manager in the cluster.

Secrets are limited in size to 1MiB, which reduces the impact of this issue; it was discovered through an ~856kB fuzz test input which causes pem.Decode to take roughly 750ms to reject the input on an M2 Max Macbook Pro. By way of comparison, a valid PEM-encoded 4096-bit RSA key takes roughly 70µs to parse on the same machine.

Given the required size of PEM data needed to present a realistic DoS vector, an attacker would need to create or insert many different large sized resources in the cluster, and so the best secondary defense is to ensure that sensible limits are placed via RBAC.

This issue affects all versions of cert-manager to have been released since at least v0.1.0 (since pem.Decode is core functionality for cert-manager). All supported releases are patched.

Patches

The fixed versions are v1.16.2, v1.15.4 and v1.12.14.

master branch: https://github.com/cert-manager/cert-manager/pull/7400
release-1.16 branch: https://github.com/cert-manager/cert-manager/pull/7401
release-1.15 branch: https://github.com/cert-manager/cert-manager/pull/7402
release-1.12 branch: https://github.com/cert-manager/cert-manager/pull/7403

Workarounds

Ensure that RBAC is scoped correctly in your cluster. If a user is able to modify resources containing PEM data to be able to exploit this, it's like that those permissions are a bigger security threat than this issue - especially for Secret resources.

References

Upstream issue: https://github.com/golang/go/issues/50116
Similar issue: https://github.com/sigstore/sigstore/issues/198
Google OSSFuzz: https://issues.oss-fuzz.com/issues/376728466

Affected Packages

3 total 3 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/cert-manager/cert-manager`	all versions	1.12.14`go get github.com/cert-manager/cert-manager@v1.12.14`
🐹Go	`github.com/cert-manager/cert-manager`	≥ 1.13.0-alpha.0&&< 1.15.4	1.15.4`go get github.com/cert-manager/cert-manager@v1.15.4`
🐹Go	`github.com/cert-manager/cert-manager`	≥ 1.16.0-alpha.0&&< 1.16.2	1.16.2`go get github.com/cert-manager/cert-manager@v1.16.2`

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/cert-manager/cert-manager, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/cert-manager/cert-manager to 1.12.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r4pg-vg54-wxx4 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.

Frequently Asked Questions

### Impact cert-manager packages which call the standard library `pem.Decode()` function can take a long time to process specially crafted invalid PEM data. If an attacker is able to modify PEM data which cert-manager reads (e.g. in a Secret resource), they may be able to use large amounts of CPU in the cert-manager controller pod to effectively create a denial-of-service (DoS) vector for cert-manager in the cluster. Secrets are limited in size to [1MiB](https://kubernetes.io/docs/concepts/configuration/secret/#restriction-data-size), which reduces the impact of this issue; it was discover

O3 Security · Impact-Aware SCA

Is GHSA-r4pg-vg54-wxx4 in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works