CVE-2026-34052: JupyterHub LTI Authenticator DoS Vulnerability

CVE-2026-34052 Overview

CVE-2026-34052 is a memory exhaustion vulnerability in LTI JupyterHub Authenticator, a JupyterHub authenticator for Learning Tools Interoperability (LTI). Prior to version 1.6.3, the LTI 1.1 validator stores OAuth nonces in a class-level dictionary that grows without bounds. Nonces are added before signature validation, allowing an attacker with knowledge of a valid consumer key to send repeated requests with unique nonces to gradually exhaust server memory, causing a denial of service condition.

Critical Impact

An attacker can cause a denial of service by exhausting server memory through unbounded nonce storage, potentially disrupting JupyterHub services for educational institutions and organizations relying on LTI authentication.

Affected Products

• LTI JupyterHub Authenticator versions prior to 1.6.3
• JupyterHub deployments using LTI 1.1 authentication
• Educational platforms utilizing LTI integration with JupyterHub

Discovery Timeline

• April 3, 2026 - CVE-2026-34052 published to NVD
• April 7, 2026 - Last updated in NVD database

Technical Details for CVE-2026-34052

Vulnerability Analysis

This vulnerability is classified as CWE-401 (Missing Release of Memory after Effective Lifetime), a memory leak vulnerability that can lead to denial of service. The LTI 1.1 validator in ltiauthenticator uses a class-level dictionary to store OAuth nonces for replay protection. However, this dictionary has no mechanism to limit its size or expire old entries.

The critical flaw lies in the order of operations during request validation. Nonces are added to the storage dictionary before the OAuth signature is verified, which means even requests with invalid signatures will contribute to the growing dictionary. This design flaw allows an attacker who only knows a valid consumer key (but not the secret) to inject arbitrary nonces into the storage.

Root Cause

The root cause stems from the implementation of nonce storage for OAuth 1.0a replay protection. In OAuth 1.0a, nonces must be stored to prevent replay attacks, but the implementation failed to include:

1. A maximum size limit for the nonce dictionary
2. A mechanism to expire or remove old nonces after a reasonable time window
3. Validation of the OAuth signature before storing the nonce

This architectural oversight means the nonce dictionary grows indefinitely with each unique request, regardless of whether the request is legitimate.

Attack Vector

The attack is network-based and does not require authentication or user interaction. An attacker needs only knowledge of a valid OAuth consumer key, which may be discoverable through configuration files, documentation, or reconnaissance. The attacker then sends a high volume of requests, each containing a unique nonce value, to the JupyterHub authentication endpoint.

Since nonces are stored before signature validation, every request—even those with invalid signatures—contributes to memory consumption. Over time, the accumulated nonces exhaust available server memory, causing the JupyterHub service to become unresponsive or crash.

The attack can be executed gradually to avoid detection, as there is no immediate impact from individual requests. The vulnerability does not require high privileges or complex attack chains, making it relatively straightforward to exploit.

Detection Methods for CVE-2026-34052

Indicators of Compromise

• Gradual increase in memory consumption on JupyterHub servers over time
• High volume of LTI authentication requests with unique nonce values from single or few IP addresses
• OAuth signature validation failures paired with continued memory growth
• JupyterHub service degradation or crashes correlated with authentication endpoint activity

Detection Strategies

• Monitor memory usage trends on JupyterHub application servers for abnormal growth patterns
• Implement rate limiting on LTI authentication endpoints and alert on threshold breaches
• Log and analyze OAuth nonce usage patterns to identify suspicious request volumes
• Configure application performance monitoring to track dictionary or object size growth in the authenticator module

Monitoring Recommendations

• Set up alerts for memory utilization exceeding baseline thresholds on JupyterHub hosts
• Enable detailed logging for LTI authentication requests including source IP and nonce values
• Deploy network-level monitoring to detect unusual traffic patterns to authentication endpoints
• Regularly review authentication logs for signs of automated or scripted request patterns

How to Mitigate CVE-2026-34052

Immediate Actions Required

• Upgrade LTI JupyterHub Authenticator to version 1.6.3 or later immediately
• Implement network-level rate limiting on LTI authentication endpoints as a temporary measure
• Monitor memory consumption on affected servers until patches are applied
• Consider temporarily disabling LTI 1.1 authentication if upgrade cannot be performed promptly

Patch Information

The vulnerability has been addressed in LTI JupyterHub Authenticator version 1.6.3. Organizations should upgrade to this version or later to remediate the vulnerability. The patch release is available through the GitHub Release 1.6.3. Additional details about the vulnerability and remediation can be found in the GitHub Security Advisory GHSA-8mxq-7xr7-2fxj.

Workarounds

• Implement rate limiting at the web server or load balancer level to restrict authentication requests per source
• Configure memory limits for the JupyterHub process to prevent complete server resource exhaustion
• Deploy a reverse proxy with request filtering to block suspicious authentication patterns
• Restrict LTI consumer key access to only trusted and necessary integrations

# Configuration example - Nginx rate limiting for JupyterHub LTI endpoints
# Add to nginx configuration to limit authentication requests

limit_req_zone $binary_remote_addr zone=lti_auth:10m rate=10r/s;

location /hub/lti {
    limit_req zone=lti_auth burst=20 nodelay;
    limit_req_status 429;
    proxy_pass http://jupyterhub;
}