CVE-2026-104964

Executive Summary

CVE-2026-104964 is a broken tenant-isolation vulnerability in Plane, an open-source project management tool, affecting all versions prior to 1.4.0. The project update endpoint authorizes the caller against the workspace slug in the request URL but then loads the target project globally by UUID without binding it to that workspace, allowing an administrator of one workspace to modify a project belonging to another workspace when the victim project UUID is known. The impact is unauthorized cross-workspace modification of project metadata and configuration, violating the multi-tenant security boundary that Plane deployments rely upon.

Technical Analysis

The vulnerability class is CWE-639, Authorization Bypass Through User-Controlled Key (often described as an insecure direct object reference, IDOR, in a multi-tenant context). The root cause, as described by the vendor, is a mismatch between two authorization decisions performed within a single request handler:

1. Authorization check: The project update endpoint validates the calling principal against the workspace slug present in the request URL. This confirms the caller has administrative rights within the workspace path they are addressing.
2. Object resolution: The handler then loads the target project globally by its UUID, without constraining that lookup to the workspace that was just authorized. The UUID is not bound to the workspace slug used during the authorization step.

Because the object lookup and the authorization check operate on two different identifiers (URL workspace slug vs. message-supplied project UUID), there is no tenant-binding between them. An actor who is a legitimate administrator of Workspace A can supply a project UUID belonging to Workspace B; the authorization step succeeds against Workspace A, and the handler then selects and updates the Workspace B project.

Two properties make this exploitable in practice despite the required privilege level:

• Cross-tenant object reference: UUIDs are the only secret required to reach the target object. Project UUIDs are not access-controlled as secrets and can leak through shared links, export files, integration payloads, logs, or API responses from any workspace where the actor has visibility. If any project identifier from the victim workspace is observable, the barrier to exploitation drops significantly.
• Scope change (S:C in the CVSS vector): The security authority being evaluated (the authorized workspace) is different from the resource actually modified (a foreign workspace), so the impact crosses a security scope boundary — the defining characteristic of a tenant-isolation failure.

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:N yields 6.8. Network attack vector (AV:N) means the endpoint is reachable over the network. Low attack complexity (AC:L) means no special conditions or race windows are required. High privileges required (PR:H) reflects that the attacker must already hold administrative rights in some workspace. No user interaction (UI:N) is needed. Scope is changed (S:C) because the modified resource lies outside the actor's authorized tenant. Confidentiality impact is None (C:N) — the operation writes rather than reads. Integrity impact is High (I:H) — project metadata and configuration are fully modifiable. Availability impact is None (A:N).

Affected systems are Plane instances prior to 1.4.0, particularly self-hosted or SaaS deployments operating in a multi-tenant or multi-workspace configuration. Single-workspace deployments reduce the blast radius because there is no second tenant to cross into.

The version 1.4.0 release resolves the issue. No CVE record provides additional code-level detail (specific function names, route strings, or parameter names beyond the "project update endpoint" and "workspace slug"), so further implementation specifics cannot be stated with confidence and are not asserted here.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available as of this writing. The attack chain below is inferred from the vulnerability class and the vendor description; implementation-level specifics such as exact endpoint paths or parameter names are not provided by the available data and are therefore not fabricated.

1. Reconnaissance and target identification The attacker needs two things: (a) administrative access to at least one workspace on a target Plane instance (≥ 1.4.0 pre-fix), and (b) the UUID of a project belonging to a different workspace on the same instance. The UUID can be gathered through any of the following, consistent with the class of the flaw:

• Project UUIDs shared in exported files, documentation, or integration configurations.
• UUIDs appearing in API responses, activity logs, or links the attacker can legitimately view within their own workspace or through any channel that exposes foreign identifiers.
• Enumeration or guessing is generally infeasible (UUIDs are high-entropy), so in practice the attacker relies on an identifier that has leaked or been obtained through another weakness.

2. Triggering the flaw The attacker, authenticated as a workspace administrator, issues a project update request (the vendor-described "project update endpoint") that contains:

• The workspace slug in the request URL belonging to the workspace they administer — this satisfies the authorization check.
• A project UUID belonging to the victim workspace — this is used to load the target object globally.

