CVE-2026-104955

Executive Summary

CVE-2026-104955 is a privilege escalation vulnerability in Plane, an open-source project management tool, affecting all versions prior to 1.4.0. A Project Member holding role 15 can send a crafted PATCH request to the project-member update endpoint to change another user's project role, exploiting insufficient role-validation logic that only blocks assigning a role higher than the requester's own. By assigning the equal Member role (bypassing the check), an attacker can promote a Project Guest with role 5 to Member without Project Admin approval, granting unauthorized project capabilities and bypassing governance controls.

Technical Analysis

Plane implements a role-based access control (RBAC) model at the project level, using numeric role identifiers. A Project Guest is assigned role 5, a Project Member is assigned role 15, and Project Admin represents a higher privilege tier. The vulnerability resides in the role-update logic implemented at the project-member update endpoint.

The attack surface is the HTTP API endpoint: PATCH /api/workspaces/{workspace_slug}/projects/{project_id}/members/{member_pk}/

The endpoint accepts a request to modify the role of the member identified by {member_pk} within the project identified by {project_id}, inside the workspace identified by {workspace_slug}.

The root-cause flaw is a flawed authorization predicate in the role-update logic. The logic only rejects a request when the new role being assigned is higher than the requester's own role. It does not reject requests where the new role is equal to the requester's role. Because a Project Member (role 15) may legitimately hold role 15, the check "new_role > requester_role" evaluates to false when new_role == 15, and the update is permitted.

This means a Project Member (role 15) can assign role 15 (the Member role) to another user — specifically, a Project Guest currently at role 5 — thereby promoting that guest to Member status. The change is not routed through any Project Admin approval workflow, so the promotion is unauthorized from a governance perspective: a non-admin actor has altered the privilege level of another account.

The consequence is a horizontal-to-vertical privilege change for the targeted guest account: the guest acquires all capabilities associated with the Member role, which are broader than the guest role's restricted, limited project access. The bypass additionally undermines project governance controls that assume only Project Admins can modify member roles to the Member tier.

No public proof-of-concept, exploit code, or Nuclei template is available. The technical mechanism is described at the role-validation-logic level; no specific source file paths, internal function names, or database schema details are provided in the available CVE data, and none are invented here.

This maps to CWE-269 (Improper Privilege Management) — specifically, insufficient validation of an authorization decision allowing a principal to grant privileges equal to its own, which the application's governance model intended to reserve for a higher-privileged principal (Project Admin).

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred strictly from the vulnerability class (improper privilege management via insufficient role-validation) and the endpoint and role values named in the NVD description.

1. Reconnaissance / target identification. The attacker is an authenticated user who already holds the Project Member role (role 15) in a target Plane workspace/project. They enumerate project members — including the {member_pk} identifiers of Project Guests (role 5) in the project — and identify the {workspace_slug} and {project_id} for a project in which both they and at least one guest participate. No exploit tooling is required; standard API access with the attacker's own session is sufficient.

2. Triggering the flaw class. The attacker issues an authenticated PATCH request to /api/workspaces/{workspace_slug}/projects/{project_id}/members/{member_pk}/, targeting a guest's {member_pk} and supplying a role value of 15 (Member). The server-side role-update logic compares the requested new role against the requester's own role using a "greater than" check. Since 15 is not greater than 15, the check does not block the update. The equal-role comparison is the misconfiguration that permits the privileged change without Project Admin involvement.

3. Payload / execution at the vulnerability-class level. The execution method is a single unauthorized state-changing API request that mutates the target member's role field. There is no memory corruption, injection, or code execution component — the flaw is purely an authorization-logic defect. The request succeeds because the server trusts the client-supplied role value beyond the scope the requester's privilege level should allow.

4. Post-exploitation impact. The formerly Guest account (role 5) is now a Member (role 15). That account — which may be an attacker-controlled second identity or a colluding account — gains the expanded set of project operations available to Members. A single Project Member has therefore escalated another identity's access and circumvented the governance control that reserves Member-tier assignment for Project Admins. This can be a stepping stone: the newly promoted account can act as a Member in operations the attacker's original account might be monitored for, and can expand the attacker's effective project footprint.

Impact Assessment

The CVSS 3.1 vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base score 5.4 (Medium).

• AV:N — the endpoint is reachable over the network; no local access is required.
• AC:L — no special conditions or race timing are needed; a valid authenticated request with an equal-role value triggers the flaw.
• PR:L — the attacker must possess at least a low-privileged authenticated account that holds Project Member (role 15) in the affected project.
• UI:N — no action by the victim (the guest) or any administrator is required; the role change happens server-side upon request.
• S:U — the impact is scoped to the application's own security authority.
• C:L / I:L — limited confidentiality and integrity impact: the promoted account can access and modify project data at the Member tier, but the vulnerability does not, by itself, expose the full workspace or grant administrative control.
• A:N — no denial-of-service condition is described.

Business impact. Organizations using Plane for project management inherit a breakdown of project-level governance: role transitions intended to require Project Admin authorization can be performed by ordinary Members. This weakens the integrity of access control records and can enable unauthorized visibility into, or modification of, project content that was deliberately restricted from Guest accounts. In environments where guest access is used to limit contractors, external collaborators, or lower-trust staff, this vulnerability defeats the intended segregation.

Blast radius. Any Plane deployment prior to 1.4.0 that (a) hosts users with mixed Guest/Member project roles and (b) is network-reachable by authenticated Members. The blast radius is limited per-project: the promotion grants Member-tier access within the specific target project, not workspace-wide administrative rights.

Detection Guidance

Sigma Rule

