AI Threat Alert
JupyterHub's form-based login accepts unbounded, attacker-controlled username strings on failed login attempts and writes them verbatim into logs, letting anyone who can reach the login page — no credentials required — flood disk and logging infrastructure with oversized entries. This is a low-complexity, network-reachable denial-of-service against a platform that many organizations use as the shared front door to their data science and AI/ML notebook environments, so a successful flood can take down a multi-tenant research or training workspace for every user on it, not just the attacker. The CVSS score (5.3, medium) and low EPSS (0.28th percentile, top 79% least likely to be exploited soon) reflect that this is a resource-exhaustion nuisance rather than a data-loss or code-execution bug, and it is not in CISA KEV, has no public exploit, and no Nuclei template exists, so exploitation in the wild is currently unlikely. Patch to JupyterHub 5.5.0, and in the interim rate-limit or WAF-protect the login endpoint and monitor log volume/disk usage on JupyterHub hosts for anomalous spikes tied to failed-login events.
What is the risk?
Medium risk overall: the vulnerability is trivially reachable by an unauthenticated network attacker (AV:N/AC:L/PR:N/UI:N) and requires no special skill, but its impact is limited to availability (A:L) with no confidentiality or integrity loss. Exploitability in practice is low right now — EPSS sits at 0.28% (top 79% least-likely bucket), there's no CISA KEV listing, no public PoC, and no scanner template, and CISA's own SSVC decision is TRACK (monitor, not urgent action). The main risk driver is that JupyterHub is frequently deployed as shared, multi-tenant infrastructure for AI/ML teams, so a successful DoS has an outsized blast radius relative to the vulnerability's technical severity.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Jupyter | pip | < 5.5.0 | 5.5.0 |
Do you use Jupyter? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade JupyterHub to 5.5.0 or later, which caps/sanitizes the logged username to prevent unbounded log growth. Until patched, place rate limiting or a WAF rule in front of the login endpoint to throttle repeated failed-login POSTs from a single source, and configure log rotation with size caps plus disk-usage alerting on JupyterHub hosts to prevent storage exhaustion from becoming an outage. Detection: monitor for failed-login log entries with abnormally long username fields or a sudden spike in failed-login volume from a small number of source IPs, and alert on rapid disk/log-volume growth correlated with authentication endpoints.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-54338?
JupyterHub's form-based login accepts unbounded, attacker-controlled username strings on failed login attempts and writes them verbatim into logs, letting anyone who can reach the login page — no credentials required — flood disk and logging infrastructure with oversized entries. This is a low-complexity, network-reachable denial-of-service against a platform that many organizations use as the shared front door to their data science and AI/ML notebook environments, so a successful flood can take down a multi-tenant research or training workspace for every user on it, not just the attacker. The CVSS score (5.3, medium) and low EPSS (0.28th percentile, top 79% least likely to be exploited soon) reflect that this is a resource-exhaustion nuisance rather than a data-loss or code-execution bug, and it is not in CISA KEV, has no public exploit, and no Nuclei template exists, so exploitation in the wild is currently unlikely. Patch to JupyterHub 5.5.0, and in the interim rate-limit or WAF-protect the login endpoint and monitor log volume/disk usage on JupyterHub hosts for anomalous spikes tied to failed-login events.
Is CVE-2026-54338 actively exploited?
No confirmed active exploitation of CVE-2026-54338 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-54338?
Upgrade JupyterHub to 5.5.0 or later, which caps/sanitizes the logged username to prevent unbounded log growth. Until patched, place rate limiting or a WAF rule in front of the login endpoint to throttle repeated failed-login POSTs from a single source, and configure log rotation with size caps plus disk-usage alerting on JupyterHub hosts to prevent storage exhaustion from becoming an outage. Detection: monitor for failed-login log entries with abnormally long username fields or a sudden spike in failed-login volume from a small number of source IPs, and alert on rapid disk/log-volume growth correlated with authentication endpoints.
What systems are affected by CVE-2026-54338?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, ML development environments, multi-tenant research platforms.
What is the CVSS score for CVE-2026-54338?
CVE-2026-54338 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.44%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029 Denial of AI Service Compliance Controls Affected
What are the technical details?
Original Advisory
JupyterHub is software that allows users to create a multi-user server for Jupyter notebooks. Prior to 5.5.0, invalid input to form-based login authenticators can place an unbounded attacker-controlled username in failed-login logs, allowing an unauthenticated attacker to consume logging and storage resources. This issue is fixed in version 5.5.0.
Exploitation Scenario
An unauthenticated attacker scripts repeated POST requests to a public-facing JupyterHub login form, each carrying a form-based username field padded to tens of kilobytes. Each failed attempt is written to JupyterHub's logs in full, so a modest request rate over a short period can generate gigabytes of log data, exhausting disk space or overwhelming log-processing pipelines. As storage fills or logging bottlenecks the process, the shared notebook platform becomes unresponsive or crashes outright, denying every data scientist and ML engineer on that hub access to their training and experimentation environments until an administrator intervenes.
Weaknesses (CWE)
CWE-400 Uncontrolled Resource Consumption
Primary
CWE-400 Uncontrolled Resource Consumption
Primary
CWE-400 Uncontrolled Resource Consumption CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.
- [Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- [Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L References
Timeline
Related Vulnerabilities
CVE-2023-25574 10.0 JupyterHub LTI13: JWT forgery enables full auth bypass
Same package: jupyter CVE-2026-44180 9.8 Jupyter Enterprise Gateway: root privilege bypass in Kubernetes
Same package: jupyter CVE-2026-23537 9.1 Feast: unauth file write to RCE via /save-document
Same package: jupyter CVE-2026-54527 9.0 jupyterlab-git: stored XSS escalates to full RCE
Same package: jupyter CVE-2026-44727 9.0 jupyter-server: stored XSS yields kernel RCE
Same package: jupyter