CVE-2026-54338: JupyterHub Unauthenticated Denial of Service via Unbounded Username Logging

JupyterHub acts as a multi-user server interface designed to orchestrate and manage individual instances of Jupyter notebooks. At its core, the application exposes a series of network-accessible endpoints, of which /hub/login serves as the primary gateway for user authentication. When form-based authenticators—such as the default Pluggable Authentication Module (PAM) authenticator—are configured, they process authentication requests containing username and password credentials supplied through standard HTTP POST parameters. This mechanism presents an exposed, unauthenticated attack surface to any network client capable of reaching the server interface.

The vulnerability documented under CVE-2026-54338 is classified under CWE-400: Uncontrolled Resource Consumption. The security flaw stems from a systemic omission of length constraints and character verification on the user-supplied input parsed during failed login sequences. When a remote, unauthenticated entity attempts to authenticate with incorrect credentials, the server initiates logical logging mechanisms to record the event. Because the system does not impose arbitrary boundaries or input filtering on the incoming payload data, it parses and writes raw, uncontrolled data directly to system logs and localized output streams.

Form-based authenticators are uniquely affected by this vulnerability due to their design, which processes user-provided inputs directly on the hosting infrastructure. Conversely, non-form-based authentication systems, such as those relying on OAuthenticator and external OAuth 2.0 or OpenID Connect identity providers, are completely unaffected. In external identity configurations, the authentication transaction and initial input processing occur out-of-band on third-party identity provider infrastructure, thereby avoiding the local JupyterHub form handler processing pipeline.

The consequence of this uncontrolled input handling is a remote, unauthenticated Denial of Service (DoS) exploit vector. By repeatedly sending oversized username payloads to the vulnerable /hub/login route, an attacker can consume disk space through rapid log file expansion. Additionally, processing these high-volume, oversized strings within the Python environment results in severe memory consumption and CPU saturation, culminating in the degradation or outright failure of the JupyterHub daemon.

The root cause of CVE-2026-54338 lies within the failure handler pipeline inside JupyterHub's core authentication and login execution paths. When an invalid login request is received, the default PAM authenticator or standard base handler constructs log statements using basic string formatting mechanisms. Prior to version 5.5.0, these systems did not validate the length or structure of the incoming string stored within the username field. The code expected reasonable username strings but lacked any structural validation rules to guarantee this assumption at runtime.

When a login failure triggers, the authenticator's code path handles exceptions such as pamela.PAMError. Within the exception handling block, the application logging library is invoked to document the incident. The vulnerable implementation constructed warning entries using raw string interpolation (%s), inserting the raw, unsanitized username directly into the message buffer. This method allows the output of any arbitrary sequence of bytes or characters present in the HTTP POST request directly into the file write queue of the operating system.

Using %s formatting is a critical coding mistake in this context because it passes the raw bytes of the user input directly into the format string without sanitization. If the string contains newline control characters, such as carriage returns (0x0D) or line feeds (0x0A), the operating system's filesystem writer processes them literally, causing the log entry to split across multiple lines. This behavior creates a secondary vulnerability path in the form of log injection, where attackers can forge valid audit entries to confuse automated intrusion detection systems or security administrators.

Beyond log formatting flaws, the application pipeline also propagates the unsanitized username to the user interface layer upon failure. When rendering the 403 Forbidden response template, the login handler reflects the user-supplied username string back into the HTML document to populate the form fields for subsequent attempts. This action forces the Jinja2 rendering engine to process and build an HTML structure matching the size of the malicious payload. The resource overhead of compiling and transmitting an oversized HTML page consumes significant CPU cycles and ephemeral RAM, compounding the denial of service state.

The vulnerability was remediated in patch commit d6dc595f84b7509969686da31d87d6d69e7fce0a by introducing truncation boundaries and switching the string formatting specifier to %r. The patch modifies three critical files: jupyterhub/auth.py, jupyterhub/handlers/base.py, and jupyterhub/handlers/login.py. These modifications systematically ensure that any failed login username exceeding 32 characters is safely truncated, and control characters are escaped prior to processing.

In jupyterhub/auth.py, the vulnerable PAM authentication handler recorded failed attempts using the standard %s interpolation on the raw username. The patched implementation introduces a conditional validation check that truncates any input exceeding a 32-character boundary:

# Vulnerable code in jupyterhub/auth.py
self.log.warning("PAM Authentication failed (%s@%s): %s", username, handler.request.remote_ip, e)
 
# Patched code in jupyterhub/auth.py
log_username = username
if len(username) > 32:
    log_username = f"{username[:16]}...({len(username)} chars)"
if handler is not None:
    self.log.warning(
        "PAM Authentication failed (%r@%s): %s",
        log_username,
        handler.request.remote_ip,
        e,
    )

This change restricts log entry growth and converts the string interpolation token to %r, which enforces the use of the Python standard library repr() function to escape literal control codes.

A identical defensive pattern is established within jupyterhub/handlers/base.py to cover general authentication failures. The base login handler is modified to extract the username safely and apply the same 32-character length limit before triggering logging operations:

# Patched code in jupyterhub/handlers/base.py
log_username = username = (data or {}).get('username', 'unknown user')
if len(username) > 32:
    log_username = f"{username[:16]}...({len(username)} chars)"
self.log.warning("Failed login for %r", log_username)

By implementing this truncation layer, the core framework prevents the consumption of arbitrary amounts of disk storage during high-volume failed authentication attacks.

