Punk::Plugin::TOTP CVE-2026-78619

Exploitation requires three concrete prerequisites, all named in the description: (1) the attacker already knows the victim's account password, since the recovery code is only accepted after primary TOTP verification fails at the challenge route; (2) the attacker possesses a valid recovery code issued to an account they control; and (3) the target application keys its user models on a NON-numeric identifier - a username, email address, or UUID - because the bypass depends on Perl integer coercion collapsing such identifiers to zero so two of them compare equal. What LIMITS exploitation: deployments using purely numeric primary keys are NOT vulnerable (the comparison works as intended), and the attacker must have both the victim's password and their own recovery-capable account, making this a targeted rather than opportunistic attack despite the AV:N/AC:L/PR:N CVSS vector.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H = 9.8) treats this as trivially exploitable and unauthenticated, but the description contradicts that: the attacker must already know the victim's password (first factor) AND hold a valid recovery code of their own (implying an attacker-controlled account), AND the target application must key user models on a non-numeric identifier. Those are meaningful preconditions, so the real-world attack complexity and privilege requirements are higher than PR:N/AC:L suggest - I assess this closer to PR:L/AC:H. Signals otherwise point to low urgency: no KEV listing (not actively exploited), no public POC identified, and EPSS of 0.44% (37th percentile) indicating low predicted exploitation. The impact when conditions are met is genuine account takeover of a targeted victim, but this is a targeted, precondition-heavy attack rather than mass-exploitable RCE. Net priority: patch promptly if you run this module with non-numeric user keys, but this is not an emergency drop-everything issue for most environments. Note the 'Information Disclosure' tag understates impact, which is really an authentication/integrity bypass.

An attacker who has phished or reused a victim's password reaches the TOTP challenge, fails standard TOTP verification, then submits a recovery code from their own registered account. Because both accounts are keyed on non-numeric identifiers that coerce to zero, the ownership check passes and the attacker completes the victim's second factor, achieving full account takeover. No public exploit is identified at time of analysis, but the logic is simple enough to reproduce from the advisory once the target's key scheme is known.