CVE-2026-104956 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, the unauthenticated public issues endpoint accepts group_by and sub_group_by query parameters and passes them without an allowlist to grouped paginators, where they are used as ORM field names by F(field), .values(field), .order_by(field), and Window partition_by operations. An anonymous attacker can supply arbitrary field paths that trigger an unhandled FieldError or KeyError and an HTTP 500 response, or force the ORM to resolve __-separated relational paths as a blind traversal oracle. This is the same field-name injection class addressed by earlier order_by sanitization, but that remediation left group_by and sub_group_by unvalidated. The issue does not directly disclose column values because issue_group_values() returns an empty list for unknown fields, the result projection uses a fixed required_fields list, and the subgrouped path raises KeyError before serialization. This issue is fixed in 1.4.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/05/2026
Plane version prior to 1.4.0 contains a critical input validation flaw within its unauthenticated public issues endpoint that allows for field name injection through query parameters. The vulnerability stems from the application accepting group_by and sub_group_by parameters without subjecting them to an allowlist or rigorous sanitization process before passing them directly into Django ORM operations such as F, values, order_by, and Window partition_by. This architectural oversight enables an anonymous attacker to supply arbitrary field paths that are interpreted by the database backend rather than being treated strictly as user input strings intended for grouping logic. The core technical failure lies in the lack of validation against a predefined set of permissible model fields, which violates fundamental security principles regarding untrusted data handling and represents a classic instance of CWE-20 Improper Input Validation where insufficient verification allows malicious payloads to alter application behavior or trigger system errors.
The operational impact of this vulnerability manifests primarily through denial-of-service conditions caused by unhandled exceptions within the web server stack. When an attacker supplies field names that do not correspond to valid database columns, the Django ORM raises a FieldError which is not caught and handled gracefully by the application logic, resulting in a generic HTTP 500 Internal Server Error response. Similarly, attempts to force the Object-Relational Mapper to resolve double underscore-separated relational paths trigger KeyErrors due to improper handling of nested relationships during serialization. While these errors do not directly result in data exfiltration because the issue_group_values function returns an empty list for unknown fields and the projection relies on a fixed required_fields list, the consistent generation of server-side exceptions can be leveraged by attackers to disrupt service availability or potentially infer database schema details through error-based blind traversal techniques. This behavior aligns with CWE-209 Generation of Error Message Containing Sensitive Information if such errors expose stack traces or internal state details in production environments, and it reflects ATT&CK technique T1595 Active Scanning as the attacker probes for valid field structures to map the underlying data model.
Although earlier security remediations addressed similar injection vectors by sanitizing order_by parameters, this specific oversight left group_by and sub_group_by endpoints unprotected against analogous attacks. The distinction is significant because grouping operations often involve different ORM methods that may not have been included in previous patches targeting sorting functionality. This highlights the importance of comprehensive input validation across all query manipulation points within an application's API surface. To mitigate this vulnerability, organizations must upgrade to Plane version 1.4.0 or later where the issue has been resolved by implementing strict allowlisting for these parameters. In environments where immediate patching is not feasible, defensive measures should include deploying a Web Application Firewall configured to detect and block anomalous query parameter patterns indicative of ORM injection attempts, as well as ensuring that application error handling routines suppress detailed stack traces from being returned in HTTP responses to prevent information leakage during exploitation attempts.