Plane CVE-2026-105638

Exploitation requires that the target Plane instance (prior to 1.4.0) has magic-code email login enabled and that the attacker knows or can enumerate the victim's email address used for sign-in. The attacker must complete the OTP brute force within the magic code's Redis TTL window, since a new token is not issued per guess. No authentication and no user interaction are required (PR:N/UI:N). Limiting factors for defenders: deployments that rely solely on SSO or password auth without the magic-code flow are not exposed; the attack generates a very high volume of requests to the verify endpoint (a detectable signal) and must succeed before the current code expires.

All available signals point to a genuine high-priority authentication weakness rather than an inflated high-CVSS issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H) is internally consistent with the described flaw: a remote, unauthenticated attacker can brute-force a six-digit (~20-bit) magic-code OTP because the verifier enforces no per-code failed-attempt counter, never invalidates the Redis entry on a wrong guess, never locks the email, and bypasses even the configured DRF AnonRateThrottle (because the view extends django.views.View, not APIView, and no Django-level rate limiter is present). Successful brute force yields full account takeover, justifying C:H/I:H. The one tempering factor is that the guess space must be exhausted within the OTP's Redis TTL window, which demands a high request volume - but with zero throttling this is readily automatable, so AC:L is defensible. Key probabilistic signals are MISSING: no EPSS score was provided, so likelihood of exploitation cannot be quantified; KEV status is not indicated (treat as not listed); and no public exploit was provided. The source-code patch diff is public, which materially lowers the bar for an attacker to reconstruct the exploit even though no weaponized POC is identified. Net: a real, actionable priority for any Plane deployment that enables magic-code email login, even though active-exploitation and EPSS evidence are absent from the input.

An attacker requests a magic-code login for a known victim email address, then scripts the verify endpoint to submit guesses for the six-digit code. Because wrong guesses are neither counted, rate-limited, nor cause the Redis token to be invalidated, the attacker brute-forces the ~20-bit code space within the token's validity window and logs in as the victim. No public exploit is identified at time of analysis, but the fixing PR diff publicly reveals the exact root cause.