PLANKA CVE-2026-105835

Requires the attacker to already possess the victim's valid password (the first authentication factor) and the target account to have TOTP two-factor authentication enabled, producing an active ten-minute pending session token. The specific weakness is that POST /api/access-tokens/verify-totp in Planka 2.2.0 through 2.2.1 performs no counting or limiting of incorrect TOTP submissions, so the same pending token can be guessed against for its full lifetime. LIMITING FACTORS: exploitation is impossible without the password; the attacker must exhaust a probabilistic guess of the 1,000,000-value six-digit space within the 10-minute window (AC:H/AT:P); and patched builds close the window entirely by destroying the session after a configurable number of failed attempts and adding per-IP and per-identifier sign-in rate limiting.

The input CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N) scores 9.1 (Critical), driven by network reach and high confidentiality/integrity impact, but the real-world risk is materially lower than that headline because exploitation is gated on a strong precondition: the attacker must already know the victim's password to obtain the ten-minute pending token. In practice this is a second-factor bypass, not an unauthenticated takeover - the weakness (CWE-307, no limit on incorrect TOTP submissions) nullifies 2FA for accounts whose first factor is already compromised. The AC:H / AT:P metrics correctly signal that success is not guaranteed: the attacker must brute-force the ~1,000,000-value six-digit space within the 10-minute token lifetime. No EPSS score was provided, the CVE is NOT in CISA KEV, and no public exploit code was identified, so there is no evidence of active or widespread exploitation. CONFLICT TO NOTE: the input vector uses PR:N, yet the description explicitly requires a known valid password - a form of authentication - so PR:N understates the barrier and inflates the score; this should be read as PR:L (see assessed vector). Net: a genuine and patch-worthy 2FA-bypass priority for internet-facing Planka instances, but closer to high-severity-for-already-breached-passwords than a drive-by critical.

An attacker who has obtained a Planka user's password (via phishing, reuse, or a prior leak) authenticates to receive a ten-minute pending token, then scripts repeated POST requests to /api/access-tokens/verify-totp cycling through six-digit codes until one validates, yielding a full access token and complete account takeover despite 2FA being enabled. Because the endpoint imposed no attempt limit in 2.2.0-2.2.1, the same pending token can be guessed against for its entire lifetime. No public proof-of-concept exploit was identified at time of analysis.