CVE-2026-85211: Label Studio: org filter bypass leaks tenant storage

HIGHPoC AVAILABLECISA: TRACK*
Published September 3, 2026
CISO Take

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.

Sources:NVDGitHub Advisoryvulncheck.comATLAS

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?

Establish adversary tenant
Attacker self-registers a separate organization/account on the shared Label Studio instance.
AML.T0021
Discover target storage URIs
Attacker identifies or guesses project/task storage URIs belonging to a victim organization's connected cloud bucket.
AML.T0007
Bypass organization filter
Attacker calls the proxy_api.py presign/stream endpoint with the victim's storage URI; the missing org-scoping check returns valid access.
AML.T0049
Exfiltrate cross-tenant data
Attacker downloads labeled training data or raw files from the victim organization's cloud storage bucket without holding any cloud credentials.
AML.T0025

What systems are affected?

PackageEcosystemVulnerable RangePatched
Label Studiopip—No patch
28.6K2 dependentsPushed yesterday50% patched~275d to patchFull package profile →

Do you use Label Studio? You're affected.

How severe is it?

CVSS 3.1
7.7 / 10
EPSS
0.4%
chance of exploitation in 30 days
Higher than 36% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Moderate
Exploitation Confidence
medium
○CISA SSVC: Public PoC
○Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACLow
PRLow
UINone
SChanged
CHigh
INone
ANone

What should I do?

1 step
  1. 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 does CISA's SSVC say?

DecisionTrack*
Exploitationpoc
AutomatableNo
Technical Impactpartial

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:

EU AI Act
Article 10-Data and data governance
ISO 42001
A.7.2-Data for AI systems
NIST AI RMF
GOVERN 1.2-Data and access governance

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

training pipelinesdata labeling/annotation pipelinesmulti-tenant AI/MLOps platforms

MITRE ATLAS Techniques

AML.T0007Discover AI Artifacts
AML.T0025Exfiltration via Cyber Means
AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 10
ISO 42001: A.7.2
NIST AI RMF: GOVERN 1.2

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:N

Timeline

Published
September 3, 2026
Last Modified
September 24, 2026
First Seen
September 3, 2026

Related Vulnerabilities