CVE-2026-85211: Label Studio: org filter bypass leaks tenant storage
HIGHPoC AVAILABLECISA: TRACK*Label Studio's storage-proxy endpoints fail to check organization ownership when resolving a presign or stream request, so any authenticated user — including someone who just signed up for their own free organization on a shared instance — can supply an arbitrary storage URI belonging to a different tenant and pull back the underlying cloud bucket contents. This is a classic IDOR (CWE-639) reachable over the network with no user interaction and only low privileges, and the CVSS 7.7 confidentiality-only score understates the real exposure for a labeling platform whose entire purpose is warehousing raw and annotated training data. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so this isn't being mass-exploited today, but the bar to weaponize it is low — a self-service org signup plus a crafted API call — and Label Studio already carries 9 other CVEs and a below-average 39/100 package risk score, suggesting it hasn't had deep security hardening. Any organization running a multi-tenant or shared Label Studio deployment (self-hosted or on Label Studio Enterprise-style setups) should treat this as urgent: check the vendor advisory and GitHub issue #9924 for a patched release, and until then restrict `proxy_api.py` storage endpoints at the network/WAF layer and audit access logs for cross-organization storage URI requests.
What is the risk?
High risk despite the confidentiality-only impact (C:H/I:N/A:N). Network-exploitable, low attack complexity, and only low privileges required (a self-registered account on the victim's own instance is enough) make this trivially reachable in any multi-tenant deployment. No patched version is listed yet and no exploit code is public, which caps near-term mass exploitation, but the vulnerability class (missing tenant-scoping on an object-resolution endpoint) is well understood and easy to reproduce once the technical writeup (linked GitHub source) is read. The Scope:Changed rating reflects that the flaw lets an attacker reach resources (cloud storage objects) outside the vulnerable component's own security boundary — the actual blast radius depends entirely on what's stored in each tenant's connected buckets.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Label Studio | pip | — | No patch |
Do you use Label Studio? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Check the linked GitHub issue (#9924) and vendor advisory for a patched release and upgrade
label-studioas soon as one is available — no patched version was listed at time of writing. 2) Until patched, restrict access to/api/.../presignand storage-proxy/streaming endpoints inproxy_api.pyvia a WAF or reverse-proxy rule that ties requests to session organization context. 3) If running a shared/multi-tenant instance, consider temporarily disabling self-service organization signup or isolating each tenant to a dedicated Label Studio deployment with separate storage credentials (least-privilege bucket scoping) rather than shared service credentials. 4) Audit cloud storage access logs for presign/stream requests referencing URIs outside the requesting principal's expected bucket prefixes. 5) Rotate cloud storage credentials used by Label Studio if any cross-tenant access is suspected, and reviewadmin_jobs/access logs for anomalous cross-org task or project reads.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-85211?
Label Studio's storage-proxy endpoints fail to check organization ownership when resolving a presign or stream request, so any authenticated user — including someone who just signed up for their own free organization on a shared instance — can supply an arbitrary storage URI belonging to a different tenant and pull back the underlying cloud bucket contents. This is a classic IDOR (CWE-639) reachable over the network with no user interaction and only low privileges, and the CVSS 7.7 confidentiality-only score understates the real exposure for a labeling platform whose entire purpose is warehousing raw and annotated training data. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so this isn't being mass-exploited today, but the bar to weaponize it is low — a self-service org signup plus a crafted API call — and Label Studio already carries 9 other CVEs and a below-average 39/100 package risk score, suggesting it hasn't had deep security hardening. Any organization running a multi-tenant or shared Label Studio deployment (self-hosted or on Label Studio Enterprise-style setups) should treat this as urgent: check the vendor advisory and GitHub issue #9924 for a patched release, and until then restrict `proxy_api.py` storage endpoints at the network/WAF layer and audit access logs for cross-organization storage URI requests.
Is CVE-2026-85211 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-85211, increasing the risk of exploitation.
How to fix CVE-2026-85211?
1) Check the linked GitHub issue (#9924) and vendor advisory for a patched release and upgrade `label-studio` as soon as one is available — no patched version was listed at time of writing. 2) Until patched, restrict access to `/api/.../presign` and storage-proxy/streaming endpoints in `proxy_api.py` via a WAF or reverse-proxy rule that ties requests to session organization context. 3) If running a shared/multi-tenant instance, consider temporarily disabling self-service organization signup or isolating each tenant to a dedicated Label Studio deployment with separate storage credentials (least-privilege bucket scoping) rather than shared service credentials. 4) Audit cloud storage access logs for presign/stream requests referencing URIs outside the requesting principal's expected bucket prefixes. 5) Rotate cloud storage credentials used by Label Studio if any cross-tenant access is suspected, and review `admin_jobs`/access logs for anomalous cross-org task or project reads.
What systems are affected by CVE-2026-85211?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, data labeling/annotation pipelines, multi-tenant AI/MLOps platforms.
What is the CVSS score for CVE-2026-85211?
CVE-2026-85211 has a CVSS v3.1 base score of 7.7 (HIGH). The EPSS exploitation probability is 0.41%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0007Discover AI ArtifactsAML.T0025Exfiltration via Cyber MeansAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
Label Studio fails to apply organization filters when resolving storage URIs for tasks and projects in proxy_api.py endpoints. Attackers can access other tenants' cloud storage objects by creating a separate organization and supplying arbitrary file URIs to presign or stream bucket contents.
Exploitation Scenario
An attacker signs up for a free/self-service organization on a shared Label Studio instance (SaaS or internally shared deployment). After authenticating, they enumerate or guess project/task identifiers and storage URIs belonging to a different organization — these can often be inferred from predictable bucket-naming conventions or leaked from public documentation/screenshots. The attacker then calls the storage-proxy endpoint in `proxy_api.py` (presign or stream) directly with the victim org's storage URI. Because the endpoint never re-validates that the requesting user's organization owns that storage connection, Label Studio's backend service credentials generate a valid presigned URL or stream the object directly, handing the attacker labeled training data, raw files, or other bucket contents belonging to a completely separate tenant — no cloud credentials of their own required.
Weaknesses (CWE)
CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
- [Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- [Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:NReferences
- github.com/HumanSignal/label-studioproduct
- github.com/HumanSignal/label-studio/blob/1.23.0/label_studio/io_storages/proxy_api.pytechnical-description
- github.com/HumanSignal/label-studio/issues/9924issue-tracking
- vulncheck.com/advisories/label-studio-through-1.23.0-cross-organization-storage-uri-resolutionthird-party-advisory
Timeline
Related Vulnerabilities
CVE-2026-760738.8Label Studio: IDOR exposes cross-org annotations
Same package: label-studioCVE-2025-252978.6Label Studio: SSRF via S3 endpoint exposes internal services
Same package: label-studioCVE-2026-851798.5Label Studio: SSRF via webhooks hits cloud metadata
Same package: label-studioCVE-2025-51737.8label-studio-ml: PyTorch .pt deserialization RCE in YOLO loader
Same package: label-studioCVE-2022-365516.5Label Studio: SSRF + file read, self-reg bypass
Same package: label-studio