CVE-2026-105633

Executive Summary

CVE-2026-105633 is an authorization flaw (CWE-639, Authorization Bypass Through User-Controlled Key) in Plane, an open-source project management tool, affecting all versions prior to 1.4.0. The V2 issue-attachment PATCH endpoint accepts an issue_id in the URL but omits it from the database query, so the server matches an attachment only by its pk UUID, workspace, and project_id. Any authenticated project member can therefore supply an issue_id they legitimately control in the URL while targeting another user's attachment by its pk UUID, and the request will succeed — when the target attachment is still pending confirmation, the handler reassigns created_by to the attacker, transferring ownership. The vulnerability requires only a low-privileged authenticated account (CVSS 3.1 base score 7.1, AV:N/AC:L/PR:L/UI:N), with high integrity impact but no direct confidentiality or availability impact.

Technical Analysis

Plane is a self-hosted and cloud project management platform built around workspaces, projects, and issues. Issues can carry file attachments, and Plane's import/upload workflow treats attachments as two-stage objects: an attachment record is first created in a pending state (metadata present, object not yet confirmed as uploaded), and it is later confirmed — at which point the attachment becomes a fully finalized, owned object. CVE-2026-105633 lives in the confirmation stage of this workflow.

The vulnerable surface is the "V2 issue-attachment PATCH endpoint." Per the NVD description, this endpoint receives the issue identifier via the URL path (issue_id), but the backend query that locates the attachment to modify does not include issue_id as a filter. Instead, the query matches on three fields only:

1. pk — the attachment's primary-key UUID,
2. workspace — the workspace the caller is operating within,
3. project_id — the project the attachment belongs to.

Because issue_id is validated implicitly (it appears in the URL and the caller must be a member of the referenced project/workspace) but is never used to constrain the row selected for update, the endpoint exhibits an object-reference/authorization confusion. The attacker presents an issue_id they legitimately own in the URL — a value that passes any coarse route-level or membership check — while the pk UUID in the request body targets a different user's attachment inside the same workspace and project. The database lookup succeeds because the query only constrains on pk, workspace, and project_id; there is no join back to issue_id and no check that created_by == request.user for the target row.

The consequence is a two-part exploit primitive:

• Unauthorized modification: the attacker can PATCH attachments they do not own, as long as the workspace and project_id match the attachment and the pk UUID is known or guessed.
• Ownership transfer (the escalation): when the target attachment is still in the pending state (not yet confirmed as uploaded), the PATCH handler sets created_by = request.user. This is a write to the ownership foreign key, not merely a metadata update. The attachment is thereby reassigned to the attacker, effectively granting them the privileges that ownership confers over that object.

The root cause is a broken object-level authorization pattern: a user-controlled identifier (pk) is taken from the request and used directly as the row selector, while the contextual identifier that should scope the operation (issue_id) is present only in the URL and never applied to the query. This is the textbook CWE-639 pattern — the application trusts a user-supplied key to select a resource without re-validating that the caller is entitled to that resource. The workspace and project_id filters provide only tenant-level scoping; they do not prevent cross-user access within the same workspace/project, which is exactly where legitimate project members coexist.

No public proof-of-concept, exploit code, or Nuclei template was available at the time of writing, and the description does not enumerate the exact HTTP method parameters, serializer fields, or ORM query builder used. The analysis above is therefore derived strictly from the stated query fields (pk, workspace, project_id), the pending/confirmed attachment state model, and the created_by ownership assignment described by NVD.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the NVD description. Only identifiers explicitly named in the description (issue_id, pk, workspace, project_id, created_by) are used.

1) Reconnaissance / target identification. The attacker must already hold a valid Plane account that is a member of the target workspace and project — the vulnerability is reachable only by an authenticated low-privileged user (PR:L). The attacker enumerates the workspace and project they belong to, collects any issue_id values they legitimately control, and seeks the pk UUIDs of attachments created by other users in the same project. The description does not state how pk values are exposed; depending on deployment, attachment UUIDs may be obtainable from activity feeds, API listing responses, shared links, or the pending-attachment metadata returned to collaborators. Because the flaw does not require knowledge of the victim's credentials, only the attachment's pk and the shared workspace/project_id, discovery of a UUID is the primary precondition.

