/

CVE-2026-105631

Severity:

HIGH RISK

(7.5)

Broken Access Control (CWE-639) in Plane Asset APIs

CVE-2026-105631

Deferred

Vulnerability type

Category:

Authorization Bypass

CWE:

CWE-639

Impact:

Unauthorized Disclosure of Private Project Assets

Severity:

HIGH RISK

(7.5)

CVSS version:

3.1

Catch this CVE while code is being written

Detect vulnerable code directly in pull requests, so CVEs are fixed before merge.

Summary

Plane contains an authorization flaw in asset retrieval endpoints that can expose files associated with private or unpublished projects. Depending on the endpoint, a workspace member or an unauthenticated caller who knows the relevant identifiers may download protected issue- or comment-description assets.

Plane contains an authorization flaw in asset retrieval endpoints that can expose files associated with private or unpublished projects. Depending on the endpoint, a workspace member or an unauthenticated caller who knows the relevant identifiers may download protected issue- or comment-description assets.

Affected context

The vulnerability occurs in Plane deployments using affected asset endpoints before authorization checks sufficiently bind an asset to its project or published entity. Workspace-level lookup, and a separate public-anchor lookup, may permit access to assets outside the caller's authorized project scope when valid identifiers are available.

The vulnerability occurs in Plane deployments using affected asset endpoints before authorization checks sufficiently bind an asset to its project or published entity. Workspace-level lookup, and a separate public-anchor lookup, may permit access to assets outside the caller's authorized project scope when valid identifiers are available.

Exploit preconditions

  • Attack surface: Workspace and entity asset download endpoints
  • Required access: Either workspace membership with a known asset UUID, or no authentication when a valid public anchor and asset UUID are known
  • Trigger point: Retrieval of a file asset through an endpoint that resolves it by workspace or anchor
  • Why exploitation is possible: The lookup does not consistently verify membership in the asset's project or confirm that the referenced entity is published and authorized for disclosure
  • Attack surface: Workspace and entity asset download endpoints
  • Required access: Either workspace membership with a known asset UUID, or no authentication when a valid public anchor and asset UUID are known
  • Trigger point: Retrieval of a file asset through an endpoint that resolves it by workspace or anchor
  • Why exploitation is possible: The lookup does not consistently verify membership in the asset's project or confirm that the referenced entity is published and authorized for disclosure

Why this happens

The underlying bug is an authorization scope mismatch. Asset records are resolved using a workspace or public anchor, but the subsequent access decision does not reliably enforce authorization against the asset's owning project or published entity.

This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where knowledge of an object identifier can be enough to access a resource without validating whether the requester is entitled to that specific object.

The underlying bug is an authorization scope mismatch. Asset records are resolved using a workspace or public anchor, but the subsequent access decision does not reliably enforce authorization against the asset's owning project or published entity.

This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where knowledge of an object identifier can be enough to access a resource without validating whether the requester is entitled to that specific object.

Potential impact

  • Private issue-description or comment-description assets may be disclosed
  • An attacker could retrieve sensitive project documents or embedded information
  • Unauthenticated access could expose assets from unpublished projects
  • The incident could lead to privacy violations, information leakage, or compliance concerns
  • Private issue-description or comment-description assets may be disclosed
  • An attacker could retrieve sensitive project documents or embedded information
  • Unauthenticated access could expose assets from unpublished projects
  • The incident could lead to privacy violations, information leakage, or compliance concerns

General mitigation guidance

Mitigation generally focuses on enforcing object-level authorization at every asset retrieval path.

Common defensive patterns include:

  • Authorizing the asset against its owning project and entity before returning content
  • Treating workspace membership as insufficient for project-scoped resources
  • Requiring publication and visibility checks for public-anchor endpoints
  • Avoiding authorization decisions based solely on user-controlled identifiers
  • Applying least privilege and consistent deny-by-default rules to download handlers
  • Centralizing asset-access policy so alternate endpoints cannot bypass the same checks

Mitigation generally focuses on enforcing object-level authorization at every asset retrieval path.

Common defensive patterns include:

  • Authorizing the asset against its owning project and entity before returning content
  • Treating workspace membership as insufficient for project-scoped resources
  • Requiring publication and visibility checks for public-anchor endpoints
  • Avoiding authorization decisions based solely on user-controlled identifiers
  • Applying least privilege and consistent deny-by-default rules to download handlers
  • Centralizing asset-access policy so alternate endpoints cannot bypass the same checks

How teams detect issues like this

Organizations can look for this class of issue through:

  • Static analysis and code review checks for object lookups followed by missing ownership or project authorization
  • Review of endpoint permissions, especially broad public access declarations
  • Tests that attempt cross-project asset access using valid identifiers
  • Monitoring download events for unusual access across private or unpublished projects
  • Policy checks requiring resource-level authorization before file content is returned
  • Automated security review tools that flag identifier-based lookups without corresponding authorization predicates

Organizations can look for this class of issue through:

  • Static analysis and code review checks for object lookups followed by missing ownership or project authorization
  • Review of endpoint permissions, especially broad public access declarations
  • Tests that attempt cross-project asset access using valid identifiers
  • Monitoring download events for unusual access across private or unpublished projects
  • Policy checks requiring resource-level authorization before file content is returned
  • Automated security review tools that flag identifier-based lookups without corresponding authorization predicates

Sources

SourceLink
github.comgithub.com/makeplane/plane/commit/4577dc3f7a6b5a198602b602a45c6b0abdc7204b
github.comgithub.com/makeplane/plane/commit/e63f0c3b3404d669ae05dd9050aab72292f87e5c
github.comgithub.com/makeplane/plane/pull/9288
github.comgithub.com/makeplane/plane/pull/9372
github.comgithub.com/makeplane/plane/releases/tag/v1.4.0
github.comgithub.com/makeplane/plane/security/advisories/GHSA-85h2-mhcc-xfmw

Frequently asked

questions

A workspace member may be able to access assets from other private projects if the asset UUID is known. The separate public-anchor path may allow unauthenticated access when both a valid anchor and asset UUID are available.

Yes. Exploitation depends on obtaining a valid asset UUID and, for the public-anchor path, a valid anchor. Identifier secrecy should not substitute for authorization.

Enforce object-level authorization before serving an asset, verifying the caller's relationship to the asset's project and associated entity on every retrieval path.

Use centralized authorization checks, test cross-tenant and cross-project access, review public endpoints carefully, and enforce deny-by-default policies for private resources.

A workspace member may be able to access assets from other private projects if the asset UUID is known. The separate public-anchor path may allow unauthenticated access when both a valid anchor and asset UUID are available.

Yes. Exploitation depends on obtaining a valid asset UUID and, for the public-anchor path, a valid anchor. Identifier secrecy should not substitute for authorization.

Enforce object-level authorization before serving an asset, verifying the caller's relationship to the asset's project and associated entity on every retrieval path.

Use centralized authorization checks, test cross-tenant and cross-project access, review public endpoints carefully, and enforce deny-by-default policies for private resources.

Find out what's already
exploitable in your codebase.