CVE-2026-54457: TensorZero Gateway Information Disclosure

CVE-2026-54457 Overview

CVE-2026-54457 affects TensorZero, an open-source LLMOps platform that unifies an LLM gateway, observability, evaluation, optimization, and experimentation. The TensorZero Gateway /internal/object_storage endpoint accepts a caller-supplied JSON storage_path parameter that dynamically overrides the [object_storage] configuration. Attackers can select the filesystem storage type to read arbitrary files from the gateway host, including credential files. Selecting the s3_compatible storage type redirects outbound object-storage requests to attacker-chosen internal services or cloud metadata endpoints. The issue is fixed in version 2026.6.0.

Critical Impact
Attackers with access to the gateway can read arbitrary filesystem files and pivot to internal or cloud-metadata endpoints via Server-Side Request Forgery (SSRF).

Affected Products

TensorZero Gateway versions prior to 2026.6.0
Deployments exposing the /internal/object_storage endpoint
Both authenticated and unauthenticated gateway deployments

Discovery Timeline

2026-08-21 - CVE-2026-54457 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-54457

Vulnerability Analysis

The vulnerability falls under [CWE-552: Files or Directories Accessible to External Parties]. The TensorZero Gateway exposes an internal endpoint that resolves storage paths using a JSON payload supplied by the caller. The storage_path parameter dynamically overrides the server's [object_storage] configuration at request time. This design allows a caller to change both the storage backend type and its target location per request.

When the caller sets the storage type to filesystem, the gateway reads the requested path from the local disk. This enables disclosure of sensitive files such as /etc/passwd, cloud credential files, and application secrets. When the caller sets the storage type to s3_compatible, the gateway issues outbound HTTP requests to a caller-controlled endpoint. Attackers use this to reach internal-only services and cloud instance metadata services such as http://169.254.169.254/.

Root Cause

The root cause is the absence of validation on the caller-supplied storage_path structure. The gateway treats untrusted input as authoritative configuration for a security-sensitive operation. The prior StoragePathResolver implementation passed the entire storage_path object to get_object, allowing the resolver to honor attacker-chosen backends rather than the server's configured backend.

Attack Vector

The attack requires network access to the gateway's /internal/object_storage endpoint. Depending on deployment, this endpoint may be reachable without authentication. An attacker sends a JSON body specifying either a local filesystem path or a remote s3_compatible endpoint under their control.

rust

 impl StoragePathResolver for Client {
     async fn resolve(&self, storage_path: StoragePath) -> Result<String, Error> {
         Ok(self
-            .get_object(storage_path.clone())
+            .get_object(&storage_path.path)
             .await
             .map_err(|e| {
                 Error::new(ErrorDetails::InternalError {

Source: GitHub commit 0abbc83. The patch changes the resolver to use only the path component of storage_path, ignoring the caller-supplied backend override.

Detection Methods for CVE-2026-54457

Indicators of Compromise

Requests to /internal/object_storage containing a storage_path field with kind set to filesystem or s3_compatible.
Outbound connections from the gateway host to 169.254.169.254, metadata.google.internal, or unexpected internal IP ranges.
Gateway process reads of sensitive files such as ~/.aws/credentials, /etc/passwd, or Kubernetes service account tokens.

Detection Strategies

Enable HTTP access logging on the TensorZero Gateway and alert on any request path matching /internal/object_storage.
Inspect request bodies for JSON keys overriding the storage backend (kind, bucket_name, endpoint, path).
Correlate gateway process file reads with outbound requests to detect chained SSRF-to-credential exfiltration.

Monitoring Recommendations

Monitor egress traffic from LLM gateway hosts and block access to link-local metadata addresses at the network layer.
Alert on gateway processes reading credential files or files outside their expected working directories.
Track version strings reported by TensorZero deployments and flag any instance running below 2026.6.0.

How to Mitigate CVE-2026-54457

Immediate Actions Required

Upgrade TensorZero to version 2026.6.0 or later, which contains the fix from pull request #7527.
Restrict network access to the /internal/object_storage endpoint using a reverse proxy or firewall rule so only trusted callers can reach it.
Rotate any credentials, API keys, or tokens accessible from the gateway host if exploitation is suspected.

Patch Information

The fix is included in TensorZero release 2026.6.0. See GHSA-824w-x939-6cmc for the vendor advisory. The patch also updates end-to-end test configurations to disable object storage by default via an object-storage-disabled config overlay.

Workarounds

Place the gateway behind an authenticating reverse proxy and deny external access to any path beginning with /internal/.
Run the gateway as an unprivileged user in a container without access to host credential files or cloud metadata endpoints.
Enforce IMDSv2 on AWS workloads and block link-local 169.254.169.254 traffic from the gateway namespace.

bash

# Example: block metadata endpoint access from the gateway container
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 169.254.170.2 -j DROP

# Example: nginx rule to deny external access to internal endpoints
# location /internal/ { deny all; return 404; }