Crypt::Password EUVD-2026-45894

Exploitation requires that an application expose a code path calling Crypt::Password's check_password (versions ≤0.28) in a way the attacker can invoke repeatedly and time precisely, and that the attacker can collect enough timing samples to overcome network and system jitter. What limits exploitation: the leak is the stored password hash, not the plaintext; success depends on high-resolution, low-noise timing measurements (network latency, load balancers, and rate limiting all degrade feasibility, contradicting the AC:L rating); and there is no authentication bypass - the attacker gains hash-guessing signal, not direct access. No special non-default configuration is required beyond simply using the vulnerable module's check_password.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:N/A:N = 7.5) rates this as network-reachable, low-complexity, unauthenticated with high confidentiality impact - but multiple other signals argue the real-world risk is considerably lower. EPSS is 0.14% (4th percentile), SSVC exploitation is 'none', and no POC is known. Most importantly, practical exploitation of a timing side channel over a network is hard: an attacker must collect large numbers of samples to average out network and scheduling jitter, which conflicts with the AC:L (low complexity) rating - a real assessment would lean toward AC:H. What actually leaks is the stored hash value, not the plaintext password, and only when an attacker can repeatedly invoke check_password and precisely measure response time, so C:H may overstate impact. SSVC 'Automatable: yes' and 'Technical Impact: partial' are consistent with a low-severity information-disclosure issue. Net: treat this as a low-to-moderate priority hardening fix rather than an urgent, actively-exploited threat. Note the discrepancy: CVSS AC:L versus the inherent statistical difficulty of remote timing attacks - verify complexity assumptions before prioritizing.

An attacker who can repeatedly submit authentication attempts against an application built on Crypt::Password measures the response time of check_password across many requests and uses the byte-by-byte timing differences of the eq comparison to progressively recover the stored hash one character at a time. No POC is currently known, and the statistical sampling required over a network makes this slow and noisy in practice.