CVE-2026-105835 in Planka
Summary
by MITRE • 10/06/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in PLANKA versions 2.2.0 through 2.2.1 represents a critical failure in the implementation of Time-based One-Time Password (TOTP) verification logic within its API endpoint POST /api/access-tokens/verify-totp. This flaw fundamentally undermines the security guarantees provided by two-factor authentication mechanisms, specifically regarding resistance to brute-force attacks. In standard secure implementations, TOTP systems are designed with strict rate-limiting and account lockout policies to prevent automated guessing of the six-digit verification codes. However, in this affected version, the server fails to enforce any limits on the number of incorrect attempts allowed within a single session or over time for a specific pending token. This architectural oversight allows an attacker who has already compromised a user's static password credential to bypass the second factor entirely through systematic enumeration rather than cryptographic breaking.
The operational impact of this vulnerability is severe, as it effectively reduces two-factor authentication to a mere notification mechanism that can be trivially circumvented. An adversary possessing valid username and password credentials initiates the login process, which generates a pending TOTP token with a standard ten-minute validity window. During this period, the attacker can submit an unlimited number of POST requests containing different six-digit codes against the verify-totp endpoint without triggering any defensive countermeasures such as temporary account locks or exponential backoff delays. Since there are only one million possible combinations for a six-digit numeric code, and no rate limiting is in place to slow down these attempts, automated scripts can exhaust the entire keyspace rapidly. The probability of success approaches certainty within minutes, allowing the attacker to obtain a valid full access token without ever knowing the actual TOTP secret shared with the legitimate user.
This vulnerability aligns closely with CWE-307 Improper Restriction of Excessive Authentication Attempts and CWE-640 Weak Password Recovery Mechanism for Forgotten Password if similar logic applies to recovery flows, though it is primarily an authentication bypass issue. From a threat modeling perspective using the MITRE ATT&CK framework, this flaw facilitates Credential Access via Brute Force techniques (T1110) specifically targeting Multi-Factor Authentication components. The lack of rate limiting violates fundamental security principles outlined in OWASP guidelines for API Security and Identity Management, which mandate that all authentication endpoints must implement robust throttling mechanisms to mitigate automated attacks.
To remediate this issue, developers must immediately implement strict rate-limiting policies on the verify-totp endpoint. This should include a maximum number of allowed attempts per user account or IP address within a defined time window, after which further requests are rejected with an appropriate HTTP status code such as 429 Too Many Requests. Additionally, implementing progressive delays between failed attempts can significantly increase the computational cost for attackers without impacting legitimate users excessively. It is also recommended to introduce temporary account lockouts after a certain threshold of consecutive failures and to ensure that pending tokens expire quickly or are invalidated immediately upon any incorrect attempt if such behavior aligns with security policies. Upgrading to a patched version where these controls are enforced is the primary mitigation strategy for organizations currently running vulnerable instances of PLANKA.