CVE-2026-85211 is a high severity authorization flaw in Label Studio through 1.23.0. Two storage resolve endpoints look up tasks and projects without an organization filter, so a user in one organization can reach another tenant's connected cloud storage. Check the project's releases for a fixed version.
What's affected
- Product: Label Studio,
io_storages/proxy_api.py. - Affected per VulnCheck: up to and including 1.23.0.
- Fixed version: not confirmed. The public issue (#9924) showed as closed when read, but it did not name a release. Check the Label Studio release notes and security advisory GHSA-8mp9-cpp7-x63q referenced there.
- Scope: the issue describes the Community edition, where the permission check is a stub.
Severity in the record: High, CVSS 7.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N). VulnCheck scores it 8.3 under CVSS v4. The record has 7.7 under v3.1 with a changed scope, because the data belongs to another tenant.
Weakness class: CWE-639 (Authorization Bypass Through User-Controlled Key).
How to check if you're exposed
- Run
pip show label-studioin the environment that serves the app, or read your container image tag. - If the version is 1.23.0 or earlier, check release notes for a newer release.
- Ask whether you run more than one organization on a single instance. A single organization deployment has no other tenant to leak to.
- Review which cloud buckets are attached as storage and what the connecting credentials can read. The issue says a user could reach any object in a connected bucket, not only files linked to a task.
What to do now
- Upgrade to a release that contains the fix once you confirm which one it is.
- If you host several organizations, consider separate instances for tenants with sensitive data until you have upgraded.
- Use bucket credentials limited to the one prefix each project needs.
- Turn on access logs for the storage buckets and look for reads that do not match known tasks.
- Review users who can create organizations.
Why it matters
The weak spot is a database lookup by primary key alone. The safe pattern is to filter every query by the caller's organization, and the other endpoints in the app do this. These two did not. The community edition's permission hook returns True for everyone, so nothing else stepped in. That is CWE-639.
The second problem makes it worse. The code checked that a requested file address matched the storage's scheme and bucket, not that the object was one the task referenced. So the reach is the whole bucket. Multi tenant software should deny by default, with an org filter that cannot be skipped. The record does not claim exploitation in the wild.
Try it yourself
This demo shows how a vulnerability moves from discovery to owner and fix in one view.
Click through it at your own pace, or open it full screen.
Quick check
Is a single organization Label Studio safe from this?
It removes the cross-tenant angle, because there is no other organization to read. You should still upgrade once a fixed version is confirmed.
Sources
Last reviewed: 18 October 2026.