2) Triggering the specific flaw class. The attacker issues a PATCH request to the V2 issue-attachment endpoint, placing an issue_id they own in the URL path and the victim's attachment pk UUID in the request target. The server routes the request, confirms the caller is a member of the referenced workspace/project, and then executes an update against the row matching pk + workspace + project_id — without correlating the row to the issue_id in the URL. The authorization check on the URL's issue_id passes trivially because it is genuinely the attacker's; the query then silently operates on a row belonging to someone else. The mismatch between "what the URL says" and "what the query selects" is the entire exploit.

3) Exploitation / execution method. The attacker sends the PATCH with the fields required to modify the attachment. When the targeted attachment is pending and not yet confirmed as uploaded, the handler additionally sets created_by = request.user. This single field write is the escalation: ownership of the attachment record shifts to the attacker. No elevated privileges, user interaction (UI:N), or special position beyond normal project membership is needed (AC:L).

4) Post-exploitation impact. With ownership transferred, the attacker holds whatever authority ownership grants over that attachment within Plane (e.g., future modification, confirmation, or lifecycle actions on the object, and persistence of the ownership claim). Even where the target attachment is already confirmed and ownership is not reassigned, the attacker can still modify another user's attachment because the update matches on pk/workspace/project_id alone — an integrity violation affecting the victim's data. The CVSS subscores reflect this precisely: I:H (high integrity impact, since arbitrary unauthorized modification and ownership reassignment are possible), A:L (low availability impact, from potential disruption to the attachment's state or workflow), and C:N (no direct confidentiality impact in the described mechanism).

Impact Assessment

CVE-2026-105633 is an authenticated, cross-user integrity attack against Plane attachment objects. The blast radius is scoped to a single workspace and project: the attacker can only reach attachments whose workspace and project_id they already belong to. This limits the tenant scope but does not limit the user scope — within a shared project, every other member's pending attachments are potential targets.

Business impact includes:

• Data integrity loss: unauthorized modification of attachments owned by other users, with no confidentiality exposure and no availability guarantee (C:N/I:H/A:L).
• Ownership hijacking: pending attachments can be permanently reassigned to the attacker via the created_by = request.user write, corrupting the audit trail of who uploaded what.
• Trust and compliance: in regulated or collaborative environments (engineering, legal, finance) where Plane is used as a system of record, silent reassignment of file ownership undermines provenance and chain-of-custody assumptions.
• Low barrier to entry: exploitation requires only a valid low-privileged account, network reachability, and knowledge of a target attachment UUID — no user interaction and no race or timing window.

The CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L yields a base score of 7.1 (High): remote, low complexity, low privileges, no user interaction, unchanged scope, with the impact concentrated in integrity. EPSS has not yet assigned a score, and the CVE is not listed in CISA KEV; there is no evidence of in-the-wild exploitation at the time of writing. Exploit code and Nuclei templates are unavailable, which somewhat reduces near-term mass-exploitation risk, but the triviality of the flaw means weaponization is straightforward once a pk discovery path is identified.

Detection Guidance

Detection should focus on the mismatch between the issue_id present in the request path and the attachment pk selected for update, and on anomalous created_by reassignments on pending attachments.

Sigma Rule

title: Plane Issue-Attachment PATCH Ownership Reassignment (CVE-2026-105633)
id: 7f3a9c2e-plane-attach-idor
status: experimental
description: Detects PATCH requests to the Plane V2 issue-attachment endpoint where the issue_id in the URL does not correspond to the attachment pk being modified, or where created_by is reassigned to the requesting user.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-105633
author: valtersit.com
date: 2026-01-01
tags:
  - attack.t1078
  - cve.2026-105633
logsource:
  category: webserver
  product: plane
detection:
  selection_method:
    cs-method: 'PATCH'
  selection_endpoint:
    cs-uri-stem|contains: '/issue-attachment'
  selection_status:
    sc-status: 200
  filter_same_user:
    # path issue_id must be cross-referenced against attachment ownership at query time
    cs-uri-query|contains: 'pk='
  condition: selection_method and selection_endpoint and selection_status
fields:
  - c-ip
  - cs-username
  - cs-uri-stem
  - cs-uri-query
level: medium

YARA Rule

rule CVE_2026_105633_Plane_Attachment_IDOR
{
    meta:
        description = "Detects Plane issue-attachment PATCH handling that omits issue_id from the ownership query (CVE-2026-105633)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-105633"
        date = "2026-01-01"
        severity = "high"

    strings:
        $ep  = "issue-attachment" ascii wide nocase
        $p1  = "issue_id" ascii wide
        $p2  = "created_by" ascii wide
        $p3  = "project_id" ascii wide
        $p4  = "workspace" ascii wide
        $p5  = "pk" ascii wide

    condition:
        $ep and (2 of ($p1,$p2,$p3,$p4,$p5))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-105633 Plane V2 issue-attachment PATCH possible IDOR/ownership reassignment"; flow:established,to_server; http.method; content:"PATCH"; http.uri; content:"issue-attachment"; http.uri; content:"issue_id"; http.request_body; content:"pk"; http.request_body; content:"created_by"; reference:cve,2026-105633; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-105633; classtype:attempted-user; sid:2026105633; rev:1;)

Elastic Detection

sequence by user.name, source.ip with maxspan=30s
  [ http where http.request.method == "PATCH"
      and http.request.uri : "*issue-attachment*"
      and http.request.uri : "*issue_id*" ]
  [ http where http.response.status_code == 200
      and http.request.body : "*created_by*"
      and http.request.body : "*pk*" ]

Splunk SPL Query

index=web_logs sourcetype=plane_access
| search http_method=PATCH uri_path="*issue-attachment*" status=200
| rex field=uri_path "\/issues\/(?<path_issue_id>[^\/]+)\/issue-attachment"
| search uri_query="*pk=*"
| stats count values(uri_path) as paths values(uri_query) as queries by src_ip user path_issue_id
| where count > 3
| table src_ip user path_issue_id count paths queries

Wazuh OSSEC Rule

<group name="plane,web,cve-2026-105633,">
  <rule id="2026105" level="10">
    <decoded_as>json</decoded_as>
    <field name="http_method">PATCH</field>
    <field name="uri">\.*issue-attachment</field>
    <description>CVE-2026-105633: Plane V2 issue-attachment PATCH to cross-user attachment pk (possible IDOR/ownership reassignment)</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor advisory, commit, or release artifact was available from any tracked source; the only referenced fix is the NVD statement that the issue is "fixed in 1.4.0." Treat the guidance below as interim until an authoritative patch is verified.

1) Immediate mitigations (no patch required):

• Restrict the V2 issue-attachment PATCH endpoint to attachment owners at the application gateway or reverse proxy if your deployment topology permits request-level filtering; otherwise, front-end the endpoint with a WAF rule that flags PATCH requests whose URL issue_id does not match the target attachment's owning issue (see Detection Guidance).
• Reduce exposure by limiting who can be a project member and by auditing membership of projects that hold sensitive attachments.
• Disable or gate the two-stage "pending attachment" workflow where possible, since the ownership-transfer behavior (created_by = request.user) is only exercised on pending, unconfirmed attachments. Confirming attachments promptly reduces the window in which ownership can be hijacked.
• Monitor for anomalous created_by value changes on attachment records as a compensating detective control.

2) Patch / upgrade steps:

