CVE-2026-9641: Crypt::PBKDF2 Weak Default Algorithm and Iteration Count
Crypt::PBKDF2, a Perl cryptographic library, uses cryptographic settings that are too weak by modern standards in versions before 0.261630. Specifically, the library defaults to HMAC-SHA1 (an older algorithm suitable only for legacy compatibility) and performs only 1,000 iterations of the key derivation process. Modern best practices recommend 220,000 to 1,400,000 iterations depending on the algorithm chosen. This gap between defaults and best practices weakens password protection for applications that rely on these defaults without customization.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 5.3 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
- Weaknesses (CWE)
- CWE-916
- Affected products
- 0 configuration(s)
- Published / Modified
- 2026-06-12 / 2026-06-17
NVD description (verbatim)
Crypt::PBKDF2 versions before 0.261630 for Perl have a weak default algorithm and number of iterations. The default algorithm is HMAC-SHA1, which should only be used for legacy systems. These versions default to using 1000 iterations. Depending on the chosen algorithm, 220,000 to 1,400,000 iterations should be used.
7 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
Crypt::PBKDF2 is a Perl module implementing PBKDF2 (Password-Based Key Derivation Function 2), which is used to derive cryptographic keys from passwords. The vulnerability stems from two configuration weaknesses in versions prior to 0.261630: (1) the default hash algorithm is HMAC-SHA1, which cryptographic standards now recommend only for backward compatibility with legacy systems, and (2) the default iteration count of 1,000 is significantly below the NIST and industry-recommended minimum range of 220,000–1,400,000 iterations (depending on algorithm choice). Lower iteration counts reduce the computational cost of brute-force and dictionary attacks against derived keys. While PBKDF2 is not broken, these weak defaults mean that applications using the library without explicit parameter tuning will produce keys that are easier to attack than intended.
Business impact
Organizations using Crypt::PBKDF2 in password storage, key derivation, or authentication workflows may be storing or transmitting credentials protected by weaker-than-intended cryptography. If an attacker obtains a password hash or derived key, the low iteration count reduces the time required to brute-force or dictionary-attack it. This could lead to unauthorized access to user accounts or protected resources. The risk is elevated for high-value applications (financial, healthcare, identity services) but is mitigated if applications explicitly override the weak defaults with strong parameters, or if the library is used only for non-security-critical purposes.
Affected systems
Crypt::PBKDF2 for Perl versions before 0.261630 are affected. The library is distributed via CPAN and is used by Perl applications that require password-based key derivation. Without a comprehensive supply-chain inventory, the exact scope of affected systems is unknown; however, any Perl application using Crypt::PBKDF2 with default parameters and relying on it for password security is potentially at risk.
Exploitability
Exploitation requires an attacker to obtain a password hash or derived key, which typically happens through database compromise, log exposure, or network interception. Once obtained, an attacker can perform offline brute-force or dictionary attacks more efficiently than intended because the iteration count is low. The attack does not require network access to the application (the vector is AV:N in the context of attacking a compromised credential), but it does require possession of the hash material. The ease of attack is moderate: while specialized GPU or ASIC hardware can accelerate brute-force attempts, the low iteration count makes such attacks practical for attackers with standard computing resources and time.
Remediation
Upgrade Crypt::PBKDF2 to version 0.261630 or later. Verify the upgrade in your Perl module repository (CPAN or vendor distribution). After upgrading, review any hardcoded password-derivation code in your applications: if you explicitly configured weak parameters in your code, update those configurations to use NIST-recommended iteration counts (220,000–1,400,000) and a modern algorithm such as HMAC-SHA256 or HMAC-SHA512. If your application was relying entirely on Crypt::PBKDF2 defaults, upgrading the module will automatically apply stronger defaults going forward.
Patch guidance
Update Crypt::PBKDF2 to version 0.261630 or later using your Perl package manager (e.g., `cpanm Crypt::[email protected]` or `perl -MCPAN -e 'install Crypt::PBKDF2'`). Consult your vendor or organization's Perl distribution for availability and timeline. After patching, test your application's password-derivation and authentication flows to confirm no regressions. If you manage a supply chain that includes applications depending on Crypt::PBKDF2, coordinate updates across affected services.
Detection guidance
Scan your Perl module inventory for Crypt::PBKDF2 versions below 0.261630 using `cpan` queries or by examining `META.yml` and `Makefile.PL` files in your codebase. Check application logs or code for instantiations of Crypt::PBKDF2 without explicit iteration-count or algorithm parameters; these indicate reliance on weak defaults. If you have encrypted password stores or key material derived with pre-0.261630 versions, review their creation date and consider re-derivation with the patched version. Monitor for any known credential exposures from your organization's systems.
Why prioritize this
This vulnerability warrants prompt but not emergency response. The CVSS score of 5.3 (Medium) reflects the practical difficulty of exploiting it (requiring prior credential compromise) but acknowledges the real risk to password security. Prioritize it above low-severity issues if Crypt::PBKDF2 is used in customer-facing or high-assurance password systems; deprioritize slightly if it is used only in legacy or non-critical paths. Organizations relying on strong overrides of the defaults (explicit iteration counts and modern algorithms) face minimal risk and can plan updates more flexibly.
Risk score, explained
The CVSS 3.1 score of 5.3 reflects a Medium severity because: (1) the attack vector is network-accessible (the attacker can interact with password reset, login, or key-recovery flows to indirectly trigger use of weak derivation), (2) no privileges or user interaction are required, (3) the impact is confidentiality loss (weak key material can be brute-forced), (4) integrity and availability are not directly impacted, and (5) the scope is unchanged (the attacker only affects the target application, not others). The score does not factor in the prerequisite of credential compromise, which is why the severity remains Medium rather than High. Organizations storing particularly sensitive data or operating in regulated sectors should treat this as High priority internally.
Frequently asked questions
Do I need to patch if I explicitly set strong iteration counts in my code?
No, you do not need to patch urgently for security reasons. Your explicit strong parameters override the weak defaults. However, you should still upgrade to 0.261630 or later as a best practice to ensure that any future code relying on defaults is secure, and to simplify maintenance.
What happens to existing passwords or keys derived with weak settings?
Existing password hashes and derived keys remain as they were; upgrading the module does not automatically re-derive them. If you have a large password database, you can either: (1) re-derive passwords at the next user login using the new defaults, or (2) perform a batch offline re-derivation if your security posture permits it. Document the transition for your security audit.
Is HMAC-SHA1 completely broken?
HMAC-SHA1 is not cryptographically broken in the sense of being invertible, but it is considered outdated for new deployments. Combined with only 1,000 iterations, it offers insufficient resistance to brute-force attacks. Modern standards (NIST SP 800-132, Argon2) recommend HMAC-SHA256, HMAC-SHA512, or specialized functions with much higher iteration counts.
How do I verify that my patched version is using better defaults?
After upgrading, you can test by instantiating Crypt::PBKDF2 without parameters and checking its iteration count and algorithm. Consult the module's documentation or changelog (typically available on CPAN) to confirm the new defaults. If you have unit tests for your key-derivation logic, add assertions that verify iteration count and algorithm meet your organization's standards.
This analysis is provided for informational purposes and reflects publicly available information as of the publication date. No liability is assumed for the accuracy or completeness of third-party data. Always verify patch availability, compatibility, and applicability with your vendor before deployment. Consult your organization's security and compliance teams before implementing changes to cryptographic systems. The information in this page does not constitute legal, compliance, or professional security advice. Source: NVD (public-domain), retrieved 2026-07-20. Analysis generated by SEC.co (claude-haiku-4-5).
Weaknesses (CWE)
Related vulnerabilities
- CVE-2026-25861MEDIUMQloApps MD5 Password Hashing Vulnerability—Weak Cryptography Enables Credential Compromise
- CVE-2026-44611MEDIUMDanelec MacGregor VDR Password Hashing Weakness – CVSS 5.4
- CVE-2016-20064MEDIUMWP Vault 0.8.6.6 Arbitrary File Read via Directory Traversal
- CVE-2016-20067MEDIUMWordPress CP Polls CSRF Vulnerability
- CVE-2016-20070MEDIUMPrivilege Escalation & Stored XSS in WordPress Booking Calendar Contact Form 1.0.23
- CVE-2016-20074MEDIUMWordPress Lazy Content Slider CSRF Vulnerability – Patch & Detection Guide
- CVE-2016-20077MEDIUMWordPress Photocart Link Plugin Local File Inclusion Vulnerability
- CVE-2016-20078MEDIUMWordPress IMDb Profile Widget Local File Inclusion Vulnerability