Crypt::Argon2 CVE-2026-8463

The triggering condition is precise: argon2_verify must receive a zero-length (empty string) value as its encoded hash argument. This arises when a caller does not validate that the hash retrieved from storage is non-empty before invoking verify - for example, when a database column storing hashes permits NULL values and the ORM or DBI layer materializes NULL as an empty string, or when placeholder/seed records exist in the credential store. CVSS AV:N/AC:L/PR:N/UI:N indicates the vulnerable code path can be reached over the network without authentication if argon2_verify is called within an unauthenticated login handler; however, the attacker cannot directly supply the encoded hash argument - they can only influence whether the application fetches and passes an empty hash. Exploitation is limited by: (1) the attacker must induce the application to call argon2_verify with an empty hash (typically by targeting an account whose stored hash is empty, not by controlling the argument directly); (2) there is no attacker control over which heap bytes are read, making reliable information extraction non-trivial; (3) impact is process crash or incidental heap byte leakage, not arbitrary code execution; (4) non-default deployment - applications that validate hash non-emptiness before verification are unaffected.

The CVSS 5.3 Medium vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) describes a network-reachable, unauthenticated path to partial availability impact. However, multiple converging signals indicate this is lower real-world priority than the network-vector score alone suggests. EPSS sits at 0.03% (9th percentile), SSVC rates exploitation as 'none' and automatable as 'no', and no public proof-of-concept or KEV listing exists. SSVC's 'Automatable: no' likely reflects that reliable exploitation requires the application to present an empty string to argon2_verify - an edge case dependent on specific storage or input-validation patterns rather than a universally triggerable code path. One potential discrepancy worth noting: CVSS rates confidentiality impact C:N, but the CVE description explicitly mentions leakage of a '$' byte position from adjacent heap allocations. Whether this constitutes an exploitable information disclosure beyond process crash is not independently confirmed by vendor or NVD, so it should be treated as a theoretical risk inferred from the description rather than a confirmed impact.

An application with a user authentication endpoint retrieves a stored Argon2 hash from a database; a placeholder, newly-created, or improperly initialized account row contains an empty string rather than a valid hash. The application passes this empty string directly to argon2_verify for comparison, triggering the size_t underflow. memchr scans up to SIZE_MAX bytes of adjacent heap memory: in the best case for the attacker this crashes the Perl process (denial of service against the authentication service), and in an information-disclosure scenario the position of a '$' byte in adjacent heap allocations is returned to the parser, which may influence subsequent parsing behavior. No public proof-of-concept has been identified at time of analysis.