What is the CVSS score of CVE-2026-54338?

CVE-2026-54338 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. EPSS exploitation probability: 0.3%.

Is there a public PoC exploit available for CVE-2026-54338?

Yes, a public proof-of-concept exploit is available for CVE-2026-54338. Prioritise patching immediately. EPSS: 0.3%.

Is there a patch available for CVE-2026-54338?

Yes, a patch is available for CVE-2026-54338. Update the affected software to the latest version immediately.

JupyterHub CVE-2026-54338

EUVD-2026-54678 MEDIUM

Uncontrolled Resource Consumption (CWE-400)

2026-08-07 GitHub_M

GHSA-p43p-whwx-q52h

Denial Of Service Jupyterhub

5.3

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

5.3 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

vuln.today AI

5.3 MEDIUM

Login endpoint is network-accessible with no authentication; only availability is impacted via log storage exhaustion, with no confidentiality or integrity effect.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

Low

Lifecycle Timeline

Patch available

Aug 07, 2026 - 22:17 EUVD

Source Code Evidence Fetched

Aug 07, 2026 - 21:35 vuln.today

Analysis Generated

Aug 07, 2026 - 21:35 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Log flooding via unbounded username input in JupyterHub's form-based login handler allows unauthenticated remote attackers to exhaust logging and disk storage resources on multi-user Jupyter notebook servers running versions prior to 5.5.0. The root cause (CWE-400) is that failed login attempts wrote the full attacker-supplied username - with no length cap - directly into application logs across three distinct code paths: the base login handler, the login POST handler, and the PAM authenticator. No public exploit code has been identified at the time of analysis, and this vulnerability is not listed in the CISA KEV catalog.

Technical ContextAI

JupyterHub is a Python-based multi-user server for Jupyter notebooks, commonly deployed in academic, research, and data science environments. The affected code spans three files: jupyterhub/handlers/base.py (login_user method), jupyterhub/handlers/login.py (post method), and jupyterhub/auth.py (PAM authenticate method). In each case, the raw value of the 'username' field from the POST body was passed directly to self.log.warning() or equivalent without any length validation, matching CWE-400 (Uncontrolled Resource Consumption). The fix in commit d6dc595 introduces a 32-character threshold: usernames exceeding this are truncated in log output to the first 16 characters plus a character count annotation, preventing unbounded log writes. CPE cpe:2.3:a:jupyterhub:jupyterhub:*:*:*:*:*:*:*:* confirms all release lines prior to 5.5.0 are affected.

RemediationAI

Upgrade JupyterHub to version 5.5.0 or later, which contains the fix introduced in commit d6dc595f84b7509969686da31d87d6d69e7fce0a. The vendor advisory is available at https://github.com/jupyterhub/jupyterhub/security/advisories/GHSA-p43p-whwx-q52h. If immediate upgrade is not possible, compensating controls include: configuring log rotation with aggressive size caps (e.g., logrotate maxsize 100M) to limit disk consumption - note this does not prevent log flooding, only bounds its impact; deploying a reverse proxy (nginx, Traefik) in front of JupyterHub with per-IP rate limiting on POST /login to reduce the attacker's write throughput; and restricting network access to the JupyterHub login endpoint to known IP ranges where operationally feasible. Rate limiting is the most effective compensating control but may block legitimate users behind shared NAT.