GPU VulnDB

Database/AI/ML frameworks & serving

Jupyter Server: Referer header is logged unscrubbed, leaking auth tokens into server logs

CVSS 7.1CVE-2026-86049AI/ML frameworks & servingcurated

Impact

The 5xx logging path copies the Referer header into a JSON header block without the token scrubbing applied to the request URI, so any request that errors with HTTP 500 while carrying a token-bearing URL in Referer writes that token to the log in plaintext. Anyone who can read those logs - and on a GPU fleet that usually means the whole platform team plus whatever central log pipeline the cluster ships to - can replay the token and act with the notebook owner's permissions: read their data, run code on their GPU allocation, and reach anything mounted into the notebook pod. The credential outlives the incident that leaked it, since Jupyter tokens do not rotate on their own.

Who can reach it

Reading the Jupyter Server logs (local file, container stdout, or the cluster log aggregator) is enough for the attacker; no Jupyter authentication needed on their part. The leak itself requires a user request that 500s while its Referer carries a token URL.

What to do

Upgrade Jupyter Server to 2.21.0 and restart the affected notebook servers - on Kubernetes this means rolling the single-user pods, which interrupts running kernels. Also treat existing logs as credential material: rotate tokens for any user whose token may already appear, and scrub or expire the collected logs.

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.