Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-10-05T17:17:11.143Z",
  "pubdate": "2026-10-05T17:17:11.143Z",
  "executiveSummary": "Plane, an open-source project management tool, contains an ORM field-name injection vulnerability in its public issues endpoint, affecting versions prior to 1.4.0.\nThe vulnerability arises from improper validation of group_by and sub_group_by query parameters, which are passed directly to database ORM operations.\nAn unauthenticated attacker can exploit this flaw to execute arbitrary ORM field resolutions, potentially triggering application-level denial of service (HTTP 500 errors) or acting as a blind traversal oracle to probe database schema structures.\nThe core risk involves the lack of an allowlist for user-supplied input used in sensitive database operations like F(), .values(), .order_by(), and Window partition_by.\nWhile direct exfiltration of record data is mitigated by result projection constraints and error handling, the ability to interact with relational paths via '__' separators poses a significant risk to data discovery and system stability.\nThis issue highlights an incomplete remediation of a known vulnerability class within the application's query handling layer.",
  "technicalDetails": "The vulnerability exists within the handling of group_by and sub_group_by query parameters in the unauthenticated public issues endpoint of the Plane application.\nThe root cause is the lack of a strict allowlist for input parameters, allowing user-provided strings to be passed directly into Django ORM methods including F(), .values(), .order_by(), and Window partition_by operations.\nWhen an attacker supplies arbitrary field paths, the ORM attempts to resolve these strings as database column identifiers or relational paths.\nBy utilizing '__' separators, an attacker can traverse through relational paths, effectively using the application as a blind traversal oracle to determine the existence of database fields or relationships.\nIf the provided field path is invalid or results in an unexpected ORM state, the application fails to handle the resulting FieldError or KeyError, leading to an unhandled exception and a subsequent HTTP 500 status code, facilitating a denial-of-service vector.\nThe attack flow begins with an anonymous HTTP GET request to the public issues endpoint, embedding malicious strings within the group_by or sub_group_by query parameters.\nThe backend receives these parameters and, lacking validation, incorporates them into the construction of complex database queries.\nWhile the issue_group_values() function returns an empty list for unknown fields and fixed required_fields lists prevent raw column projection, the underlying database engine still attempts to parse and resolve the malicious paths.\nThis vulnerability is an extension of previously identified injection classes where order_by sanitization was implemented, but the group-based grouping parameters were overlooked.\nThe impact is primarily centered on the ability to map the database schema or induce application crashes, rather than direct unauthorized data retrieval due to the output serialization constraints.\nThe vulnerability is remediated in version 1.4.0, which presumably introduces the necessary validation and allowlisting for these specific parameters to ensure only authorized fields are processed by the ORM."
}