Cpe:2.3:a:planka:planka:2.2.0:*:*:*:*:*:*:* - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/cpes/cpe2.3aplankaplanka2.2.0/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 06 Oct 2026 16:56:21 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgBrute-Force Vulnerability in Planka TOTP Authenticationhttps://feed.craftedsignal.io/briefs/2026-10-planka-totp-brute-force/Tue, 06 Oct 2026 16:56:21 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-10-planka-totp-brute-force/Planka versions 2.2.0 through 2.2.1 contain a vulnerability in the TOTP verification endpoint that lacks rate-limiting, allowing attackers with known user passwords to brute-force two-factor authentication tokens.Planka versions 2.2.0 through 2.2.1 are vulnerable to a brute-force attack targeting the two-factor authentication (2FA) mechanism. The vulnerability exists within the /api/access-tokens/verify-totp endpoint, which fails to implement rate-limiting or account lockout mechanisms for failed TOTP code submissions. If an attacker has obtained a user's password, they can leverage the ten-minute pending token issued by the application to systematically guess six-digit TOTP codes. Given the lack of throttling, an attacker can exhaustively attempt combinations until the correct token is identified, ultimately resulting in unauthorized access to the victim's account. This flaw represents a significant risk for organizations relying on the native 2FA implementation in Planka, as it effectively bypasses the second layer of security.

Attack Chain

  1. Attacker obtains a valid username and password through credential harvesting or other initial access methods.
  2. Attacker initiates the authentication process against the Planka instance using the compromised credentials.
  3. The server validates the password and returns a ten-minute valid pending token, prompting for the second-factor code.
  4. Attacker targets the /api/access-tokens/verify-totp endpoint with high-frequency HTTP POST requests.
  5. Attacker iterates through six-digit TOTP code combinations within the ten-minute window allowed by the pending token.
  6. The server fails to enforce rate limits or block the source IP after repeated failed attempts.
  7. Upon successfully guessing the correct code, the server returns a full session access token.
  8. Attacker uses the acquired access token to gain unauthorized entry to the application.

Impact

Successful exploitation of this vulnerability allows unauthorized actors to bypass 2FA, leading to full account takeover. The impact includes the potential for unauthorized access to project management data, sensitive information exposure, and further lateral movement within the compromised environment. This vulnerability affects all deployments of Planka versions 2.2.0 and 2.2.1.

Recommendation

Detection engineering teams should monitor web access logs for anomalous traffic patterns indicating credential stuffing or brute-forcing behavior against the specific verification endpoint.

  • Monitor webserver logs for high volumes of POST requests to /api/access-tokens/verify-totp originating from a single source IP.
  • Implement request rate-limiting on the Planka /api/access-tokens/verify-totp endpoint at the web application firewall (WAF) or reverse proxy level to mitigate brute-force attempts.
  • Audit Planka authentication logs for an unusually high number of failed TOTP verification attempts associated with a single user account.
]]>highadvisorycredential-accessvulnerabilityweb-application