{“lastseen”:”2026-06-26T17:26:12″,”description”:”Plane’s asset subsystem trusted workspace slugs and asset UUIDs without enforcing the right membership checks, which let one authenticated user read, copy, delete, and overwrite assets in other workspaces. All versions prior to 1.3.1 are affected…”,”published”:”2026-06-26T00:00:00″,”modified”:”2026-06-26T00:00:00″,”type”:”packetstorm”,”title”:”\ud83d\udcc4 Plane Improper Authorization”,”source”:””,”references”:””,”id”:”PACKETSTORM:224372″,”bulletinFamily”:”exploit”,”cwe”:null,”cvelist”:[“CVE-2026-46558″],”sourceData”:”# CVE-2026-46558\\n Plane\u2019s V2 asset subsystem trusted workspace slugs and asset UUIDs without enforcing the right membership checks, which let one authenticated user read, copy, delete, and overwrite assets in other workspaces.\\n \\n ## Intro\\n \\n I found this issue while reviewing **Plane**, the open-source project management platform, with a very specific question in mind:\\n \\n **Do the V2 asset endpoints actually enforce workspace boundaries, or do they trust attacker-supplied workspace slugs and asset IDs too far?**\\n \\n In this case, the answer was no.\\n \\n Plane\u2019s V2 asset subsystem exposed two related authorization flaws that broke workspace isolation for any authenticated user:\\n – the workspace-level asset endpoint did not enforce target-workspace membership before asset operations\\n – the duplicate-assets flow authorized only the destination workspace and trusted the source asset UUID without checking source-workspace access\\n \\n That made cross-workspace asset abuse possible.\\n \\n In my validated PoC, one normal user in workspace Bravo was able to:\\n – download Alpha\u2019s private uploaded asset\\n – duplicate that asset into Bravo\u2019s own workspace\\n – delete Alpha\u2019s original asset\\n – overwrite Alpha\u2019s workspace logo with attacker-controlled content\\n \\n That issue was later assigned **CVE-2026-46558**.\\n \\n **Plane:** [Plane on GitHub](https:\/\/github.com\/makeplane\/plane) \\n **CVE:** CVE-2026-46558\\n \\n This affected **Plane**, which on its official site is presented as being used by **50,000+ teams across the globe**. Plane also highlights strong open-source adoption, including **46,000+ GitHub stars** and **1,000,000+ Docker pulls**, and showcases organizations such as **Tencent**, **Accenture**, **Microsoft**, and **Amazon**.\\n \\n \\u003cimg width=\\”840\\” height=\\”560\\” alt=\\”photo0\\” src=\\”https:\/\/github.com\/user-attachments\/assets\/60f918ad-9f99-4287-9f33-e28f99d813d2\\” \/\\u003e\\n \\n —\\n \\n ## Attack Chain\\n \\n `authenticated attacker in workspace B \u2192 workspace-level V2 asset route trusts target workspace slug and asset UUID without proper membership checks \u2192 presigned read \/ patch \/ delete against workspace A assets + duplicate-assets source lookup trusts uploaded source UUID \u2192 cross-workspace disclosure, copying, deletion, and branding overwrite`\\n \\n —\\n \\n ## What Plane Does\\n \\n **Plane** is an open-source project management platform used to manage:\\n – tasks\\n – issues\\n – sprints\\n – docs\\n – triage\\n – workspace-level branding and assets\\n \\n That means its asset subsystem sits on a real trust boundary.\\n \\n The important question here was not whether Plane supports uploads.\\n \\n The real question was:\\n \\n **Does Plane enforce workspace isolation when one authenticated user references assets owned by another workspace?**\\n \\n In this case, it did not.\\n \\n —\\n \\n ## Why This Bug Was Worth Looking At\\n \\n A lot of multi-tenant application reviews focus first on obvious admin endpoints or direct settings updates.\\n \\n That misses a very common and very real bug class:\\n \\n **secondary object access through shared file or asset subsystems**\\n \\n Asset systems are easy to get wrong because they often combine:\\n – user-controlled identifiers\\n – storage-layer indirection\\n – metadata-driven object linking\\n – presigned URL generation\\n – multiple entity types behind a shared route\\n \\n That is exactly the kind of place where tenant boundaries silently weaken.\\n \\n This issue was not about storage corruption.\\n It was not about S3 itself.\\n It was not about upload MIME handling.\\n \\n It was an **authorization boundary failure**:\\n – attacker-controlled identifiers crossed the boundary\\n – the server resolved cross-workspace objects\\n – authorization was incomplete or missing\\n – privileged asset actions still succeeded\\n \\n That is enough to create a real vulnerability.\\n \\n —\\n \\n ## The Boundary I Focused On\\n \\n I did not approach Plane by blindly fuzzing random endpoints or guessing at UUIDs with no model.\\n \\n The stronger approach was to identify the most promising isolation boundary first.\\n \\n For Plane, that was the **V2 asset subsystem**.\\n \\n Why?\\n \\n Because a shared asset system becomes dangerous when:\\n – multiple workspaces exist\\n – uploaded objects are referenced by UUID\\n – workspace slugs are attacker-controlled route inputs\\n – the application later turns successful lookups into presigned download or mutation paths\\n \\n That was the right boundary to inspect.\\n \\n And it was exactly where the bug lived.\\n \\n —\\n \\n ## Root Cause\\n \\n This was really two related authorization failures in the same subsystem.\\n \\n ### Root cause 1: workspace asset routes missing membership enforcement\\n \\n The workspace-level asset routes were exposed through:\\n \\n – `apps\/api\/plane\/app\/urls\/asset.py:50-56`\\n \\n The vulnerable handlers were in:\\n \\n – `apps\/api\/plane\/app\/views\/asset\/v2.py:314`\\n – `apps\/api\/plane\/app\/views\/asset\/v2.py:379`\\n – `apps\/api\/plane\/app\/views\/asset\/v2.py:400`\\n – `apps\/api\/plane\/app\/views\/asset\/v2.py:409`\\n \\n The problem was simple.\\n \\n `WorkspaceFileAssetEndpoint` accepted a workspace slug and asset UUID, then directly resolved objects like:\\n \\n “`python\\n workspace = Workspace.objects.get(slug=slug)\\n “`\\n \\n and:\\n \\n “`python\\n asset = FileAsset.objects.get(id=asset_id, workspace__slug=slug)\\n “`\\n \\n without first enforcing that the caller was actually an authorized member of that target workspace.\\n \\n That meant the endpoint could still:\\n – create assets\\n – finalize assets\\n – delete assets\\n – return presigned download URLs\\n \\n for another workspace\u2019s objects.\\n \\n ### Root cause 2: duplicate-assets trusted the source asset UUID\\n \\n The duplicate-assets route was mapped through:\\n \\n – `apps\/api\/plane\/app\/urls\/asset.py:100-101`\\n \\n The vulnerable logic was in:\\n \\n – `apps\/api\/plane\/app\/views\/asset\/v2.py:736-780`\\n \\n The destination workspace had an authorization decorator.\\n But the source asset lookup did not.\\n \\n The source object was loaded with:\\n \\n “`python\\n original_asset = FileAsset.objects.filter(id=asset_id, is_uploaded=True).first()\\n “`\\n \\n That meant the caller only needed:\\n – valid access to the destination workspace\\n – a source asset UUID that was uploaded\\n \\n There was no check that the caller belonged to the source workspace that actually owned that asset.\\n \\n That is the whole second bug.\\n \\n —\\n \\n ## Why This Is a Security Issue, Not Just Bad Access Logic\\n \\n The important distinction is cross-workspace impact.\\n \\n A lot of authorization bugs get minimized as:\\n \\u003e \u201cit still requires login\u201d\\n \\n That misses the point.\\n \\n The real question is not:\\n \\n \\u003e \u201cIs the caller authenticated?\u201d\\n \\n The real question is:\\n \\n \\u003e \u201cIs the caller authorized for the specific workspace and specific asset being acted on?\u201d\\n \\n In Plane, that answer was no.\\n \\n That turns what might look like ordinary object handling into a real multi-tenant security issue.\\n \\n There is a clear difference between:\\n – authenticated access inside your own workspace\\n – and authenticated access that crosses another tenant\u2019s boundary\\n \\n This issue was firmly the second case.\\n \\n —\\n \\n ## PoC\\n \\n I validated the issue locally against **Plane Community Edition 1.2.3** using two ordinary users in two unrelated workspaces:\\n \\n – Alpha in workspace `alpha-20260323072017`\\n – Bravo in workspace `bravo-20260323072017`\\n \\n I used Alpha to create a legitimate private uploaded asset in a project issue.\\n \\n The validated private asset ID in my run was:\\n \\n “`text\\n 6ed6ed62-d1b2-4399-8220-336c01b7d72c\\n “`\\n \\n ### Case 1: unauthorized read from another workspace\\n \\n As Bravo, I requested:\\n \\n “`http\\n GET \/api\/assets\/v2\/workspaces\/alpha-20260323072017\/6ed6ed62-d1b2-4399-8220-336c01b7d72c\/\\n “`\\n \\n Plane returned:\\n \\n “`http\\n HTTP\/1.1 302 Found\\n “`\\n \\n with a presigned download URL for Alpha\u2019s asset.\\n \\n The downloaded file hash matched Alpha\u2019s original private asset exactly:\\n \\n “`text\\n original: 0d4d070f550ba59ba6b30bee62343cf68ea221af7034f131f72f6409cf5a598e\\n unauthorized read: 0d4d070f550ba59ba6b30bee62343cf68ea221af7034f131f72f6409cf5a598e\\n “`\\n \\n That proved the read path crossed workspace boundaries successfully.\\n \\n —\\n \\n ### Case 2: cross-workspace duplication through source UUID trust\\n \\n As Bravo, I then requested:\\n \\n “`http\\n POST \/api\/assets\/v2\/workspaces\/bravo-20260323072017\/duplicate-assets\/6ed6ed62-d1b2-4399-8220-336c01b7d72c\/\\n “`\\n \\n Plane returned:\\n \\n “`http\\n HTTP\/1.1 200 OK\\n “`\\n \\n and created a duplicated attacker-side asset:\\n \\n “`text\\n 72d51497-ccc1-4546-ba14-28fae5d37dbb\\n “`\\n \\n The duplicated file\u2019s SHA-256 matched Alpha\u2019s original asset exactly:\\n \\n “`text\\n 0d4d070f550ba59ba6b30bee62343cf68ea221af7034f131f72f6409cf5a598e\\n “`\\n \\n That proved the source asset UUID alone was enough to copy cross-workspace content into an attacker-controlled workspace.\\n \\n —\\n \\n ### Case 3: unauthorized delete of victim asset\\n \\n As Bravo, I then sent:\\n \\n “`http\\n DELETE \/api\/assets\/v2\/workspaces\/alpha-20260323072017\/6ed6ed62-d1b2-4399-8220-336c01b7d72c\/\\n “`\\n \\n Plane returned:\\n \\n “`http\\n HTTP\/1.1 204 No Content\\n “`\\n \\n When Alpha later fetched that asset, the server returned:\\n \\n “`http\\n HTTP\/1.1 404 Not Found\\n “`\\n \\n That proved cross-workspace integrity impact, not just disclosure.\\n \\n —\\n \\n ### Case 4: unauthorized workspace-logo overwrite\\n \\n As Bravo, I created a `WORKSPACE_LOGO` asset against Alpha\u2019s workspace through the vulnerable workspace-level asset route, uploaded attacker-controlled content, and finalized it.\\n \\n After that, Alpha\u2019s workspace metadata pointed to attacker-controlled logo asset:\\n \\n “`text\\n c1032f06-3cf5-4f7e-b139-e6976d8c567d\\n “`\\n \\n The downloaded final logo hash matched the attacker payload exactly:\\n \\n “`text\\n expected: b9d1ef1de88d61bf55dd18055839bacacb832a752e17a7312547f641113d0e7b\\n observed: b9d1ef1de88d61bf55dd18055839bacacb832a752e17a7312547f641113d0e7b\\n “`\\n \\n That proved a visible cross-workspace overwrite path, not just a hidden backend access issue.\\n \\n —\\n \\n ## Why the Full Chain Matters\\n \\n Any one of the above results would already have been enough to justify a real bug report.\\n \\n But validating the full chain mattered for two reasons.\\n \\n ### First\\n \\n It showed the issue was not limited to read-only exposure.\\n \\n The same weak boundary enabled:\\n – disclosure\\n – copying\\n – deletion\\n – overwrite\\n \\n That makes the impact much stronger than a narrow \u201ccan fetch one file\u201d IDOR.\\n \\n ### Second\\n \\n It showed the two code paths were related but independently important.\\n \\n One flaw exposed workspace-level asset operations directly.\\n The second flaw turned uploaded asset UUIDs into a reusable exfiltration primitive through duplication.\\n \\n That made the overall security story much harder to dismiss.\\n \\n —\\n \\n ## Scope Validation\\n \\n The most visible overwrite impact I validated was:\\n \\n – `WORKSPACE_LOGO`\\n \\n That was deliberate because it is easy to verify and demonstrates obvious cross-tenant integrity failure.\\n \\n But the endpoint was not limited to workspace logos.\\n \\n The vulnerable workspace-level asset flow also accepted multiple entity contexts, including:\\n – project covers\\n – user images\\n – issue content\\n – page content\\n – comment content\\n \\n That mattered because it showed the bug was **structural**, not tied to a single branding field.\\n \\n I validated the workspace-logo path directly.\\n The broader code path strongly suggested additional asset-backed contexts were exposed to the same authorization mistake.\\n \\n —\\n \\n ## Severity and Classification\\n \\n This issue was reasonably classified as **High**.\\n \\n The advisory classification was:\\n \\n – **CWE-862**: Missing Authorization\\n – **CWE-639**: Authorization Bypass Through User-Controlled Key\\n – **CVSS:** \\n “`text\\n CVSS:3.1\/AV:N\/AC:L\/PR:L\/UI:N\/S:U\/C:H\/I:H\/A:L\\n “`\\n \\n That classification makes sense.\\n \\n The claim is not that an unauthenticated attacker can compromise Plane from nothing.\\n 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.\\n \\n That is a real and defensible multi-tenant authorization vulnerability.\\n \\n —\\n \\n ## Why This Was Still Worth Reporting\\n \\n Some people underrate authenticated cross-tenant bugs because they hear:\\n \\n \\u003e \u201cthe attacker already needed an account\u201d\\n \\n That is not a serious defense.\\n \\n In multi-workspace software, normal authenticated users are supposed to be **contained** inside their own authorization scope.\\n \\n If a low-privileged user in workspace Bravo can read, copy, delete, or overwrite objects in workspace Alpha, then workspace isolation is broken.\\n \\n That is exactly the security property the application is supposed to protect.\\n \\n 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.\\n \\n —\\n \\n ## Fix Analysis\\n \\n The issue was fixed in **Plane v1.3.1**.\\n \\n The release notes for `v1.3.1` described the fix clearly:\\n \\n – add `@allow_permission` to all `WorkspaceFileAssetEndpoint` methods\\n – scope `DuplicateAssetEndpoint` source asset lookup to workspaces where the caller is an active member\\n \\n That is the correct remediation direction because it addresses both failed security properties:\\n \\n 1. **workspace-level asset actions now require real membership enforcement**\\n 2. **source assets in duplication flow are no longer trusted by UUID alone**\\n \\n This is exactly what this bug needed.\\n \\n A good fix here is not about hiding UUIDs better.\\n It is not about changing presigned URL generation.\\n \\n It is about restoring the correct rule:\\n \\n **workspace slug plus asset UUID must never be enough without authorization scoped to the current user**\\n \\n That is the part the patch restored.\\n \\n —\\n \\n ## Disclosure\\n \\n This issue was reported privately through GitHub Security Advisories.\\n \\n The report included:\\n – root cause analysis for both code paths\\n – a local end-to-end PoC\\n – raw HTTP evidence\\n – hash-based proof for unauthorized download, duplication, and overwrite\\n – remediation guidance\\n \\n The issue was later published as:\\n \\n – **GHSA-qw87-v5w3-6vxx**\\n – **CVE-2026-46558**\\n \\n The advisory was published on **May 15, 2026**.\\n The fix shipped in **Plane v1.3.1**.\\n \\n —\\n \\n ## What This Bug Actually Teaches\\n \\n The key lesson here is simple:\\n \\n \\u003e shared asset subsystems are authorization boundaries, not just storage helpers\\n \\n A lot of developers think in terms of:\\n – upload succeeds\\n – object exists\\n – UUID resolves\\n – presigned URL works\\n \\n Those things are implementation details.\\n \\n The real security question is:\\n \\n **who is allowed to resolve, mutate, copy, or relink that asset across tenant boundaries?**\\n \\n In Plane, that boundary was not enforced consistently.\\n \\n That is the real takeaway.\\n \\n This bug also reinforces something important about reviewing multi-tenant applications:\\n \\n – shared object layers deserve direct security review\\n – attacker-controlled identifiers are enough when authorization is incomplete\\n – a single subsystem can expose both confidentiality and integrity failures at once\\n \\n —\\n \\n ## Key Points\\n \\n – asset endpoints are real multi-tenant security boundaries\\n – authenticated access is not the same thing as authorized cross-workspace access\\n – workspace slugs and asset UUIDs should never be sufficient on their own\\n – presigned download generation becomes dangerous when upstream authorization is weak\\n – validating both read and write consequences makes an authorization report much stronger\\n – structural authorization bugs in shared asset systems often affect more than one entity type\\n \\n —\\n \\n ## Final Words\\n \\n This vulnerability was not about exotic storage behavior.\\n \\n It was about asking the right trust-boundary question.\\n \\n In Plane, one authenticated user could supply another workspace\u2019s slug and asset UUIDs, and the V2 asset subsystem trusted those identifiers farther than it should have.\\n \\n That is why this became **CVE-2026-46558**.\\n \\n Fixed in **Plane v1.3.1**.”,”sourceHref”:”https:\/\/packetstorm.news\/download\/224372″,”cvss”:{“score”:8.3,”severity”:”HIGH”,”vector”:”CVSS:3.1\/AV:N\/AC:L\/PR:L\/UI:N\/S:U\/C:H\/I:H\/A:L”,”version”:”3.1″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/packetstorm.news\/files\/id\/224372\/”,”category_name”:”Exploit”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-06-26T17:26:12″,”description”:”Plane’s asset subsystem trusted workspace slugs and asset UUIDs without enforcing the right membership checks, which let one authenticated user read, copy, delete, and overwrite…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[6,8,99,12,15,13,53,7,11,5],"class_list":["post-66259","post","type-post","status-publish","format-standard","hentry","category-category_exploit","tag-cve","tag-cvss","tag-cvss-83","tag-exploit","tag-high","tag-news","tag-packetstorm","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n