Plane CVE-2026-104893

Requires an authenticated account on the target Plane instance with access to the API-tokens endpoints (PR:L); the attacker modifies the allowed_rate_limit field on a token via PATCH /api/users/api-tokens/{token_id}/, which prior to version 1.4.0 lacks server-side validation and any maximum cap. This is the default behavior of affected versions, so no non-default feature flag or special configuration is needed - only a valid user session. Exploitation is LIMITED by the authentication requirement (no unauthenticated path), the absence of confidentiality impact, and the fact that damage is scoped to API resource abuse/exhaustion rather than data compromise or code execution.

This is a moderate-severity (CVSS 5.4), low-priority issue in practice. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L indicates network-reachable, low-complexity exploitation but requires at least low-privilege authentication (PR:L) - an attacker must already hold a valid account on the Plane instance with access to API tokens. Impact is limited to Integrity-Low (modifying the allowed_rate_limit field) and Availability-Low (resource abuse/exhaustion), with no confidentiality impact (C:N), consistent with the CWE-770 uncontrolled-resource-consumption classification. No EPSS score, CISA KEV listing, or public POC was provided in the intelligence set, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical ceiling is self-inflicted or insider abuse: a legitimate authenticated user degrading the shared backend, rather than an unauthenticated mass-exploitation threat. Signals are internally consistent (authenticated DoS-style flaw) with no contradictions between the vector and the description; the main missing signals are EPSS/KEV/POC, whose absence lowers urgency but is not itself an error.

An authenticated low-privilege user of a self-hosted Plane instance calls GET /api/users/api-tokens/ to retrieve their token record, then issues PATCH /api/users/api-tokens/{token_id}/ setting allowed_rate_limit to an arbitrarily high value. With rate-limiting neutralized, the attacker drives high-volume automated API traffic through their token to abuse backend resources and potentially exhaust server capacity, degrading availability for other tenants. No public exploit code is identified, and exploitation requires a valid authenticated session (PR:L), limiting this to insiders or compromised accounts.