Summary
Plane's public project asset endpoint checks whether a requester is authenticated but does not verify membership in the target workspace or project. An authenticated user who knows a published project's public identifier may therefore inject files or soft-delete existing assets, causing cross-workspace storage abuse and data loss.
Plane's public project asset endpoint checks whether a requester is authenticated but does not verify membership in the target workspace or project. An authenticated user who knows a published project's public identifier may therefore inject files or soft-delete existing assets, causing cross-workspace storage abuse and data loss.
Affected context
The issue occurs in Plane deployments using the public project asset endpoint for published projects. Write operations require authentication, but authorization may not confirm that the requester belongs to the workspace or project associated with the supplied public DeployBoard anchor. As a result, the endpoint can expose asset-management actions across workspace boundaries.
The issue occurs in Plane deployments using the public project asset endpoint for published projects. Write operations require authentication, but authorization may not confirm that the requester belongs to the workspace or project associated with the supplied public DeployBoard anchor. As a result, the endpoint can expose asset-management actions across workspace boundaries.
Exploit preconditions
- Attack surface: The public project asset API endpoint used for asset creation and deletion
- Required access: An authenticated Plane account
- Target knowledge: A valid public DeployBoard anchor for a published project
- Trigger point: A write request that creates an asset or soft-deletes an existing asset by identifier
- Why exploitation is possible: Authentication is enforced without a corresponding workspace or project membership check
- Attack surface: The public project asset API endpoint used for asset creation and deletion
- Required access: An authenticated Plane account
- Target knowledge: A valid public DeployBoard anchor for a published project
- Trigger point: A write request that creates an asset or soft-deletes an existing asset by identifier
- Why exploitation is possible: Authentication is enforced without a corresponding workspace or project membership check
Why this happens
The underlying bug is an authorization-scoping failure. The endpoint establishes that the requester is authenticated, but it does not bind the requested asset operation to the requester's workspace or project membership. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, because a user-controlled project or asset identifier can be used to access records outside the user's authorized scope.
The underlying bug is an authorization-scoping failure. The endpoint establishes that the requester is authenticated, but it does not bind the requested asset operation to the requester's workspace or project membership. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, because a user-controlled project or asset identifier can be used to access records outside the user's authorized scope.
Potential impact
- An attacker may create unauthorized file records in another workspace's project.
- An attacker could consume storage through cross-workspace file injection.
- Existing project assets may be soft-deleted without the owner's authorization.
- Project data could become unavailable or inconsistent.
- Organizations may face data loss, operational disruption, and cleanup costs.
- An attacker may create unauthorized file records in another workspace's project.
- An attacker could consume storage through cross-workspace file injection.
- Existing project assets may be soft-deleted without the owner's authorization.
- Project data could become unavailable or inconsistent.
- Organizations may face data loss, operational disruption, and cleanup costs.
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization for every asset operation rather than relying on authentication or public identifiers alone.
Common defensive patterns include:
- Verify workspace and project membership before creating, modifying, or deleting an asset.
- Resolve public identifiers to authorized server-side objects and apply deny-by-default access checks.
- Enforce ownership and tenant boundaries consistently across all API methods.
- Use separate authorization policies for published-project access and asset-management operations.
- Apply storage quotas, rate limits, and file validation to reduce abuse impact.
- Run destructive operations through auditable, explicitly authorized service paths.
Mitigation generally focuses on enforcing object-level authorization for every asset operation rather than relying on authentication or public identifiers alone.
Common defensive patterns include:
- Verify workspace and project membership before creating, modifying, or deleting an asset.
- Resolve public identifiers to authorized server-side objects and apply deny-by-default access checks.
- Enforce ownership and tenant boundaries consistently across all API methods.
- Use separate authorization policies for published-project access and asset-management operations.
- Apply storage quotas, rate limits, and file validation to reduce abuse impact.
- Run destructive operations through auditable, explicitly authorized service paths.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for authorization decisions based only on authentication state.
- Review signals where user-supplied workspace, project, asset, or public identifiers are used directly in database operations.
- Tests that exercise cross-tenant and cross-project create, update, and delete attempts.
- API policy checks requiring object-level authorization before every state-changing operation.
- Audit-log monitoring for asset changes made by users outside the owning workspace or project.
- Automated security testing that validates tenant isolation and access-control invariants.
Organizations can look for this class of issue through:
- Static analysis and code review checks for authorization decisions based only on authentication state.
- Review signals where user-supplied workspace, project, asset, or public identifiers are used directly in database operations.
- Tests that exercise cross-tenant and cross-project create, update, and delete attempts.
- API policy checks requiring object-level authorization before every state-changing operation.
- Audit-log monitoring for asset changes made by users outside the owning workspace or project.
- Automated security testing that validates tenant isolation and access-control invariants.
