CVE-2026-54338

JupyterHub versions prior to 5.5.0 contain an input validation failure in the form-based authentication path. When a login attempt fails, the submitted username is logged without bounds-checking or sanitization. An attacker can submit a crafted username containing arbitrary characters — including newlines, control sequences, or log formatter injection tokens — which then persists verbatim into JupyterHub's structured log storage. If your JupyterHub instance forwards logs to a downstream aggregation system (Splunk, ELK, Datadog, or any SIEM), the attack surface extends beyond local storage. A malicious username becomes an injection vector into your security monitoring pipeline, where log entries are typically treated as trusted. This transforms what might appear as a medium-severity local issue into a potential pivot point for downstream compromise. Check your deployed JupyterHub version immediately. If you are on 5.4.x or earlier, upgrade to 5.5.0 or later. If immediate patching is not feasible, audit whether JupyterHub log output is being forwarded anywhere — and if so, implement log preprocessing or field extraction that treats username fields from authentication failure logs as untrusted input. Do not assume log consumers handle arbitrary input safely; most SIEM configurations parse log streams as trusted data. The vulnerability was present in what was likely years-old debugging code that survived multiple security reviews because logging sits outside the typical input-validation mindset. This is a reminder that log write paths are data boundaries just like database queries or render outputs — they deserve the same scrutiny.

Reviewed through automated stages and approved by a human before publication.