CVE-2026-54411

What it actually does

Linux-PAM through 1.7.2 can leak plaintext passwords when the pam_userdb module is configured to compare stored passwords without a recognized hashing method. In the vulnerable path, pam_userdb performs a length check and then compares the supplied password with the stored password using strncmp() or strncasecmp() when case-insensitive mode is enabled. Because these comparisons stop at the first differing byte, authentication response time varies based on how many leading characters are correct and whether the candidate length matches the stored password. An attacker who can repeatedly trigger authentication through a PAM-backed service can use timing measurements to infer the password length and recover the password byte by byte. The issue affects confidentiality of credentials; it does not directly provide code execution, privilege escalation, or data modification without successful password recovery.

Why it matters to the business

If a service uses pam_userdb with plaintext password handling, an attacker may be able to recover valid account passwords through repeated login attempts and timing analysis. This can lead to unauthorized access to systems or applications that rely on PAM authentication, credential reuse across other services, account compromise, and increased incident response costs. The practical risk is highest where the affected PAM configuration is exposed over low-latency networks, where authentication throttling is weak, or where service accounts use static passwords. The CVSS score is moderate and EPSS is currently low, and the vulnerability is not listed in CISA KEV, but environments using pam_userdb with plaintext credentials should treat it as a credential exposure issue requiring configuration review.

How an attack unfolds

An attacker first identifies a PAM-authenticated service that uses pam_userdb, such as a login, VPN, application gateway, or other network-accessible service backed by PAM. The vulnerable condition exists when the pam_userdb configuration stores or compares passwords in plaintext, including configurations using crypt=none, an unrecognized crypt method, or no crypt= argument. The attacker selects a target account and sends many authentication attempts with carefully chosen password guesses. By measuring small differences in response time, the attacker determines whether the guessed password length matches the stored password and then tests candidate prefixes. Because the comparison exits when it encounters the first incorrect character, guesses with longer correct prefixes take measurably different time than guesses that fail earlier. Repeating this process allows the attacker to reconstruct the password one character at a time. Once recovered, the attacker can authenticate normally as the victim account and perform any actions available to that account.

How to fix it

Upgrade Linux-PAM to a vendor-provided fixed release when available. Because no fixed version was provided in the input, consult the operating system or distribution security advisory for the patched package version and prioritize systems where pam_userdb is configured. As an immediate mitigation, do not use pam_userdb with plaintext passwords: remove crypt=none, correct any invalid or unrecognized crypt= argument, and configure a supported password hashing method. Review PAM configuration files for pam_userdb usage and ensure stored credentials are hashed, not plaintext. Add or strengthen rate limiting, lockout, MFA, and authentication delay controls on services that call PAM, especially remotely reachable services. Rotate passwords stored or previously stored in plaintext userdb files, because successful exploitation may not leave clear evidence. Where possible, restrict access to PAM-backed services to trusted networks and disable unused authentication endpoints.

How to confirm the fix worked

Confirm that all Linux-PAM packages are updated to the fixed version specified by the relevant OS or distribution advisory. Review PAM configuration under common locations such as /etc/pam.d/ and verify that pam_userdb is not configured with crypt=none, with an invalid crypt method, or without an intended crypt= setting. Inspect userdb credential stores used by pam_userdb and confirm passwords are hashed using a supported method rather than stored as plaintext. Test exposed PAM-backed services to ensure rate limiting, lockout, or other controls make high-volume timing attacks impractical. If a vendor supplies a regression test or package changelog, verify that pam_userdb no longer uses variable-time plaintext comparison for password checks.

Typical attack path

1. Identify a PAM-authenticated service reachable locally or over a low-latency network path.
2. Determine or assume that the service uses pam_userdb for authentication.
3. Target a known or guessable username.
4. Send repeated login attempts with controlled password candidates.
5. Measure authentication response timing with enough precision to distinguish comparison-length differences.
6. Infer the stored password length from timing behavior around length-matching candidates.
7. Recover the password incrementally by testing candidate characters and observing timing changes for correct prefixes.
8. Authenticate using the recovered password.
9. Use the compromised account's privileges to access systems, data, or downstream services.

How to detect it

Detection should focus on both exposure and possible prior exploitation. For exposure, search PAM configuration files such as /etc/pam.d/* for pam_userdb.so and review the associated arguments for crypt=none, absent crypt= configuration, or unusual crypt method names. Also identify userdb credential files referenced by the module and determine whether they contain plaintext passwords. For exploitation, examine authentication logs from Linux systems and PAM-backed services, including /var/log/auth.log, /var/log/secure, journalctl output for sshd, login, sudo, application gateways, VPN services, and any application-specific PAM integration logs. Look for large numbers of failed authentication attempts against a single account, many attempts from the same source, repeated attempts with varying password lengths, short intervals between attempts, and eventual successful authentication after a long sequence of failures. Network telemetry may show a high volume of authentication requests from a low-latency source to the same service. Because timing attacks may use normal authentication flows and leave no distinctive payload, absence of a unique log signature does not rule out exploitation; combine log review with credential rotation when vulnerable plaintext pam_userdb usage is confirmed.

• pam_userdb.so crypt=none
• pam_userdb.so
• crypt=none
• pam_userdb
• /etc/pam.d/
• /var/log/auth.log
• /var/log/secure
• pam_unix
• authentication failure
• Failed password
• Accepted password
• journalctl -u sshd

What your security team should do

• Inventory systems using Linux-PAM pam_userdb, prioritizing internet-facing, VPN, bastion, application gateway, and other remotely reachable authentication services.
• Search PAM configuration files for pam_userdb.so with crypt=none, missing crypt= settings, or nonstandard crypt method values.
• Immediately remove plaintext pam_userdb password configurations or migrate those accounts to a supported hashed credential store.
• Apply vendor patches for Linux-PAM as soon as fixed packages are available for the operating system distribution.
• Enable or tune authentication rate limiting, lockout thresholds, MFA, and monitoring on services that call PAM.
• Rotate credentials for accounts stored in pam_userdb plaintext databases or exposed through vulnerable services.
• Review authentication logs for high-volume failed login attempts, especially attempts against a single username from a consistent source with systematic password lengths or patterns.
• Treat confirmed password recovery or suspicious repeated timing probes as credential compromise and initiate account containment and password reset procedures.