CVE-2026-78619 in Punk-Plugin-TOTP
Summary
by MITRE • 08/26/2026
Punk::Plugin::TOTP versions before 0.05 for Perl accept another account's recovery code at the two-factor challenge because totp_use_recovery compares user identifiers numerically.
The helper searches the recovery model for the submitted code's digest alone, across every user's rows, so the ownership test that follows is the only thing binding a code to the account it was issued to. That test compares the row's user_id with the challenged user's id through Perl's integer coercion, and an identifier with no leading digits coerces to zero, so any two of them compare equal. User models keyed on a username, an email address or a UUID hit that case, and a numeric key compares as intended.
The challenge route feeds a submitted value to the helper once TOTP verification fails, so an attacker who knows a victim's password and holds a recovery code of their own passes the victim's second factor.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
This vulnerability represents a critical authentication bypass within the Punk::Plugin::TOTP Perl module for versions prior to 0.05, specifically affecting systems that rely on time-based one-time passwords combined with account recovery codes as part of their two-factor authentication strategy. The core technical flaw stems from an improper comparison logic in the helper function responsible for validating recovery codes against user accounts. When a TOTP verification fails, the system falls back to checking if the submitted code matches any stored recovery digest. This search is performed across all users without immediate restriction by account ownership, relying entirely on a subsequent identity check to bind the valid recovery code to the specific user attempting authentication.
The mechanism of failure lies in how Perl handles type coercion during integer comparisons. The validation logic compares the user identifier associated with the found recovery code against the identifier of the currently challenged user using an equality operator that coerces both operands into integers for comparison. In many common application architectures, user identifiers are not strictly numeric but are instead strings such as usernames, email addresses, or universally unique identifiers (UUIDs). When Perl attempts to coerce a string with no leading digits into an integer, it results in the value zero. Consequently, any two users whose identifiers do not start with a number will both be coerced to zero, causing the equality check to return true regardless of whether the recovery code actually belongs to the challenged user. This effectively nullifies the ownership test that is supposed to prevent cross-account access via shared or leaked recovery codes.
The operational impact of this flaw allows an attacker who possesses valid credentials for a target victim and also holds their own account with a known recovery code to bypass two-factor authentication entirely. By submitting the victim's username or email along with their own recovery code, the attacker can successfully authenticate as the victim because both identifiers coerce to zero during the comparison step. This scenario is particularly dangerous in multi-tenant environments or applications where user IDs are derived from non-numeric strings, such as standard email addresses which rarely begin with digits. The vulnerability undermines the fundamental security guarantee of two-factor authentication by allowing a valid second factor from one account to be accepted for another, provided both accounts use string-based identifiers that fail numeric coercion checks.
From an industry standards perspective, this issue aligns closely with CWE-287: Improper Authentication and CWE-601: URL Redirection to Untrusted Site (in the context of identity binding failures), though it is most accurately categorized under CWE-345: Insufficient Verification of Data Authenticity. The attack vector corresponds to MITRE ATT&CK technique T1078, specifically Valid Accounts, as it involves using legitimate credentials combined with a bypassed second factor to gain unauthorized access. To mitigate this vulnerability, developers must upgrade the Punk::Plugin::TOTP module to version 0.05 or later where the comparison logic has been corrected to perform strict string-based equality checks rather than numeric coercion. Alternatively, if upgrading is not immediately feasible, application-level workarounds include ensuring that all user identifiers are strictly numeric before being passed to the authentication plugin, although this may require significant architectural changes depending on how identities are managed within the system. Ensuring that identity verification occurs prior to or concurrently with code validation rather than as a post-hoc check would also strengthen the security posture against such bypasses.