GHSA-pwfw-mgfj-7g3g
HIGHGHSA-pwfw-mgfj-7g3g is a high-severity (CVSS 7.5) CWE-391 vulnerability in ecdsa. O3 Security confirms whether GHSA-pwfw-mgfj-7g3g is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
ecdsa Denial of Service vulnerability in signature verification and signature malleability
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.
How urgent is this, really
GHSA-pwfw-mgfj-7g3g plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 369,023 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
ecdsaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
possible DoS in signature verification and signature malleability
Impact
Code using VerifyingKey.verify() and VerifyingKey.verify_digest() may receive exceptions other than the documented BadSignatureError when signatures are malformed. If those other exceptions are not caught, they may lead to program termination and thus Denial of Service
Code using VerifyingKey.verify() and VerifyingKey.verify_digest() with sigdecode option using ecdsa.util.sigdecode_der will accept signatures even if they are not properly formatted DER. This makes the signatures malleable. It impacts only applications that later sign the signatures or verify signatures of signatures, e.g. Bitcoin.
All versions between 0.5 and 0.13.2 (inclusive) are thought to be vulnerable. Code before 0.5 may be vulnerable but didn't receive extended analysis to rule this issue out.
Patches
The patches have been merged to master branch in https://github.com/warner/python-ecdsa/pull/115.
The backported patches for a release in the 0.13 branch are in https://github.com/warner/python-ecdsa/pull/124
They are part of the 0.13.3 release.
There are no plans to backport them to earlier releases.
Workarounds
It may be possible to prevent the Denial of Service by catching also UnexpectedDER, IndexError and AssertionError exceptions. That list hasn't been verified to be complete though. If those exceptions are raised, the signature verification process should consider the signature to be invalid.
To remediate signature malleability and the Denial of Service vulnerability, it may be possible to first verify that the signature is properly DER formatted ECDSA-Sig-Value, as defined in RFC3279, before passing it to verify() or verify_digest() methods. If the signature is determined to not follow the DER or encode a different structure, the signature verification process should consider the signature to be invalid.
References
https://en.bitcoinwiki.org/wiki/Transaction_Malleability
For more information
If you have any questions or comments about this advisory please open an issue in python-ecdsa project.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | ecdsa | all versions | 0.13.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ecdsa. 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 ecdsa to 0.13.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pwfw-mgfj-7g3g 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-pwfw-mgfj-7g3g 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-pwfw-mgfj-7g3g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
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.
Although Red Hat OpenStack Platform ships the flawed code, RHOSP does not actually use python-ecdsa's functionality. As such, Red Hat OpenStack Platform will not be providing a fix for python-ecdsa at this time. Current releases of Red Hat Virtualization Manager no longer includes python-ecdsa as a dependency. While…
Frequently Asked Questions
Is GHSA-pwfw-mgfj-7g3g in your dependencies?
O3 detects GHSA-pwfw-mgfj-7g3g across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.