What is the CVSS score of CVE-2026-54457?

CVE-2026-54457 has a CVSS 3.1 base score of 7.7 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. EPSS exploitation probability: 0.3%.

Which versions of TensorZero Gateway are affected by CVE-2026-54457?

TensorZero Gateway versions before 2026.6.0 contain flaws allowing attackers to read sensitive files and access internal infrastructure, exposing credentials and secrets.. A patch is available.

How to fix or mitigate CVE-2026-54457?

Within 24 hours: Identify all systems running tensorzero versions prior to 2026.6.0 and assess network accessibility of the /internal/object_storage endpoint. Within 7 days: upgrade TensorZero to version 2026.6.0 or later and verify authentication is enforced on the /internal/object_storage endpoint. Within 30 days: conduct a security audit of what endpoints were accessible, rotate any credentials potentially exposed through file read, and review the SSRF attack surface on internal and cloud infrastructure.

TensorZero Gateway CVE-2026-54457

EUVD-2026-64144 HIGH

Files or Directories Accessible to External Parties (CWE-552)

2026-07-15 https://github.com/tensorzero/tensorzero

GHSA-824w-x939-6cmc PYSEC-2026-3541

Information Disclosure Path Traversal

7.7

CVSS 3.1 · Vendor: https://github.com/tensorzero/tensorzero

Severity by source

Vendor (https://github.com/tensorzero/tensorzero) PRIMARY

7.7 HIGH

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

vuln.today AI

8.6 HIGH

Default TensorZero deployments run without authentication so PR:N is the realistic worst case; network low-complexity file read plus SSRF pivot gives S:C and C:H with no integrity/availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N

Primary rating from Vendor (https://github.com/tensorzero/tensorzero).

CVSS VectorVendor: https://github.com/tensorzero/tensorzero

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jul 15, 2026 - 22:17 vuln.today

Analysis Generated

Jul 15, 2026 - 22:17 vuln.today

CVE Published

Jul 15, 2026 - 21:59 github-advisory

HIGH 7.7

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

6 pypi packages depend on tensorzero (4 direct, 2 indirect)

Ecosystem-wide dependent count for version 2026.6.0.

DescriptionCVE.org

Impact

The /internal/object_storage endpoint accepts a caller-supplied JSON storage_path parameter that dynamically overrides the TensorZero [object_storage] configuration.

By abusing the filesystem storage type, a caller can read arbitrary files from the gateway filesystem, including files that may contain sensitive credentials. Similarly, by abusing the s3_compatible storage type, the caller can coerce the gateway into making outbound object storage requests to attacker-chosen internal/cloud-metadata endpoints.

This vulnerability only applies when the gateway can be accessed by untrusted callers. If a developer's TensorZero deployment has authentication enabled, only authenticated callers can exploit this vulnerability. If a developer's deployment has authentication disabled, any caller can exploit this vulnerability.

Remediation

The vulnerability has been patched in version 2026.6.0. See PR #7527.

Workarounds

If developers are unable to upgrade a gateway that is exposed to untrusted callers, please block external access to the /internal/object_storage endpoint.

AnalysisAI

Arbitrary file read and server-side request forgery in TensorZero Gateway (pip package tensorzero, versions < 2026.6.0) let callers of the /internal/object_storage endpoint override the gateway's [object_storage] configuration via a caller-supplied storage_path JSON parameter. Using the filesystem storage type an attacker reads arbitrary files (including credential files) from the gateway host, while the s3_compatible type coerces the gateway into outbound requests to attacker-chosen internal or cloud-metadata endpoints. There is no public exploit identified at time of analysis and the flaw is not in CISA KEV; exploitability hinges on whether the deployment has authentication enabled.

Technical ContextAI

TensorZero is an open-source LLM gateway/observability stack whose Rust gateway persists model artifacts (e.g. images) through a pluggable [object_storage] backend supporting filesystem and s3_compatible (S3-style) storage kinds. The internal /internal/object_storage endpoint was designed to resolve StoragePath objects, but it trusted a client-supplied storage_path that dynamically replaced the operator-configured store rather than binding resolution to the gateway's own configuration. This maps to CWE-552 (Files or Directories Accessible to External Parties): untrusted input selects both the storage backend type and the path/target, so a filesystem override yields path/file disclosure and an s3_compatible override yields SSRF. The patched code (commit 0abbc838, PR #7527) hardens the Client::resolve path so the gateway only fetches from its own configured [object_storage], and adds an object-storage-disabled test configuration; affected package identity is pkg:pip/tensorzero.

RemediationAI

Vendor-released patch: upgrade the tensorzero package to version 2026.6.0 or later (fix in commit 0abbc838 / PR #7527), per advisory GHSA-824w-x939-6cmc and release https://github.com/tensorzero/tensorzero/releases/tag/2026.6.0. If immediate upgrade is not possible for a gateway exposed to untrusted callers, block external access to the /internal/object_storage endpoint at a reverse proxy, ingress, or firewall (the vendor's recommended workaround); side effect is that any legitimate internal tooling relying on that endpoint must be sourced from a trusted network segment. Additionally, enable the gateway's authentication so only authenticated callers can reach the endpoint, and constrain the host's outbound network egress and IMDS access (e.g. enforce IMDSv2 / block 169.254.169.254 from the gateway) to blunt the SSRF-to-metadata path, accepting that egress restrictions may break legitimate S3-compatible object storage traffic.