CVE-2025-25297: Label Studio S3 Storage SSRF Vulnerability

CVE-2025-25297 Overview

Label Studio, an open source data labeling platform from HumanSignal, contains a Server-Side Request Forgery (SSRF) vulnerability in its S3 storage integration. Versions prior to 1.16.0 accept a user-supplied s3_endpoint parameter and pass it directly to the boto3 AWS SDK without validating the protocol or destination. An authenticated attacker can point this endpoint at arbitrary internal services and trigger storage sync operations to coerce the server into issuing HTTP requests. Failed request error messages return the full response body, enabling data exfiltration from internal resources. The flaw is tracked as [CWE-918] and was patched in Label Studio 1.16.0.

Critical Impact
Authenticated attackers can pivot through Label Studio to reach internal services behind network segmentation and exfiltrate response bodies via error messages.

Affected Products

HumanSignal Label Studio versions prior to 1.16.0
Deployments exposing the S3 storage integration endpoint configuration
Self-hosted Label Studio instances accepting custom s3_endpoint values

Discovery Timeline

2025-02-14 - CVE-2025-25297 published to NVD
2025-08-25 - Last updated in NVD database

Technical Details for CVE-2025-25297

Vulnerability Analysis

Label Studio exposes an S3 storage connection feature that lets users configure third-party or S3-compatible object stores. The configuration accepts an s3_endpoint URL that the application forwards verbatim to the boto3 client. Because no protocol allow-list, hostname filtering, or DNS resolution check is applied, the parameter can reference loopback addresses, link-local metadata services such as 169.254.169.254, or arbitrary internal hosts.

When a storage sync runs, boto3 issues HTTP requests to the attacker-controlled endpoint as if it were an S3 API call. The remote service responds with its own content, which boto3 then surfaces as a parsing or signature error. Label Studio includes the full response body in the resulting error message returned to the requesting user, converting the SSRF into a blind-to-full-read primitive.

Root Cause

The root cause is missing input validation on the s3_endpoint parameter combined with verbose error propagation. Trusted endpoint domains were not enforced, and SDK exceptions returned upstream response bodies to the API consumer. The remediation in 1.16.0 introduces an S3_TRUSTED_STORAGE_DOMAINS allow-list and a catch_and_reraise_from_none helper that strips response detail for untrusted destinations.

Attack Vector

Exploitation requires an authenticated account with permission to create or modify S3 storage configurations. The attacker submits a storage definition where s3_endpoint references an internal target (for example, a cloud metadata service or an internal admin API). Triggering a sync forces Label Studio to call the target, and the returned error message discloses the response body.

python

 if CSRF_TRUSTED_ORIGINS:
     CSRF_TRUSTED_ORIGINS = CSRF_TRUSTED_ORIGINS.split(',')
 
+# Custom S3 endpoints on these domains will get detailed error reporting
+S3_TRUSTED_STORAGE_DOMAINS = get_env_list(
+    'S3_TRUSTED_STORAGE_DOMAINS',
+    [
+        'amazonaws.com',
+        'scw.cloud',
+        'yandexcloud.net',
+        'digitaloceanspaces.com',
+        'orange-business.com',
+        'computecanada.ca',
+        'cloudflarestorage.com',
+        'wasabisys.com',
+        'oracle.com',
+        'amazon.com',
+        'appdomain.cloud',
+    ],
+)

Source: HumanSignal label-studio commit 06a2b29

The patch also wires a new exception wrapper into the S3 storage models to suppress verbose error chaining:

python

     ImportStorageLink,
     ProjectStorageMixin,
 )
-from io_storages.s3.utils import get_client_and_resource, resolve_s3_url
+from io_storages.s3.utils import catch_and_reraise_from_none, get_client_and_resource, resolve_s3_url
 from io_storages.utils import storage_can_resolve_bucket_url
 from tasks.models import Annotation
 from tasks.validation import ValidationError as TaskValidationError

Source: HumanSignal label-studio commit 06a2b29

Detection Methods for CVE-2025-25297

Indicators of Compromise

Label Studio S3 storage records whose s3_endpoint value resolves to RFC1918, loopback, or link-local addresses such as 169.254.169.254
Outbound HTTP requests from the Label Studio host targeting internal services that do not expose S3 APIs
Application error logs containing non-S3 response bodies returned from boto3 storage sync operations
Repeated storage sync failures from a single user account against varied endpoint hostnames

Detection Strategies

Audit the Label Studio database for storage configurations created prior to upgrade and review every s3_endpoint value against the S3_TRUSTED_STORAGE_DOMAINS allow-list
Inspect web server and application logs for storage sync API calls followed by error responses containing HTML, JSON, or metadata service signatures
Correlate authenticated Label Studio sessions with egress traffic from the application server to internal IP ranges

Monitoring Recommendations

Restrict outbound network access from the Label Studio server to only sanctioned object storage providers
Alert on DNS queries from the Label Studio host to internal zones or cloud metadata endpoints
Log all create and update events on the S3 storage configuration API and review them during change windows

How to Mitigate CVE-2025-25297

Immediate Actions Required

Upgrade Label Studio to version 1.16.0 or later on all self-hosted deployments
Review existing S3 storage integrations and remove any configurations referencing untrusted or internal endpoints
Rotate any credentials, tokens, or metadata that may have been exposed via the cloud instance metadata service
Restrict Label Studio user permissions so that only trusted roles can create or modify storage connections

Patch Information

The fix is included in Label Studio 1.16.0 and is documented in GitHub Security Advisory GHSA-m238-fmcw-wh58. The corresponding code change is available in the HumanSignal label-studio commit 06a2b29. The patch introduces the S3_TRUSTED_STORAGE_DOMAINS configuration and a new exception handler that prevents response bodies from being returned for non-trusted endpoints.

Workarounds

Configure S3_TRUSTED_STORAGE_DOMAINS to enforce an allow-list of permitted object storage domains
Place Label Studio behind an egress proxy that blocks requests to internal IP ranges and metadata services
Disable IMDSv1 and require IMDSv2 with hop-limit controls on cloud-hosted Label Studio instances

bash

# Configuration example: restrict S3 endpoints to trusted domains
export S3_TRUSTED_STORAGE_DOMAINS="amazonaws.com,digitaloceanspaces.com,wasabisys.com"

# Verify installed Label Studio version is patched
pip show label-studio | grep -i version