Finally, the login template renderer in jupyterhub/handlers/login.py was patched to avoid reflecting oversized inputs into the rendered HTML body. The patch ensures that only the sanitized, truncated log_username is passed to the rendering engine when displaying the 403 failure template:

# Patched code in jupyterhub/handlers/login.py
username = data['username']
log_username = username
if len(username) > 32:
    log_username = f"{username[:16]}...({len(username)} chars)"
self.set_status(403)
html = await self._render(
    login_error='Invalid username or password', username=log_username
)
self.finish(html)

This comprehensive patch effectively seals all three exposure pathways (authenticator logging, base handler logging, and template reflection), presenting a complete fix that resists variant attacks targeting the login pipeline.

Exploitation of CVE-2026-54338 requires that the target JupyterHub instance is running a version prior to 5.5.0 and is configured with a form-based authenticator. The default configuration uses the PAM Authenticator, which meets these criteria. The attacker does not need to possess active credentials on the system or maintain any pre-existing authorization tokens, making this an unauthenticated remote exploit vector.

To execute a storage exhaustion attack, an attacker issues consecutive HTTP POST requests to the /hub/login endpoint of the target instance. The request body contains standard form data, but with the username parameter set to a highly inflated string, such as 10 megabytes of repeating characters. When the server processes this request, the PAM authenticator fails the login and writes the 10-megabyte string directly to the log file. If the attacker automates this process using a multithreaded script, they can write several gigabytes of data to the system disk within minutes, exhausting disk space and triggering system instability.

An attacker can also exploit the raw string interpolation in the logging pipeline to perform log injection. By embedding specific control characters, such as hex byte sequences 0x0D and 0x0A (carriage return and line feed), into a moderately sized username parameter, the attacker can break the logical formatting of the log file. When the server logs the failure, these characters force the log writer to start a new line. The attacker can then append fake log messages that mimic legitimate administrative actions, potentially confusing log monitors or security operations teams.

The visual architecture of this attack flow is illustrated below, tracing the path of the malicious payload from the unauthenticated client through the vulnerable application layers to the ultimate point of resource exhaustion.

The physical impact of a successful exploitation of CVE-2026-54338 ranges from service degradation to complete system outage. When the storage volume hosting the JupyterHub logs reaches 100% utilization, the operating system can no longer execute write commands to system files, causing critical services to stall. The JupyterHub daemon itself may crash or refuse to spawn new single-user servers, preventing legitimate users from accessing their workspace environments and disrupting active computational notebooks.

Furthermore, the uncontrolled allocation of memory inside the Python runtime environment presents a severe stability risk. When the server receives multi-megabyte string payloads, it allocates equivalent blocks of memory to process the HTTP request, interpolate the logs, and render the output HTML page. Under a concurrent attack scenario, these allocations will exceed the available physical RAM on the hosting system. This condition triggers the Linux Out-Of-Memory (OOM) killer, which may abruptly terminate the main JupyterHub process or other critical container workloads.

From a security monitoring perspective, the log injection vector compromises the integrity of audit trails. Because raw strings are written to the logs, attackers can insert forged event entries or corrupt existing records, rendering security audits unreliable. This can hinder post-incident investigation processes and allow malicious activities to go undetected by automated log analysis tools or security information and event management (SIEM) systems.

The vulnerability is assigned a CVSS v3.1 base score of 5.3 (Medium), reflecting network exploitability with low complexity and no required privileges, balanced by a localized impact profile. While confidentiality and integrity impacts are officially rated as none, the practical risk is amplified in shared hosting or cloud environments where a single compromised or exhausted storage volume can affect multiple tenant applications running on the same host infrastructure.

The primary remediation strategy for CVE-2026-54338 is upgrading JupyterHub to version 5.5.0 or later. This release incorporates the official patch that limits failed login username lengths to 32 characters and applies strict character escaping via %r formatting. System administrators should verify their current deployment versions using the command jupyterhub --version and schedule an immediate upgrade if the running version is within the affected range.

If an immediate upgrade is not feasible due to change control constraints, several effective mitigation strategies can be applied to reduce exposure. Administrators can transition from form-based authenticators to external authentication systems, such as OAuthenticator using OAuth 2.0 or OpenID Connect. Because these configurations handle authentication external to the JupyterHub host, the local login handlers are not exposed to raw user credentials, rendering the vulnerability path inaccessible to attackers.

Implementing rate limiting at the reverse proxy layer is also recommended to defend against high-volume Denial of Service attempts. For instances utilizing Nginx as a front-end proxy, a rate limit can be enforced on the /hub/login endpoint to restrict the frequency of incoming POST requests from individual IP addresses:

# Configure Nginx rate limiting for the login route
limit_req_zone $binary_remote_addr zone=login_limit_zone:10m rate=5r/m;
 
location /hub/login {
    limit_req zone=login_limit_zone burst=10 nodelay;
    proxy_pass http://127.0.0.1:8000;
}

This configuration limits attackers to 5 login attempts per minute, preventing the rapid log bloat required to trigger storage exhaustion.

Finally, standard host-hardening practices can mitigate the operational impact of log file growth. Configuring robust log rotation policies with logrotate to strictly limit maximum log file sizes and storage retention periods ensures that uncontrolled disk growth is mitigated. Additionally, placing the logging directory /var/log on a dedicated partition separate from the primary system partition prevents log growth from exhausting storage resources required by the core operating system.