Description

PLANKA 2.2.0 through 2.2.1 fails to limit incorrect TOTP codes submitted to POST /api/access-tokens/verify-totp, allowing attackers to brute force two-factor authentication codes. Attackers who know a user's password can reuse the ten-minute pending token to guess six-digit codes until one succeeds, obtaining a full access token.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-10-06T13:16:46.760Z",
  "pubdate": "2026-10-06T13:16:46.760Z",
  "executiveSummary": "Planka versions 2.2.0 through 2.2.1 are susceptible to a critical authentication bypass vulnerability due to a lack of rate limiting on the two-factor authentication (TOTP) verification endpoint.\nThis vulnerability allows an attacker who has compromised a user's primary password to perform a brute-force attack against the TOTP verification process.\nBy repeatedly submitting 6-digit TOTP codes against the POST /api/access-tokens/verify-totp endpoint using a ten-minute pending token, an attacker can eventually guess the correct code.\nSuccessful exploitation results in the issuance of a full access token, effectively bypassing the secondary authentication layer and granting unauthorized access to the user's account.\nThe risk is high, as it invalidates the security benefits of multi-factor authentication (MFA) for the affected versions of the product.",
  "technicalDetails": "The vulnerability resides in the application's handling of the TOTP verification process at the POST /api/access-tokens/verify-totp endpoint. The root cause is the absence of a server-side rate-limiting or account lockout mechanism for failed TOTP attempts.\nWhen a user provides valid primary credentials (username and password), the system generates a temporary, ten-minute pending token required for MFA verification. In a secure implementation, the server should track the number of failed attempts associated with this pending token and invalidate it or impose a delay after a specified number of incorrect entries.\nIn Planka 2.2.0 and 2.2.1, the lack of an incremental delay or threshold-based blocking allows an adversary to automate a brute-force attack against the six-digit TOTP code. A six-digit code provides 1,000,000 possible combinations. Given that a TOTP code typically remains valid for a 30 to 60-second window, and the pending token remains active for ten minutes, an attacker has a significantly large window of opportunity to iterate through potential codes.\nThe attack flow proceeds as follows: First, the attacker performs a successful login using stolen or guessed primary credentials, obtaining the initial ten-minute pending token. Second, the attacker utilizes the pending token to submit sequential or randomized TOTP codes to the /api/access-tokens/verify-totp endpoint. Because the endpoint does not terminate the session or block the IP address after multiple failed attempts, the attacker can submit a high volume of requests within the ten-minute window until the correct code is submitted. Upon matching the correct six-digit value, the server validates the MFA requirement and issues a fully privileged access token, granting the attacker complete access to the user's account context.\nThis vulnerability is classified as an authentication bypass via improper access control on the verification flow. It allows attackers to circumvent MFA entirely, rendering the security posture of the affected software insufficient for environments requiring strict access control."
}