CVE-2026-85211 in Label Studio
Summary
by MITRE • 09/03/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in Label Studio represents a critical failure in multi-tenant isolation mechanisms, specifically within the proxy API layer responsible for handling data ingestion from external cloud storage providers. In enterprise environments utilizing Label Studio for machine learning dataset annotation, organizations often rely on strict logical separation to ensure that sensitive proprietary data belonging to one tenant remains inaccessible to others. The core technical flaw lies in how the application resolves Uniform Resource Identifiers (URIs) associated with tasks and projects when these resources are stored in external cloud buckets such as Amazon S3 or Google Cloud Storage. Instead of strictly validating that a requested URI belongs exclusively to the storage configuration explicitly linked to the current user's organization, the system fails to enforce this boundary during the presigning process used for temporary access tokens or direct streaming operations. This oversight allows an authenticated attacker who has created their own separate organization within the same Label Studio instance to manipulate input parameters and supply arbitrary file URIs pointing to storage buckets belonging to other tenants.
From a technical perspective, the vulnerability stems from insufficient authorization checks in the proxy_api.py endpoints. When a user requests access to a specific data object via these endpoints, the backend logic is intended to verify that the target URI matches one of the whitelisted or configured URIs associated with the requesting entity's organization scope. However, due to this logical flaw, the validation step either skips checking the organizational context entirely or fails to correctly bind the requested resource ID to the tenant-specific storage configuration. Consequently, if an attacker knows or can guess a valid URI format for another organization’s cloud bucket—often possible through enumeration of common naming conventions or by leveraging information leaked in other parts of the application—they can generate presigned URLs that grant temporary read access to those foreign objects. This effectively bypasses the intended isolation boundaries between tenants, turning what should be a secure multi-tenant architecture into one where data leakage is trivially achievable for any authenticated user with organization creation privileges.
The operational impact of this vulnerability is severe, particularly in sectors handling regulated or confidential information such as healthcare, finance, and intellectual property development. By exploiting this flaw, an attacker can exfiltrate sensitive training datasets, proprietary images, text corpora, or annotated labels belonging to competing organizations or internal departments that were intended to be siloed. This constitutes a direct violation of data confidentiality requirements under standards like GDPR, HIPAA, and SOC 2. Furthermore, the ability to stream bucket contents means that large volumes of data can be extracted without triggering typical bulk-download alerts associated with administrative console access. The risk is compounded by the fact that presigned URLs often have expiration times that may allow for sustained or repeated access if not carefully managed, although typically they are short-lived; nonetheless, even transient access to proprietary datasets can lead to significant competitive disadvantage and legal liability for the affected organizations.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure in enforcing organizational boundaries within a multi-tenant application context. It also maps closely to MITRE ATT&CK technique T1530 Data from Cloud Storage Object, where adversaries retrieve data directly from cloud storage accounts rather than compromising the underlying infrastructure or credentials of the primary account holder. The exploitation path resembles T1078 Valid Accounts combined with lateral movement within a SaaS environment, as the attacker uses legitimate but misconfigured permissions to access resources outside their designated scope. To mitigate this risk, immediate remediation should focus on enforcing strict validation at the application logic level rather than relying solely on cloud provider-level IAM policies. Developers must ensure that every request for data retrieval explicitly verifies that the target URI is associated with an organization ID matching the authenticated user's current context before generating presigned URLs or initiating streams. Additionally implementing rigorous input sanitization and ensuring that storage configurations are strictly scoped to individual organizations will prevent cross-tenant data leakage. Regular security audits focusing on multi-tenancy isolation patterns in web applications are essential to identify similar logical flaws in other components of the platform.