Summary
Plane's public-board asset endpoints can access file assets without fully scoping requests to the authorized project, workspace, or user membership. An attacker who can reach a suitable public-board operation may read, overwrite, or restore assets belonging to other projects or workspaces.
Plane's public-board asset endpoints can access file assets without fully scoping requests to the authorized project, workspace, or user membership. An attacker who can reach a suitable public-board operation may read, overwrite, or restore assets belonging to other projects or workspaces.
Affected context
The vulnerability occurs in Plane's Spaces public-board asset operations, where an entity asset endpoint and an asset restore endpoint resolve a deployment board from a public anchor and then access file assets using workspace-level scoping alone. Risk is present when public-board routes are enabled and asset identifiers or related operation parameters can be supplied without enforcing project boundaries and workspace membership.
The vulnerability occurs in Plane's Spaces public-board asset operations, where an entity asset endpoint and an asset restore endpoint resolve a deployment board from a public anchor and then access file assets using workspace-level scoping alone. Risk is present when public-board routes are enabled and asset identifiers or related operation parameters can be supplied without enforcing project boundaries and workspace membership.
Exploit preconditions
- Attack surface: Public-board asset endpoints under the
/api/public/route space - Required access: Ability to reach a relevant public-board operation; authenticated membership is not necessarily enforced by the affected handlers
- Trigger point: Asset retrieval, overwrite, or restoration through the entity asset or asset restore endpoint
- Why exploitation is possible: Asset lookups rely on board workspace scope without consistently constraining the project or verifying membership, allowing identifiers associated with other tenants to be resolved
- Attack surface: Public-board asset endpoints under the
/api/public/route space - Required access: Ability to reach a relevant public-board operation; authenticated membership is not necessarily enforced by the affected handlers
- Trigger point: Asset retrieval, overwrite, or restoration through the entity asset or asset restore endpoint
- Why exploitation is possible: Asset lookups rely on board workspace scope without consistently constraining the project or verifying membership, allowing identifiers associated with other tenants to be resolved
Why this happens
The underlying flaw is an incomplete authorization check in object-level asset access. The endpoints establish a workspace relationship through a public board but do not consistently apply project-level constraints or membership validation before reading or modifying a FileAsset record. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, commonly known as insecure direct object reference, because a supplied or indirectly selected object identifier can access a resource outside the requester's authorized tenant or project.
The underlying flaw is an incomplete authorization check in object-level asset access. The endpoints establish a workspace relationship through a public board but do not consistently apply project-level constraints or membership validation before reading or modifying a FileAsset record. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, commonly known as insecure direct object reference, because a supplied or indirectly selected object identifier can access a resource outside the requester's authorized tenant or project.
Potential impact
- Unauthorized users may read assets from other projects or workspaces
- Attackers could overwrite assets belonging to unrelated projects
- Attackers may restore assets that administrators intended to remain deleted
- Project content integrity and confidentiality could be reduced
- Cross-tenant attacks could support phishing, content tampering, or broader operational disruption
- Unauthorized users may read assets from other projects or workspaces
- Attackers could overwrite assets belonging to unrelated projects
- Attackers may restore assets that administrators intended to remain deleted
- Project content integrity and confidentiality could be reduced
- Cross-tenant attacks could support phishing, content tampering, or broader operational disruption
General mitigation guidance
Mitigation generally centers on enforcing authorization at every asset access boundary rather than relying on a related public board's workspace association.
Common defensive patterns include:
- Require explicit membership or equivalent authorization before asset access
- Apply both workspace and project scoping to every asset query and mutation
- Derive authorization context from trusted server-side relationships instead of client-supplied identifiers
- Use centralized object-level authorization checks for read, update, and restore operations
- Deny access by default when project, workspace, or membership relationships are ambiguous
- Limit public-board capabilities to the minimum asset operations required
- Log and monitor cross-project asset access attempts
Mitigation generally centers on enforcing authorization at every asset access boundary rather than relying on a related public board's workspace association.
Common defensive patterns include:
- Require explicit membership or equivalent authorization before asset access
- Apply both workspace and project scoping to every asset query and mutation
- Derive authorization context from trusted server-side relationships instead of client-supplied identifiers
- Use centralized object-level authorization checks for read, update, and restore operations
- Deny access by default when project, workspace, or membership relationships are ambiguous
- Limit public-board capabilities to the minimum asset operations required
- Log and monitor cross-project asset access attempts
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis and code review rules that flag object lookups lacking tenant, project, or ownership predicates
- Review of public and unauthenticated routes that read or mutate database-backed resources
- Tests that attempt to access assets across workspace and project boundaries
- Authorization policy checks covering read, overwrite, delete, and restore actions
- Runtime monitoring for unusual cross-tenant asset access or repeated identifier enumeration
- Automated security review tools that trace user-controlled identifiers into database queries and mutation paths
Organizations can identify similar issues through:
- Static analysis and code review rules that flag object lookups lacking tenant, project, or ownership predicates
- Review of public and unauthenticated routes that read or mutate database-backed resources
- Tests that attempt to access assets across workspace and project boundaries
- Authorization policy checks covering read, overwrite, delete, and restore actions
- Runtime monitoring for unusual cross-tenant asset access or repeated identifier enumeration
- Automated security review tools that trace user-controlled identifiers into database queries and mutation paths
