GPU VulnDB

Database/AI/ML frameworks & serving

Hugging Face Text Embeddings Inference: API key written to logs in cleartext at router startup

CVSS 4.8CVE-2026-108857AI/ML frameworks & servingcurated

Impact

The TEI router logs its parsed arguments at startup, and the Args struct has no redact attribute on api_key, so the configured Bearer token appears in cleartext in the process log. Anyone who can read container stdout, the node journal, or the OTLP telemetry pipeline recovers the token and can call the protected embedding and rerank endpoints directly. On a GPU fleet those logs travel much further than the secret was meant to: a cluster-wide log aggregator, a tracing backend, and often a separate observability tenant with its own, broader set of readers. The practical result is that the only access control in front of a GPU-backed embedding service is readable by every log consumer, allowing unauthorized inference that consumes accelerator capacity.

Who can reach it

Local or log-adjacent, with authentication to the logging path rather than to TEI: a user with access to the container output, the node's journal, a central log store, or OTLP traces. No access to the TEI API itself is needed beforehand.

What to do

Treat any api_key configured on an affected TEI deployment (through 1.9.4) as compromised: rotate the token and update the clients that use it. Upgrade to a release that redacts the field once available; the vendor fix is a one-line change to the router. Rollout is a container image bump and restart of the TEI pods - the model has to reload, so queue a short serving gap per replica, but no node drain or reboot. Also scrub the key from retained log stores and tracing backends, which is usually the longer part of the job.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.