Jetty patches JASPI ThreadLocal auth context leak

TL;DR — A Jetty JASPI auth bug can leave per-request ThreadLocal state behind, letting a later request on the same thread inherit it and potentially gain unintended privileges.

What happened

Eclipse Jetty is a widely-embedded Java HTTP server and Servlet container used directly and as a transitive component in many Java stacks. CVE-2026-5795 describes a flaw in Jetty’s JASPIAuthenticator where authentication checks set two ThreadLocal variables, but some early-return paths fail to clear them. A subsequent request that reuses the same thread can inherit these values, resulting in broken access control and privilege escalation. (raw.githubusercontent.com)

Thread-/request-context confusion is a recurring failure mode in high-throughput servers: when “per-request” state accidentally becomes “per-thread,” auth guarantees can silently degrade under load and are hard to detect in typical unit/integration tests. (raw.githubusercontent.com)

Who is impacted

• Jetty deployments using the affected version ranges listed in the CVE record. (raw.githubusercontent.com)

• Higher-risk environments where request threads are reused heavily (typical in Jetty thread pools), because the vulnerability specifically depends on “a subsequent request using the same thread” inheriting leftover ThreadLocal state. (raw.githubusercontent.com)

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing (the CVE record does not explicitly list fixed versions). (raw.githubusercontent.com)
• Inventory where Jetty is present (direct dependency, shaded/embedded, app server bundle, container base image) and map running services to the affected version ranges.
• Identify where JASPI / JASPIAuthenticator is in use; prioritize upgrades for internet-facing services and auth-gateway / SSO-adjacent services.
• If you suspect exposure or anomalous auth behavior, review authentication and authorization logs for unexpected identity carry-over between requests (especially across different client sessions) and rotate credentials/tokens that would be high-impact if an elevated identity were incorrectly granted.