NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
CRITICAL severity

Step CA Has Authorization Bypass in ACME and SCEP ProvisionersGHSA-h8cp-697h-8c8p

CRITICALFix: smallstep/certificates@1011f5f

GHSA-h8cp-697h-8c8p is a critical-severity (CVSS 10) Improper Authentication vulnerability in github.com/smallstep/certificates. A fix is available for github.com/smallstep/certificates — see the affected versions and patch details below.

Also known asCVE-2025-44005GO-2025-4180
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-h8cp-697h-8c8p.

EPSS Exploitation Probability

via FIRST.org ↗
9.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs95th percentile — riskier than 95% of all scored CVEsHighest risk
0.00%3.94%7.87%11.8%0.0%9.1%May 26Sep 26Nov 26

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

1 pkg affected
🐹github.com/smallstep/certificates

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

Summary

A security fix is now available for Step CA that resolves a vulnerability affecting deployments configured with ACME and/or SCEP provisioners. All operators running these provisioners should upgrade to the latest release (v0.29.0) immediately.

The issue was discovered and disclosed by a research team during a security review. There is no evidence of active exploitation.

To limit exploitation risk during a coordinated disclosure window, we are withholding detailed technical information for now. A full write-up will be published in several weeks.

Embargo List

If your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list.

Acknowledgements

This issue was identified and reported by Stephen Kubik of the Cisco Advanced Security Initiatives Group (ASIG)

Stay safe, and thank you for helping us keep the ecosystem secure.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/smallstep/certificatesall versions0.29.0go get github.com/smallstep/certificates@v0.29.0

Detection & mitigation playbook

Open-source dependency

  1. Detect

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

  2. Fix

    Update github.com/smallstep/certificates to 0.29.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h8cp-697h-8c8p is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

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 HatCritical

No Red Hat products are impacted, because the affected component (Step CA) is not used or provided by any products. This vulnerability was marked as a Critical vulnerability because it allows a remote, unauthenticated attacker to bypass core authorization mechanisms of a Certificate Authority and directly issue…

Workaround published by Red Hat
No mitigation is currently available that meets Red Hat Product Security’s standards for usability, deployment, applicability, or stability. But the exposure can be minimized by restricting or blocking access to the /sign endpoint through network controls or reverse proxies.
Source: Red Hat security advisory for GHSA-h8cp-697h-8c8p (CC BY 4.0)

Frequently Asked Questions

## Summary A security fix is now available for Step CA that resolves a vulnerability affecting deployments configured with ACME and/or SCEP provisioners. All operators running these provisioners should upgrade to the latest release (`v0.29.0`) immediately. The issue was discovered and disclosed by a research team during a security review. There is no evidence of active exploitation. To limit exploitation risk during a coordinated disclosure window, we are withholding detailed technical information for now. A full write-up will be published in several weeks. --- ## Embargo List If your or
O3 Security · Impact-Aware SCA

Is GHSA-h8cp-697h-8c8p in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works
Step CA Has Authorization Bypass in ACME and SCEP…