• Upgrade Plane to 1.4.0 or later once the release is obtained from a trusted, verified source. Because patch confidence is 0/4, independently verify the fix: after upgrading, confirm that the attachment-update query correlates the selected row to the URL issue_id and to the caller's ownership before writing.
• Where upgrade is not immediately possible, deploy the detection rules above and treat any hit as a potential compromise requiring review of attachment ownership records.
• Re-validate all attachment created_by fields for anomalies following any suspected exposure, and restore correct ownership from backup or audit logs.

3) Long-term hardening:

• Enforce object-level authorization on every write path: never select a row solely by a user-supplied key. Always join the resource to the contextual identifier (issue_id) and to the caller's identity/ownership.
• Adopt a consistent "get-then-authorize" pattern in the codebase: fetch by pk, then explicitly verify the row belongs to the workspace, project, and the requesting user (or that the user holds the required role) before any mutation.
• Introduce automated authorization tests (e.g., cross-user IDOR regression suites) that assert a user cannot mutate another user's attachments by supplying mismatched issue_id/pk combinations.
• Centralize ownership-mutation logic so that created_by can never be set to request.user without a proven ownership claim, and log all ownership changes for audit.

References

• NVD — CVE-2026-105633: https://nvd.nist.gov/vuln/detail/CVE-2026-105633
• MITRE CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
• FIRST EPSS — not yet scored at time of writing: https://www.first.org/epss/
• CISA Known Exploited Vulnerabilities Catalog — CVE-2026-105633 not listed: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Plane (upstream project) — release/security information for version 1.4.0: verify via the project's official repository and release notes.

Threat actor / exploit-in-the-wild status: No public proof-of-concept, exploit code, or Nuclei template was available; the CVE is not in CISA KEV and EPSS has not yet scored it. There is no evidence of active exploitation or named threat-actor campaigns targeting this vulnerability at the time of writing.