Because the handler authorizes against the URL workspace but loads the object by UUID without workspace binding, the request is accepted and applied to the foreign project. This is the direct object reference / missing tenant-binding mechanism (CWE-639).

3. Payload / execution method At the vulnerability-class level, the "payload" is a legitimate-looking update request whose only malicious element is the foreign project UUID in the object selector. No memory-corruption exploit, injection string, or code payload is involved — this is an authorization-logic abuse, so the request body carries normal project-field updates (metadata, configuration) directed at an unauthorized target.

4. Post-exploitation impact Successful exploitation yields unauthorized integrity changes to another tenant's project metadata and configuration (I:H). The attacker can alter the target project's attributes; the specific fields are not enumerated in the available data. Confidentiality is not directly impacted by this endpoint (C:N), and availability is not impacted (A:N). The lasting impact is a breach of the multi-tenant trust boundary — one tenant silently mutating another tenant's data, which can corrupt project state, mislead the victim's users, and undermine the platform's tenant-isolation assurances. Repeating the technique against multiple known foreign UUIDs allows modification of many projects.

Impact Assessment

• Tenant isolation broken: The core security promise of a multi-workspace deployment — that administrators cannot affect data outside their workspace — is violated. This is the central business risk.
• Data integrity: CVSS rates integrity impact as High (I:H). Project metadata and configuration can be modified without authorization. Depending on how far the modified fields propagate, downstream automation, integrations, notifications, or access settings could be affected.
• Scope breach: The S:C metric captures that the compromised authorization boundary (attacker's workspace) is distinct from the impacted resource (victim workspace). This makes the incident a cross-tenant event, not a contained internal one.
• Preconditions lower real-world risk somewhat but not decisively: PR:H means the attacker must already be an administrator somewhere on the instance. However, in SaaS or contractor-heavy environments, admin rights in one workspace are common, and the only remaining secret is a UUID that may leak through ordinary workflows. AC:L and UI:N mean no special timing or victim action is required once the UUID is known.
• Confidentiality/availability: No direct confidentiality or availability impact from this endpoint (C:N, A:N). The measured risk is concentrated in integrity and scope.
• Blast radius: Any Plane deployment < 1.4.0 hosting more than one workspace is exposed. Single-workspace deployments are largely unaffected because there is no foreign tenant to target.
• No known active exploitation: CISA KEV listing is NO; EPSS is not yet scored; no PoC, exploit code, or Nuclei template is tracked. Residual risk is driven by the underlying flaw rather than by observed exploitation.

Detection Guidance

Sigma Rule

title: Plane Cross-Workspace Project Update Authorization Bypass (CVE-2026-104964)
id: 3f1c9b2e-7d4a-4e1a-9c6b-plane104964
status: experimental
description: Detects project update requests where the URL workspace slug does not match the workspace owning the target project UUID, indicative of CVE-2026-104964 tenant-isolation bypass in Plane (< 1.4.0).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-104964
author: SOC Detection Engineering
date: 2026/01/01
logsource:
  product: plane
  service: api
detection:
  selection_method:
    http.method: 'PATCH'
  selection_endpoint:
    cs-uri-stem|contains: '/projects/'
  selection_workspace_mismatch:
    workspace_slug|exists: true
    target_project_uuid|exists: true
    workspace_owner_mismatch: true
  condition: selection_method and selection_endpoint and selection_workspace_mismatch
falsepositives:
  - Legitimate project updates where the workspace slug and project UUID are correctly co-located (no mismatch flagged)
level: high

YARA Rule

rule CVE_2026_104964_Plane_CrossWorkspace_Update
{
    meta:
        description = "Detects HTTP request artifacts targeting the Plane project update endpoint with a workspace slug and a distinct project UUID (CVE-2026-104964)."
        cve = "CVE-2026-104964"
        cwe = "CWE-639"
        author = "SOC Detection Engineering"
        date = "2026-01-01"
    strings:
        $m1 = "PATCH" nocase
        $m2 = "/projects/" nocase
        $u1 = /\/(api\/)?workspaces\/[A-Za-z0-9_-]+\// nocase
        $u2 = /\/projects\/[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}/ nocase
    condition:
        $m1 and $m2 and $u1 and $u2
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-104964 Plane Cross-Workspace Project Update Authorization Bypass Attempt"; flow:established,to_server; http.method; content:"PATCH"; http.uri; content:"/projects/"; pcre:"/\/workspaces\/[^\/]+\/projects\/[0-9a-fA-F-]{36}/Ui"; reference:cve,CVE-2026-104964; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-104964; classtype:attempted-admin; sid:2026104964; rev:1;)

Elastic Detection

sequence by user.name with maxspan=30s
  [http where http.request.method == "PATCH" and wildcard(http.request.path, "*/projects/*")]
  [any where event.action == "project.updated" and not wildcard(project.workspace, "*request.workspace*")]

Splunk SPL Query

index=web OR index=plane sourcetype=access_combined OR sourcetype=plane:api
method=PATCH uri_path="*/projects/*"
| rex field=uri_path "/workspaces/(?<url_workspace>[^/]+)/projects/(?<project_uuid>[^/?]+)"
| where isnotnull(project_uuid)
| lookup plane_project_workspace project_uuid OUTPUT owning_workspace
| where isnotnull(owning_workspace) AND owning_workspace != url_workspace
| stats count values(uri_path) as paths by src_ip, user, url_workspace, owning_workspace
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="web,plane,cve-2026-104964,">
  <rule id="104964" level="12">
    <decoded_as>json</decoded_as>
    <field name="method">^PATCH$</field>
    <field name="uri_path">/projects/</field>
    <regex field="uri_path">/workspaces/[^/]+/projects/[0-9a-fA-F-]{36}</regex>
    <description>CVE-2026-104964: possible Plane cross-workspace project update (workspace/UUID tenant mismatch)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>access_control,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The only vendor-stated fix is the Plane 1.4.0 release; no second-source confirmation of a patch was available in the provided data.

1. Immediate mitigations

• Upgrade or isolate: Because no workaround is vendor-published, the primary risk reduction is deploying the fixed Plane 1.4.0 release as soon as it can be validated. Where upgrade is not immediately possible, restrict network exposure of the Plane API to trusted networks and authenticated users only.
• Reduce attacker footholds: Limit the number of principals holding admin rights in any single workspace, and separate tenants onto distinct instances if multi-workspace isolation cannot be guaranteed on a vulnerable version.
• Protect identifiers: Treat project UUIDs as sensitive. Minimize their exposure in exports, integrations, logs, shared links, and public documentation, since a leaked UUID is the practical precondition for exploitation.
• Monitor for misuse: Enable the detection rules above to flag PATCH requests to /projects/ where the URL workspace does not match the workspace owning the targeted project UUID.

2. Patch / upgrade steps

• Identify all Plane deployments and confirm version. Any instance running < 1.4.0 is affected.
• Upgrade to Plane 1.4.0 or later. No vendor workaround is documented for pre-1.4.0 versions.
• After upgrading, verify the project update endpoint enforces that the project UUID belongs to the workspace authorized in the request URL.
• Rotate or review any project UUIDs/links that may have been exposed to untrusted parties during the vulnerable window.

3. Long-term hardening

• Enforce tenant-scoped object resolution as a design invariant: every object fetch must be constrained by the authorized tenant, never by a globally unique identifier alone.
• Adopt authorization patterns that bind object queries to the caller's authorized scope at the data-access layer (row-level tenancy), rather than validating scope and retrieving the object as two independent steps.
• Add automated tests for cross-tenant access attempts (using foreign UUIDs) to the CI pipeline.
• Log and alert on cross-tenant access denials and workspace/UUID mismatches as first-class security events.
• Apply least privilege to workspace administration and periodically audit who holds admin rights per tenant.

References

• NVD — CVE-2026-104964: https://nvd.nist.gov/vuln/detail/CVE-2026-104964
• Plane project (open-source project management tool) — release 1.4.0 fixing the tenant-isolation issue.
• CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• CISA Known Exploited Vulnerabilities catalog — CVE-2026-104964 is not listed (no known in-the-wild exploitation as of this writing).

No threat actor campaigns or exploit-in-the-wild evidence were identified in the provided data. EPSS has not yet scored this CVE, and no public PoC, exploit code, or Nuclei template is available.