GHSA-pwfw-mgfj-7g3g
HIGHecdsa Denial of Service vulnerability in signature verification and signature malleability
Blast Radius
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.
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.