CVE-2026-46558: Plane’s Cross-Workspace Asset Authorization Bypass in V2 Asset Endpoints

Plane is an open-source project management platform used to manage:

• tasks
• issues
• sprints
• docs
• triage
• workspace-level branding and assets

That means its asset subsystem sits on a real trust boundary.

The important question here was not whether Plane supports uploads.

The real question was:

Does Plane enforce workspace isolation when one authenticated user references assets owned by another workspace?

In this case, it did not.

Why This Bug Was Worth Looking At

A lot of multi-tenant application reviews focus first on obvious admin endpoints or direct settings updates.

That misses a very common and very real bug class:

secondary object access through shared file or asset subsystems

Asset systems are easy to get wrong because they often combine:

• user-controlled identifiers
• storage-layer indirection
• metadata-driven object linking
• presigned URL generation
• multiple entity types behind a shared route

That is exactly the kind of place where tenant boundaries silently weaken.

This issue was not about storage corruption. It was not about S3 itself. It was not about upload MIME handling.

It was an authorization boundary failure:

• attacker-controlled identifiers crossed the boundary
• the server resolved cross-workspace objects
• authorization was incomplete or missing
• privileged asset actions still succeeded

That is enough to create a real vulnerability.

The Boundary I Focused On

I did not approach Plane by blindly fuzzing random endpoints or guessing at UUIDs with no model.

The stronger approach was to identify the most promising isolation boundary first.

For Plane, that was the V2 asset subsystem.

Why?

Because a shared asset system becomes dangerous when:

• multiple workspaces exist
• uploaded objects are referenced by UUID
• workspace slugs are attacker-controlled route inputs
• the application later turns successful lookups into presigned download or mutation paths

That was the right boundary to inspect.

And it was exactly where the bug lived.

Root Cause

This was really two related authorization failures in the same subsystem.

Root cause 1: workspace asset routes missing membership enforcement

The workspace-level asset routes were exposed through:

• apps/api/plane/app/urls/asset.py:50-56

The vulnerable handlers were in:

• apps/api/plane/app/views/asset/v2.py:314
• apps/api/plane/app/views/asset/v2.py:379
• apps/api/plane/app/views/asset/v2.py:400
• apps/api/plane/app/views/asset/v2.py:409

The problem was simple.

WorkspaceFileAssetEndpoint accepted a workspace slug and asset UUID, then directly resolved objects like:

and:

without first enforcing that the caller was actually an authorized member of that target workspace.

That meant the endpoint could still:

• create assets
• finalize assets
• delete assets
• return presigned download URLs

for another workspace’s objects.

Root cause 2: duplicate-assets trusted the source asset UUID

The duplicate-assets route was mapped through:

• apps/api/plane/app/urls/asset.py:100-101

The vulnerable logic was in:

• apps/api/plane/app/views/asset/v2.py:736-780

The destination workspace had an authorization decorator. But the source asset lookup did not.

The source object was loaded with:

That meant the caller only needed:

• valid access to the destination workspace
• a source asset UUID that was uploaded

There was no check that the caller belonged to the source workspace that actually owned that asset.

That is the whole second bug.

Why This Is a Security Issue, Not Just Bad Access Logic

The important distinction is cross-workspace impact.

A lot of authorization bugs get minimized as:

“it still requires login”

That misses the point.

The real question is not:

“Is the caller authenticated?”

The real question is:

“Is the caller authorized for the specific workspace and specific asset being acted on?”

In Plane, that answer was no.

That turns what might look like ordinary object handling into a real multi-tenant security issue.

There is a clear difference between:

• authenticated access inside your own workspace
• and authenticated access that crosses another tenant’s boundary

This issue was firmly the second case.

PoC

I validated the issue locally against Plane Community Edition 1.2.3 using two ordinary users in two unrelated workspaces:

• Alpha in workspace alpha-20260323072017
• Bravo in workspace bravo-20260323072017

I used Alpha to create a legitimate private uploaded asset in a project issue.

The validated private asset ID in my run was:

Case 1: unauthorized read from another workspace

As Bravo, I requested:

Plane returned:

with a presigned download URL for Alpha’s asset.

The downloaded file hash matched Alpha’s original private asset exactly:

That proved the read path crossed workspace boundaries successfully.

Case 2: cross-workspace duplication through source UUID trust

As Bravo, I then requested:

Plane returned:

and created a duplicated attacker-side asset:

The duplicated file’s SHA-256 matched Alpha’s original asset exactly:

That proved the source asset UUID alone was enough to copy cross-workspace content into an attacker-controlled workspace.

Case 3: unauthorized delete of victim asset

As Bravo, I then sent:

Plane returned:

When Alpha later fetched that asset, the server returned:

That proved cross-workspace integrity impact, not just disclosure.

Case 4: unauthorized workspace-logo overwrite

As Bravo, I created a WORKSPACE_LOGO asset against Alpha’s workspace through the vulnerable workspace-level asset route, uploaded attacker-controlled content, and finalized it.

