Summary
Plane's magic-code email login can be subjected to repeated guesses because its six-digit OTP has limited entropy and failed attempts are not tracked or throttled.
An attacker who can initiate or target the login flow may be able to guess a valid code, potentially taking over the associated account.
Plane's magic-code email login can be subjected to repeated guesses because its six-digit OTP has limited entropy and failed attempts are not tracked or throttled.
An attacker who can initiate or target the login flow may be able to guess a valid code, potentially taking over the associated account.
Affected context
The vulnerability occurs in Plane deployments using magic-code email authentication where:
- Login codes are short, numeric, and have approximately 20 bits of entropy
- Failed verification attempts do not consume, invalidate, or lock the code
- The verification endpoint is not covered by the configured API throttle
- No separate application- or middleware-level rate limiter protects the endpoint
Risk depends on the login flow being reachable and an attacker being able to submit repeated code-verification requests for a target email address.
The vulnerability occurs in Plane deployments using magic-code email authentication where:
- Login codes are short, numeric, and have approximately 20 bits of entropy
- Failed verification attempts do not consume, invalidate, or lock the code
- The verification endpoint is not covered by the configured API throttle
- No separate application- or middleware-level rate limiter protects the endpoint
Risk depends on the login flow being reachable and an attacker being able to submit repeated code-verification requests for a target email address.
Exploit preconditions
- Attack surface: The magic-code email login verification endpoint
- Required access: Ability to initiate or submit login-code verification requests; possession of the target email account is not necessarily required to attempt guessing
- Trigger point: Repeated submission of incorrect six-digit OTP values
- Why exploitation is possible: The verifier does not enforce per-code attempt limits, invalidate the Redis entry after failures, lock the email address, or apply an effective request throttle
- Attack surface: The magic-code email login verification endpoint
- Required access: Ability to initiate or submit login-code verification requests; possession of the target email account is not necessarily required to attempt guessing
- Trigger point: Repeated submission of incorrect six-digit OTP values
- Why exploitation is possible: The verifier does not enforce per-code attempt limits, invalidate the Redis entry after failures, lock the email address, or apply an effective request throttle
Why this happens
The underlying issue is insufficient protection against repeated authentication attempts, mapping to CWE-307: Improper Restriction of Excessive Authentication Attempts.
The verifier accepts a low-entropy numeric code without coupling it to a bounded failure counter, expiration-on-failure behavior, account lockout policy, or effective request-rate control. Because the verification view is not covered by the configured API throttle and the middleware stack lacks an equivalent limiter, an attacker can make repeated guesses against the same authentication challenge.
The underlying issue is insufficient protection against repeated authentication attempts, mapping to CWE-307: Improper Restriction of Excessive Authentication Attempts.
The verifier accepts a low-entropy numeric code without coupling it to a bounded failure counter, expiration-on-failure behavior, account lockout policy, or effective request-rate control. Because the verification view is not covered by the configured API throttle and the middleware stack lacks an equivalent limiter, an attacker can make repeated guesses against the same authentication challenge.
Potential impact
- An attacker may authenticate as the user associated with a guessed code
- User accounts could be taken over
- Attackers could access or modify project data available to the account
- Session tokens or other authenticated resources could be exposed or misused
- Repeated guessing could increase authentication-service load
- An attacker may authenticate as the user associated with a guessed code
- User accounts could be taken over
- Attackers could access or modify project data available to the account
- Session tokens or other authenticated resources could be exposed or misused
- Repeated guessing could increase authentication-service load
General mitigation guidance
Mitigation generally focuses on making authentication challenges difficult to guess and strictly limiting verification attempts.
Common defensive patterns include:
- Applying per-code, per-account, per-email, and per-source request limits
- Tracking failed attempts and expiring or invalidating codes after a small bounded number of failures
- Binding codes to a narrowly scoped login transaction and enforcing short lifetimes
- Using secure, sufficiently unpredictable challenge values and avoiding unnecessary exposure of authentication state
- Ensuring throttling covers the actual framework view and every alternate authentication route
- Applying layered controls across the application, reverse proxy, and identity boundary
- Protecting accounts and recovery flows with least-privilege session policies and additional verification where appropriate
These controls reduce the value of online guessing even when an OTP is exposed to the network.
Mitigation generally focuses on making authentication challenges difficult to guess and strictly limiting verification attempts.
Common defensive patterns include:
- Applying per-code, per-account, per-email, and per-source request limits
- Tracking failed attempts and expiring or invalidating codes after a small bounded number of failures
- Binding codes to a narrowly scoped login transaction and enforcing short lifetimes
- Using secure, sufficiently unpredictable challenge values and avoiding unnecessary exposure of authentication state
- Ensuring throttling covers the actual framework view and every alternate authentication route
- Applying layered controls across the application, reverse proxy, and identity boundary
- Protecting accounts and recovery flows with least-privilege session policies and additional verification where appropriate
These controls reduce the value of online guessing even when an OTP is exposed to the network.
How teams detect issues like this
Detection can include:
- Static analysis and code review searches for authentication handlers without failure counters, lockouts, or request throttling
- Verification that rate-limit decorators and middleware actually cover the concrete view class and route
- Tests that submit repeated invalid codes and confirm bounded retries, invalidation, and appropriate responses
- Monitoring for bursts of failed OTP attempts by email address, account, source address, device, and challenge identifier
- Policy checks requiring rate limits and abuse controls for every passwordless or recovery authentication endpoint
- Automated security testing or code-review tools that flag short OTPs and unbounded authentication attempts
Detection can include:
- Static analysis and code review searches for authentication handlers without failure counters, lockouts, or request throttling
- Verification that rate-limit decorators and middleware actually cover the concrete view class and route
- Tests that submit repeated invalid codes and confirm bounded retries, invalidation, and appropriate responses
- Monitoring for bursts of failed OTP attempts by email address, account, source address, device, and challenge identifier
- Policy checks requiring rate limits and abuse controls for every passwordless or recovery authentication endpoint
- Automated security testing or code-review tools that flag short OTPs and unbounded authentication attempts
