GPU VulnDB

Database/AI/ML frameworks & serving

JupyterHub: unauthenticated logins write unbounded usernames to the log, exhausting storage

CVSS 5.3CVE-2026-54338AI/ML frameworks & servingcurated

Impact

A failed form login writes the attacker-supplied username to the hub log with no length bound, so anyone who can reach the login page can push arbitrary volume into the log stream at will. Where hub logs land on the node's root filesystem or are shipped to a metered logging backend, this is a cheap way to fill a disk or burn a quota. On a GPU cluster the hub is the front door for every user's notebook: if it wedges because the filesystem is full, no one's server spawns, and the host needs manual cleanup before the fleet is usable again. No confidentiality or integrity impact.

Who can reach it

Anyone who can reach the hub's login endpoint. No authentication and no valid account needed. The reachable population is whoever gets past whatever fronts the hub - internal-only exposure or an SSO proxy narrows it considerably.

What to do

Upgrade JupyterHub to 5.5.0 and restart the hub process. Until then, rate-limit the login endpoint at the proxy in front of the hub and confirm hub logs rotate with a hard size cap so a flood cannot fill the volume. The advisory names no other mitigation.

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.