CVE-2026-14570: Crypt::DSA Private Key Recovery via Biased Random Number Generation

Technical summary

The vulnerability stems from Crypt::DSA::Util::makerandom, the random number generation function used to derive both the DSA signing nonce (k) and the private key (x). To guarantee that generated values have exactly N bits, the implementation forces the top bit to always be 1. This deterministic bit-fixing removes uniformity from the distribution: instead of the top bit being randomly 0 or 1 as it should be, it is always set. DSA security depends critically on the nonce being uniformly random and secret; a biased or partially deterministic nonce enables lattice attacks. An attacker collecting signatures {(r, s)} and the corresponding message hashes, combined with the public key, can construct a lattice and use techniques such as the LLL algorithm to recover the private key. The vulnerability affects key generation as well, since the private key itself is drawn from the same biased source.

Business impact

Organizations and individuals relying on Crypt::DSA for cryptographic signing face a complete loss of signature security. Any private keys generated or used by affected versions should be revoked and replaced. Existing signatures cannot be trusted to prove authenticity or non-repudiation. For software supply chains, open-source projects, or infrastructure using Crypt::DSA for code signing, artifact verification, or authentication, a breach of signing keys could undermine trust in all downstream artifacts. The scope of impact depends on adoption: Perl-based systems and modules using this library for DSA operations are at risk. Remediation requires upgrading to version 1.22 or later, regenerating all signing keys, and potentially re-signing critical artifacts.

Affected systems

Crypt::DSA versions prior to 1.22 for Perl are affected. The vulnerability impacts any system or application that uses this library for DSA signing or key generation. This includes Perl applications, CPAN modules that depend on Crypt::DSA, and any infrastructure that relies on those modules for cryptographic operations. No vendor-specific product information is available in the advisory, indicating this is a library-level issue affecting a broad but specialized ecosystem.

Exploitability

Exploitability is high in mathematical and practical terms. An attacker does not need special network access—the attack is entirely offline and requires only the public key (assumed public or easily obtained) and a modest number of signatures (the advisory does not specify an exact threshold, but lattice attacks typically succeed with tens to hundreds of signatures). No user interaction or special privileges are required. The attack is feasible without exceptional computational resources for reasonable key sizes. However, actual exploitation requires sophisticated cryptanalytic knowledge and lattice reduction tools. The attack is not a zero-click remote code execution; it is a passive cryptanalytic break that reveals the private key over time. Real-world exploitation risk depends on whether attackers collect signed artifacts or intercept communications.

Remediation

Immediately upgrade Crypt::DSA to version 1.22 or later. After upgrading, all private keys that were generated or used with earlier versions must be considered compromised and should be revoked. Generate new signing keys using the patched version. For critical applications, re-sign any artifacts (code, packages, certificates) that were signed with old keys. Review audit logs and artifact repositories to identify which signatures were created under vulnerable versions, and flag them for re-validation or re-signing. Organizations should notify users of any signed content that relied on potentially compromised keys.

Patch guidance

Upgrade Crypt::DSA from CPAN to version 1.22 or later. For Perl environments, use `cpan Crypt::DSA` or your package manager (e.g., apt, yum, brew) if the library is packaged. Verify the patched version is in use by checking `perl -MCrypt::DSA -e 'print $Crypt::DSA::VERSION'`. After patching, existing private keys retain their biased properties and must not be reused; generate fresh keys with the patched library. Test the upgrade in a non-production environment first to ensure dependent modules are compatible with version 1.22 or later.

Detection guidance

Identify systems using Crypt::DSA by scanning Perl module lists, CPAN dependency declarations, and package manifests. For production systems, query `perl -MCrypt::DSA -e 'print $Crypt::DSA::VERSION'` or check package manager logs (`apt list --installed | grep perl-crypt-dsa`, etc.). Review any applications or scripts that import or call Crypt::DSA functions for DSA signing. Examine artifact repositories and version control logs to identify signatures created during periods when vulnerable versions were in use. Check modification dates of private keys and cross-reference with the timeline of library versions in use. Monitor for unexpected key rotation or signing events that might indicate attacker key recovery attempts.

Why prioritize this

This is a high-severity cryptographic flaw affecting the core security property of digital signatures. The CVSS 3.1 score of 7.5 reflects high confidentiality impact (private key recovery) with low attack complexity and no privilege or user interaction required. Although not actively exploited in the wild according to KEV data, the mathematical nature of the vulnerability means exploitation is deterministic once an attacker has signatures and a public key. For any organization using affected versions, key compromise should be assumed. Prioritize based on: (1) whether your environment uses Crypt::DSA; (2) whether signing keys have been used operationally; (3) whether signed artifacts are critical to your supply chain or user trust.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) is driven by complete loss of confidentiality (private key recovery) via a network-accessible attack vector with low complexity and no prerequisites. The score does not reflect integrity or availability impact because the vulnerability does not directly modify or delete data or disrupt service; rather, it silently breaks the security assumption underpinning signature verification. The practical risk is highest for organizations where signing keys are operational and signatures are relied upon for trust decisions.

Frequently asked questions