title: Plane Project Member Role Escalation via Equal-Role PATCH
id: 6f3b1c92-9a41-4c7e-b2d5-1f0a7c8e4d21
status: experimental
description: Detects a PATCH to the Plane project-member endpoint that sets the role
  field to the Member value (15), consistent with CVE-2026-104955 privilege escalation.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-104955
author: valtersit.com
date: 2026/01/01
logsource:
  category: webserver
detection:
  selection_endpoint:
    cs-method: 'PATCH'
  selection_path:
    cs-uri-stem|contains: '/projects/'
  selection_path_member:
    cs-uri-stem|contains: '/members/'
  selection_role:
    cs-uri-query|contains: 'role=15'
  condition: selection_endpoint and selection_path and selection_path_member and selection_role
falsepositives:
  - Legitimate Project Admins assigning the Member role to users
  - Automated provisioning tooling that sets role 15
level: medium

YARA Rule

rule CVE_2026_104955_Plane_Role_Escalation
{
    meta:
        description = "Detects references to the Plane project-member role escalation pattern in web logs or artifacts"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-104955"
        date = "2026-01-01"
        cve = "CVE-2026-104955"

    strings:
        $ep1 = "/api/workspaces/"
        $ep2 = "/projects/"
        $ep3 = "/members/"
        $m1  = "PATCH"
        $r1  = "role=15"
        $r2  = "\"role\":15"
        $r3  = "\"role\": 15"

    condition:
        $ep1 and $ep2 and $ep3 and $m1 and any of ($r*)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-104955 Plane Project Member Role Escalation Attempt (role=15)"; flow:established,to_server; http.method; content:"PATCH"; http.uri; content:"/api/workspaces/"; content:"/projects/"; content:"/members/"; pcre:"/role(\"|%22)?\s*[:=](\"|%22)?15/"; reference:cve,2026-104955; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-104955; classtype:attempted-admin; sid:2026104955; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5s
  [ network where http.request.method == "PATCH" and
      url.path : "/api/workspaces/*/projects/*/members/*" ]
  [ network where http.request.method == "PATCH" and
      url.path : "/api/workspaces/*/projects/*/members/*" and
      (url.query : "*role=15*") ]

Splunk SPL Query

index=web sourcetype=plane_access
("PATCH" AND "/api/workspaces/" AND "/projects/" AND "/members/")
| eval role_escalation = if(match(_raw, "role(%22)?[\"=:\s]+(%22)?15"), 1, 0)
| where role_escalation=1
| stats count min(_time) as first_seen max(_time) as last_seen
        values(uri_path) as paths
        by src_ip, user, http_status
| sort - count

Wazuh OSSEC Rule

<group name="web,plane,cve-2026-104955,">
  <rule id="104955" level="10">
    <decoded_as>json</decoded_as>
    <field name="http.method">PATCH</field>
    <field name="url.path" type="pcre2">/api/workspaces/[^/]+/projects/[^/]+/members/[^/]+</field>
    <field name="url.query" type="pcre2">role(%22)?=?(%22)?15</field>
    <description>CVE-2026-104955: Plane project member role escalation attempt (PATCH members endpoint with role=15).</description>
    <mitre>
      <id>T1548</id>
    </mitre>
    <group>privilege_escalation,attempted_admin,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Even though the upstream project states the issue is fixed in 1.4.0, no patch reference, commit, or advisory was available to the tracked sources at time of analysis; treat deployed instances as unpatched until independently verified.

1. Immediate mitigations

   • Restrict network access to the Plane API so that only trusted networks/identities can reach the project-member PATCH endpoint; place Plane behind an authenticated reverse proxy and apply IP allow-listing where feasible.
   • Reduce the population of Project Member (role 15) accounts to the minimum necessary, since any such account is the required starting privilege (PR:L) for exploitation.
   • Monitor access logs for PATCH requests to /api/workspaces/*/projects/*/members/* that set a role value equal to the requester's own role (particularly role 15), and alert on them.
   • Where the application cannot be upgraded immediately, monitor for anomalous role changes on accounts and identify/revert unauthorized promotions to Member (role 15) made without Project Admin record.

2. Patch / upgrade steps

   • Upgrade Plane to 1.4.0 or later, which the project states fixes the insufficient role-validation logic.
   • Because patch provenance could not be confirmed via tracked sources, verify the released artifact/commit against the official Plane repository and changelog before and after upgrading.
   • After upgrading, audit the current role assignments of all project members and revert any Guest-to-Member promotions that were not authorized by a Project Admin.

3. Long-term hardening

   • Enforce server-side authorization that requires the requester's role to be strictly higher than, and explicitly authorized to manage, the target role — never allow a principal to assign a role equal to its own unless that principal is a designated administrator.
   • Route all role-modification operations through Project Admin authorization rather than self-or-peer assignment.
   • Emit immutable audit-log events for every role change, capturing actor, target, old role, new role, and whether admin approval was present.
   • Apply least-privilege defaults to guest accounts and periodically review guest and member role inventories.

References

• NVD — CVE-2026-104955: https://nvd.nist.gov/vuln/detail/CVE-2026-104955
• CWE-269 (Improper Privilege Management): https://cwe.mitre.org/data/definitions/269.html
• MITRE ATT&CK T1548 (Abuse Elevation Control Mechanism): https://attack.mitre.org/techniques/T1548/
• Plane project repository and release/changelog for version 1.4.0 — verify via the official project source
• CISA Known Exploited Vulnerabilities Catalog: not listed (CISA KEV: NO) — no exploit-in-the-wild evidence available as of analysis

No threat actor campaigns or in-the-wild exploitation activity has been observed or reported for CVE-2026-104955 at the time of writing. No public proof-of-concept, exploit code, or Nuclei template was identified.