CVE-2025-13470: Ribose RNP · Weak Randomness
Affects Ribose RNPSource CVE Database V5
Not known to be exploited · CVSS 7.7 High.
Data as of 25 Oct 2026, 19:02 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 25% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/AU:Y/RE:H/U:RedExploitation evidence
Disclosed: evidence found.
CVE published 21 Nov 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
GitHubrnpgp/rnppkg:github/rnpgp/rnpOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
European organizations should immediately audit their use of Ribose RNP to identify deployments of version 0.18.0. Until a patched version is released, they should avoid using RNP 0.18.0 for public-key encryption tasks and revert to a previous secure version or alternative OpenPGP implementations. If public-key encryption is essential, switching to passphrase-based encryption (SKESK packets) temporarily can mitigate exposure since it is unaffected. Organizations should monitor Ribose’s official channels for patches and apply updates promptly once available. Additionally, they should implement network-level controls to detect and block suspicious traffic that may attempt to exploit this vulnerability. Encrypting sensitive data with multiple layers or alternative cryptographic tools can provide defense in depth. Regularly reviewing cryptographic libraries and enforcing strict version control policies will help prevent similar regressions. Finally, organizations should conduct security awareness training to highlight the importance of timely patching and cryptographic hygiene.
Description
In RNP version 0.18.0 a refactoring regression causes the symmetric session key used for Public-Key Encrypted Session Key (PKESK) packets to be left uninitialized except for zeroing, resulting in it always being an all-zero byte array. Any data encrypted using public-key encryption in this release can be decrypted trivially by supplying an all-zero session key, fully compromising confidentiality. The vulnerability affects only public key encryption (PKESK packets). Passphrase-based encryption (SKESK packets) is not affected. Root cause: Vulnerable session key buffer used in PKESK packet generation. The defect was introduced in commit `7bd9a8dc356aae756b40755be76d36205b6b161a` where initialization logic inside `encrypted_build_skesk()` only randomized the key for the SKESK path and omitted it for the PKESK path.
References
- github.com/rnpgp/rnp/commit/7bd9a8dc356aae756b40755be76d36205b6b161a (opens in a new tab)
- launchpad.net/ubuntu/+source/rnp (opens in a new tab)
- aur.archlinux.org/packages/rnp (opens in a new tab)
- packages.gentoo.org/packages/dev-util/librnp (opens in a new tab)
- bugzilla.redhat.com/show_bug.cgi?id=2415863 (opens in a new tab)
- access.redhat.com/security/cve/cve-2025-13402 (opens in a new tab)
- open.ribose.com/advisories/ra-2025-11-20/ (opens in a new tab)
- github.com/rnpgp/rnp/releases/tag/v0.18.1 (opens in a new tab)