After that, Alpha’s workspace metadata pointed to attacker-controlled logo asset:

The downloaded final logo hash matched the attacker payload exactly:

That proved a visible cross-workspace overwrite path, not just a hidden backend access issue.

Why the Full Chain Matters

Any one of the above results would already have been enough to justify a real bug report.

But validating the full chain mattered for two reasons.

First

It showed the issue was not limited to read-only exposure.

The same weak boundary enabled:

• disclosure
• copying
• deletion
• overwrite

That makes the impact much stronger than a narrow “can fetch one file” IDOR.

Second

It showed the two code paths were related but independently important.

One flaw exposed workspace-level asset operations directly. The second flaw turned uploaded asset UUIDs into a reusable exfiltration primitive through duplication.

That made the overall security story much harder to dismiss.

Scope Validation

The most visible overwrite impact I validated was:

• WORKSPACE_LOGO

That was deliberate because it is easy to verify and demonstrates obvious cross-tenant integrity failure.

But the endpoint was not limited to workspace logos.

The vulnerable workspace-level asset flow also accepted multiple entity contexts, including:

• project covers
• user images
• issue content
• page content
• comment content

That mattered because it showed the bug was structural, not tied to a single branding field.

I validated the workspace-logo path directly. The broader code path strongly suggested additional asset-backed contexts were exposed to the same authorization mistake.

Severity and Classification

This issue was reasonably classified as High.

The advisory classification was:

• CWE-862: Missing Authorization
• CWE-639: Authorization Bypass Through User-Controlled Key
• CVSS:

That classification makes sense.

The claim is not that an unauthenticated attacker can compromise Plane from nothing. The claim is that any normal authenticated user can cross tenant boundaries in the V2 asset subsystem and perform high-impact asset operations against other workspaces.

That is a real and defensible multi-tenant authorization vulnerability.

Why This Was Still Worth Reporting

Some people underrate authenticated cross-tenant bugs because they hear:

“the attacker already needed an account”

That is not a serious defense.

In multi-workspace software, normal authenticated users are supposed to be contained inside their own authorization scope.

If a low-privileged user in workspace Bravo can read, copy, delete, or overwrite objects in workspace Alpha, then workspace isolation is broken.

That is exactly the security property the application is supposed to protect.

Especially in a project-management platform that stores internal work content and branding assets, that is a meaningful issue with real confidentiality and integrity impact.

Fix Analysis

The issue was fixed in Plane v1.3.1.

The release notes for v1.3.1 described the fix clearly:

• add @allow_permission to all WorkspaceFileAssetEndpoint methods
• scope DuplicateAssetEndpoint source asset lookup to workspaces where the caller is an active member

That is the correct remediation direction because it addresses both failed security properties:

1. workspace-level asset actions now require real membership enforcement
2. source assets in duplication flow are no longer trusted by UUID alone

This is exactly what this bug needed.

A good fix here is not about hiding UUIDs better. It is not about changing presigned URL generation.

It is about restoring the correct rule:

workspace slug plus asset UUID must never be enough without authorization scoped to the current user

That is the part the patch restored.

Disclosure

This issue was reported privately through GitHub Security Advisories.

The report included:

• root cause analysis for both code paths
• a local end-to-end PoC
• raw HTTP evidence
• hash-based proof for unauthorized download, duplication, and overwrite
• remediation guidance

The issue was later published as:

• GHSA-qw87-v5w3-6vxx
• CVE-2026-46558

The advisory was published on May 15, 2026. The fix shipped in Plane v1.3.1.

What This Bug Actually Teaches

The key lesson here is simple:

shared asset subsystems are authorization boundaries, not just storage helpers

A lot of developers think in terms of:

• upload succeeds
• object exists
• UUID resolves
• presigned URL works

Those things are implementation details.

The real security question is:

who is allowed to resolve, mutate, copy, or relink that asset across tenant boundaries?

In Plane, that boundary was not enforced consistently.

That is the real takeaway.

This bug also reinforces something important about reviewing multi-tenant applications:

• shared object layers deserve direct security review
• attacker-controlled identifiers are enough when authorization is incomplete
• a single subsystem can expose both confidentiality and integrity failures at once

Key Points

• asset endpoints are real multi-tenant security boundaries
• authenticated access is not the same thing as authorized cross-workspace access
• workspace slugs and asset UUIDs should never be sufficient on their own
• presigned download generation becomes dangerous when upstream authorization is weak
• validating both read and write consequences makes an authorization report much stronger
• structural authorization bugs in shared asset systems often affect more than one entity type

Final Words

This vulnerability was not about exotic storage behavior.

It was about asking the right trust-boundary question.

In Plane, one authenticated user could supply another workspace’s slug and asset UUIDs, and the V2 asset subsystem trusted those identifiers farther than it should have.

That is why this became CVE-2026-46558.

Fixed in Plane v1.3.1.