CVE-2026-6659

What it actually does

Crypt::PasswdMD5 versions through 1.42 generate password-hash salts using Perl's built-in rand function, which is predictable and not suitable for cryptographic use. Because salts may be guessable or have insufficient entropy, password hashes generated by affected versions can be more vulnerable to offline cracking, precomputation, and correlation attacks if an attacker obtains the hashes. The flaw does not directly grant code execution or authentication bypass by itself; its impact is primarily on the confidentiality of passwords protected by hashes generated with weak salts.

Why it matters to the business

Systems or applications that used affected Crypt::PasswdMD5 versions to create password hashes may have weaker password protection than expected. If password hashes are later exposed through a database leak, backup exposure, log disclosure, or insider access, attackers may be able to recover user passwords more efficiently and reuse them against the application or other services. Although this is not currently listed in CISA KEV and has low EPSS activity, it affects a security-sensitive component and should be addressed during normal patching and credential-hardening cycles.

How an attack unfolds

An attacker first needs access to password hashes that were generated by an affected Crypt::PasswdMD5 version. This access could come from a separate vulnerability, exposed backup, database dump, misconfigured storage location, compromised administrator account, or insider access. Once the attacker has the hashes, they can take advantage of the predictable salt-generation behavior to reduce the cost of offline cracking compared with hashes generated with strong random salts. The attacker then runs password-cracking tools against the collected hashes, prioritizing predictable or repeated salt values and common password guesses. Any recovered passwords can be used for account takeover, credential stuffing, privilege escalation, or lateral movement where users reused passwords.

How to fix it

Upgrade Crypt::PasswdMD5 to a version that replaces Perl rand with a cryptographically secure random number generator as soon as a fixed release is available from the maintainer or package distributor. If no fixed version is available, avoid relying on the module's automatic salt generation; supply salts generated with a cryptographically secure source such as the operating system CSPRNG, or migrate password storage to a modern password-hashing scheme such as Argon2id, bcrypt, scrypt, or PBKDF2 with appropriate parameters. Treat hashes generated by affected versions as potentially weakened: force password resets or rehash passwords at next successful login using a secure password-hashing implementation and strong random salts. Review downstream packages, internal applications, and deployment artifacts for bundled or vendored copies of Crypt::PasswdMD5 through 1.42.

How to confirm the fix worked

Confirm dependency inventories, lockfiles, SBOMs, package manifests, and deployed Perl library paths do not contain Crypt::PasswdMD5 versions through 1.42. In Perl environments, verify the installed module version using package manager metadata or a runtime check such as loading Crypt::PasswdMD5 and printing its VERSION value. Review password-hashing code paths to confirm salts are produced by a cryptographically secure random source or that the application has migrated to a modern password-hashing library. For existing credentials, sample stored hashes to look for repeated, short, or pattern-based salts and verify that newly created or reset passwords receive high-entropy unique salts. After remediation, create test accounts or reset test passwords and confirm the resulting hashes are generated by the updated implementation or replacement algorithm.

Typical attack path

1. Identify an application or service that uses Crypt::PasswdMD5 versions through 1.42 for password hashing.
2. Obtain password hashes through a separate compromise, exposed backup, database leak, file disclosure, or privileged access.
3. Analyze salt values for predictability, repetition, low entropy, or generation patterns.
4. Run offline password-cracking attacks optimized for the predictable salt space and common password choices.
5. Use recovered plaintext passwords to authenticate to the affected application or attempt reuse against other services.
6. Maintain access or escalate privileges using compromised credentials.

How to detect it

This weakness is difficult to detect as active exploitation because cracking occurs offline after an attacker obtains password hashes. Focus detection on evidence that password hashes were accessed, exported, copied, or exposed. Review application, database, file access, backup, object storage, and administrative audit logs for unusual reads of credential stores, bulk exports, backup downloads, suspicious queries against user credential data, or access by unexpected accounts. Investigate large outbound transfers, archive creation near credential repositories, and use of password-cracking tools on compromised hosts. Correlate any suspected hash exposure with subsequent anomalous authentication activity, including successful logins from new geographies, impossible travel, dormant-account use, repeated failed logins followed by success, or reuse of privileged accounts. Also perform exposure detection by identifying deployed Crypt::PasswdMD5 versions through 1.42 and stored hashes with repeated or low-entropy salts.

What your security team should do

• Inventory all applications, scripts, appliances, and packaged products that use Crypt::PasswdMD5, including vendored Perl modules and legacy authentication code.
• Prioritize remediation for internet-facing applications, identity systems, administrative portals, and any service where password hashes may be accessible to operators, backups, or downstream systems.
• Upgrade or replace Crypt::PasswdMD5 through 1.42, and ensure password salts are generated with a cryptographically secure random source.
• Plan password rehashing for all credentials generated by affected versions; force password resets for high-privilege users or where hash exposure is suspected.
• Search for exposed password-hash files, database dumps, backups, debug exports, and logs that may contain generated hashes.
• Monitor for account takeover indicators such as successful logins from unusual locations, password-spraying patterns, and anomalous use of dormant or privileged accounts.
• Strengthen compensating controls including multi-factor authentication, password reuse detection, rate limiting, and credential-stuffing defenses.