Description

Punk::Plugin::TOTP versions before 0.05 for Perl allow the second-factor attempt limit to be reset by replaying an earlier session cookie because the challenge route counts failures in the session. The POST handler on challenge_path keeps the failure count as tries inside the totp_pending record in the session, raising it on each rejected code and deleting the pending record once it reaches attempts, five by default. Punk::Session carries the session in a signed cookie unless the application declares a store, and keeps no server-side record, so an earlier value of the same session stays valid until the expiry stamped inside it. A client that saves the cookie before its failed attempts and presents it again gets the pending record back with its counter, and the limit never fires. The replayed record is accepted while its own expiry, pending_ttl seconds from the challenge and 300 by default, has not passed. Sessions declared with a store are not affected: the pending record and its counter then live server-side. The attempt limit does not bound guessing of the second factor, which is left to the per-address rate limit the plugin registers on the same path, 30 requests per 60 seconds.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-25T22:17:06.537Z",
  "pubdate": "2026-08-25T22:17:06.537Z",
  "executiveSummary": "The Punk::Plugin::TOTP Perl module, in versions prior to 0.05, is susceptible to a session-based authentication bypass vulnerability due to improper management of TOTP failure counters.\nThe vulnerability originates from the reliance on client-side, cookie-based session storage for tracking failed second-factor authentication attempts. By replaying a previously saved signed session cookie, an attacker can reset the failure counter, effectively bypassing the configured attempt limit.\nThis flaw allows an attacker to perform an unlimited number of TOTP guessing attempts within the validity window of the session cookie, undermining the security guarantees of the second-factor authentication mechanism.\nSystems using Punk::Plugin::TOTP are at risk if they do not explicitly configure a server-side session store. The lack of server-side state forces the authentication limit logic to rely on mutable client-side data, which can be manipulated via replay attacks.\nThe impact is a significant reduction in the effectiveness of the TOTP challenge, facilitating potential brute-force or dictionary attacks against user accounts despite the defined 'tries' threshold.",
  "technicalDetails": "The vulnerability exists within the logic handling the challenge_path POST handler in Punk::Plugin::TOTP versions before 0.05. The plugin tracks the number of failed TOTP attempts within a 'totp_pending' record located inside the user's session.\nWhen Punk::Session is utilized without an explicit server-side store, it serializes the session state into a signed cookie on the client. Because the session state is stored entirely on the client, the 'tries' counter associated with the 'totp_pending' record is also controlled by the client.\nAn attacker can exploit this by initiating a legitimate TOTP challenge and capturing the session cookie. Each time the attacker submits an incorrect TOTP code, the plugin increments the 'tries' counter within the session object. Once the attacker reaches the maximum number of attempts (defaulting to 5), the plugin should logically reject further attempts.\nHowever, because the session state is held in the client-side cookie, the attacker can revert the session to an earlier, valid state by presenting a previously captured cookie that reflects a lower (or zero) failure count. As long as the session cookie has not reached its internal expiry timestamp and the 'pending_ttl' window (default 300 seconds) has not elapsed, the server will accept the replayed cookie as a valid session state.\nThis behavior creates a loop where the failure counter is perpetually reset by the attacker, effectively neutralizing the attempt-limiting mechanism. While there is a secondary per-address rate limit (30 requests per 60 seconds) configured by the plugin, the session replay allows for a significantly higher volume of guessing attempts than the intended application-level security policy allows.\nThe vulnerability is limited to deployments where Punk::Session does not utilize a server-side store. When a store is configured, the 'totp_pending' record is managed server-side, preventing the client from reverting the failure counter to a previous state, thus mitigating the replay attack vector."
}