Description

Plane is an open-source project management tool. Prior to 1.4.0, Plane's magic-code email login uses a six-digit numeric OTP with approximately 20 bits of entropy. The verifier has no per-code failed-attempt counter, and an incorrect code does not increment a counter, invalidate the Redis entry, or lock the email address. The verifier extends django.views.View rather than DRF's APIView, so the configured AnonRateThrottle limit does not apply. The middleware stack also contains no Django-level rate limiter such as django-ratelimit, django-axes, or an IP-throttling middleware. This vulnerability is fixed in 1.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-10-05T19:17:18.030Z",
  "pubdate": "2026-10-05T19:17:18.030Z",
  "executiveSummary": "Plane, an open-source project management tool, is vulnerable to an authentication bypass via brute-force attack due to insufficient protection mechanisms on its magic-code email login functionality. The vulnerability exists in versions prior to 1.4.0.\nThe authentication mechanism utilizes a six-digit numeric OTP with limited entropy. The critical security flaw is the absence of rate limiting, account lockout policies, or code invalidation upon failed attempts. Because the verifier bypasses standard Django REST Framework (DRF) throttling and lacks additional middleware-level rate limiting, an attacker can perform high-speed, automated attempts to guess the OTP.\nThis represents a significant security risk, allowing unauthorized actors to gain access to user accounts without prior credentials. The lack of per-code or per-account failed-attempt counters ensures that the brute-force process is not interrupted by standard security controls. An attacker capable of initiating a targeted email-based login request can systematically traverse the keyspace to identify the correct OTP, resulting in full account takeover. The exploit requires no special privileges and can be executed remotely over the network.",
  "technicalDetails": "The vulnerability resides within the implementation of Plane's magic-code email authentication flow. The system generates a six-digit numeric OTP that provides approximately 20 bits of entropy. While the entropy level is inherently low for authentication secrets, the primary exploit vector is the lack of mitigation against automated guessing.\nThe root cause is twofold: insufficient rate-limiting configuration and flawed architectural design in the request handling stack. The OTP verifier class extends the base django.views.View rather than inheriting from the DRF APIView. Consequently, the configured AnonRateThrottle limit, which typically enforces request frequency constraints, is ignored during the verification phase. Furthermore, the application middleware configuration lacks supplementary protection from tools like django-ratelimit or django-axes, leaving the endpoint exposed to unrestricted repeated requests.\nThe exploitation process follows a predictable attack flow:\n1. An attacker initiates an authentication request for a target email address, triggering the generation of a six-digit OTP in the backend Redis store.\n2. The attacker uses automated scripts to send continuous POST requests to the OTP verification endpoint, cycling through the possible 1,000,000 combinations (000000-999999).\n3. Because the verifier does not implement failed-attempt counters, the backend does not invalidate the Redis entry, increment a failure counter, or trigger a temporary lock on the target email identifier after incorrect submissions.\n4. Due to the absence of IP-based or session-based rate limiting, the attacker can conduct these requests in rapid succession, significantly reducing the time required to guess the valid OTP.\n5. Upon successful prediction of the OTP, the application treats the authentication as valid, granting the attacker the session associated with the target email address.\nThe impact is a total compromise of user identity and account privileges. Because the attack occurs at the authentication layer, the adversary gains access to the target's project data and associated administrative functions without the need for traditional credentials or session hijacking. The vulnerability is explicitly present in all versions prior to 1.4.0, and the exploit is highly effective given the lack of defensive triggers in the Django request-response lifecycle."
}