CVE-2025-47934 — openpgp
Fix: openpgpjs/openpgpjs@43f5f4eCVE-2025-47934 is a CWE-347 vulnerability in openpgp. A fix is available for openpgp — see the affected versions and patch details below.
OpenPGP.js's message signature verification can be spoofed
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- 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-2025-47934.
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.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
openpgpnpmDescription
Impact
A maliciously modified message can be passed to either openpgp.verify or openpgp.decrypt, causing these functions to return a valid signature verification result while returning data that was not actually signed.
This flaw allows signature verifications of inline (non-detached) signed messages (using openpgp.verify) and signed-and-encrypted messages (using openpgp.decrypt with verificationKeys) to be spoofed, since both functions return extracted data that may not match the data that was originally signed. Detached signature verifications are not affected, as no signed data is returned in that case.
In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js.
In other words. any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature.
Both OpenPGP.js v6 and v5 are affected. OpenPGP.js v4 is not affected.
Patches
The issue has been patched in versions 5.11.3 and 6.1.1.
Workarounds
- When verifying inline-signed messages, extract the message and signature(s) from the message returned by
openpgp.readMessage, and verify the(/each) signature as a detached signature by passing the signature and a new message containing only the data (created usingopenpgp.createMessage) toopenpgp.verify. - When decrypting and verifying signed+encrypted messages, decrypt and verify the message in two steps, by first calling
openpgp.decryptwithoutverificationKeys, and then passing the returned signature(s) and a new message containing the decrypted data (created usingopenpgp.createMessage) toopenpgp.verify.
Acknowledgements
We would like to thank:
- Edoardo Geraci and Thomas Rinsma of Codean Labs for finding and reporting this vulnerability
- The Sovereign Tech Agency for sponsoring the OpenPGP.js bug bounty program
- YesWeHack for hosting the OpenPGP.js bug bounty program
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | openpgp | ≥ 5.0.1&&< 5.11.3 | 5.11.3npm install openpgp@5.11.3 |
| 📦npm | openpgp | ≥ 6.0.0-alpha.0&&< 6.1.1 | 6.1.1npm install openpgp@6.1.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openpgp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update openpgp to 5.11.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-47934 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2025-47934 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2025-47934. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2025-47934 in your dependencies?
O3 Security finds CVE-2025-47934 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.