Jetty SSL buffer bloat denial of service (CVE-2021-28165)

A memory-exhaustion flaw in Eclipse Jetty's TLS handling can let a single remote attacker knock a production web server offline without ever completing a valid HTTP request. Tracked as CVE-2021-28165 and commonly referred to as the "Jetty SSL buffer bloat" vulnerability, the bug lives in how Jetty's SslConnection manages encrypted network buffers during the TLS handshake and data-transfer lifecycle. Under certain connection patterns, Jetty fails to release these buffers back to its pool, allowing an attacker to force unbounded buffer accumulation on the heap. The end result is a classic denial-of-service condition: garbage collection pressure spikes, available memory collapses, and the JVM either grinds to a halt or is killed outright by the OS — taking every application deployed on that Jetty instance down with it.

Because Jetty is embedded inside an enormous number of Java frameworks and platforms — Spring Boot's embedded server option, Eclipse itself, Google Cloud SDK components, Apache ActiveMQ, Alfresco, and countless internal microservices — this is not a niche server-admin problem. It's a supply chain problem. Most teams running a vulnerable Jetty version don't know it, because Jetty rarely appears as a top-level dependency; it's usually two or three levels deep in a transitive dependency tree, silently bundled by a framework or middleware library.

What Makes This Vulnerability Work

Jetty's SslConnection class sits between the raw network socket and the application-level HTTP handling, decrypting inbound TLS traffic and encrypting outbound traffic. To do this efficiently, it pulls ByteBuffer instances from a shared ByteBufferPool rather than allocating fresh memory for every read/write cycle — a standard and normally sound performance optimization.

The flaw is that under specific sequences of TLS renegotiation, connection resets, and partial writes, Jetty's internal accounting of buffer ownership breaks down. Buffers get acquired from the pool but never returned, effectively "leaking" outside the pool's control. Because the pool can't reclaim them, it keeps allocating new buffers to satisfy new connections, and the JVM's usable heap shrinks with every malicious or malformed connection attempt. An attacker doesn't need valid credentials, a crafted payload, or a special exploit chain — repeatedly opening and abnormally terminating TLS connections against the affected port is enough to trigger the leak. This is why the issue is described as "buffer bloat" rather than a traditional buffer overflow: nothing is being corrupted or overwritten, the server is simply being starved to death by its own memory-management bookkeeping.

Affected Versions and Components

According to the official Eclipse Jetty security advisory and the corresponding GitHub Security Advisory (GHSA-6bxc-3729-c8fq), the vulnerability spans a wide range of the Jetty 9, 10, and 11 branches:

• Jetty 9.x: versions 7.2.2 through 9.4.38 (the vulnerability was present far earlier in the codebase than most users assume, though it was formally tracked starting with more recent 9.x releases)
• Jetty 10.x: versions 10.0.0.alpha1 through 10.0.1
• Jetty 11.x: versions 11.0.0.alpha1 through 11.0.1

Fixed versions: Jetty 9.4.39, 10.0.2, and 11.0.2 resolve the issue by correcting buffer release logic in SslConnection and related connection-lifecycle handling.

The affected component is specifically the SSL/TLS connection layer, meaning any Jetty deployment terminating TLS directly — rather than behind a load balancer that terminates TLS upstream — is exposed. This includes standalone Jetty servers, Jetty used as an embedded HTTP server inside Java applications (a very common pattern with Spring Boot, Dropwizard, and custom microservice frameworks), and any product or appliance that bundles Jetty as its management console or API server.

CVSS, EPSS, and KEV Context

The vulnerability is rated in the High severity range, with a CVSS v3.1 base score in the neighborhood of 7.5, reflecting a network-exploitable (AV:N), low-complexity (AC:L), no-privileges-required (PR:N), no-user-interaction (UI:N) attack vector whose sole impact is availability (A:H) — confidentiality and integrity are not affected. This scoring profile is typical of resource-exhaustion CVEs: trivially reachable over the network, but limited to knocking a service offline rather than enabling data theft or code execution.

EPSS (Exploit Prediction Scoring System) data for CVE-2021-28165 places it at a comparatively low predicted exploitation probability relative to remote code execution or authentication-bypass CVEs published in the same window — consistent with the fact that DoS bugs, while disruptive, are less attractive to opportunistic mass-exploitation campaigns than vulnerabilities that yield footholds or data access. As of this writing, CVE-2021-28165 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, indicating no confirmed evidence of widespread in-the-wild exploitation. That said, EPSS and KEV status are not permission to deprioritize: availability-impacting bugs in internet-facing infrastructure remain a favored target for extortion-style DoS activity and "noisy" attackers probing for unpatched fleets, and KEV absence often reflects a lag in reporting rather than a lag in actual attacker interest.

Timeline

• Vulnerability introduced: Present in the Jetty codebase across multiple historical releases, tied to long-standing SslConnection buffer-management logic.
• 2021 (Q2): Vulnerability identified and reported to the Eclipse Jetty security team through the project's responsible disclosure process.
• June 2021: Eclipse Jetty published fixed releases — 9.4.39, 10.0.2, and 11.0.2 — alongside the security advisory and CVE-2021-28165 assignment.
• Post-disclosure: The CVE was ingested into the National Vulnerability Database (NVD) and mirrored across GitHub Security Advisories, OSS Index, and downstream Linux distribution security trackers, given how many packages transitively depend on Jetty.
• Ongoing: Because Jetty is frequently vendored inside other software (application servers, CI/CD tooling, monitoring agents), patch adoption has been uneven — security teams continue to find vulnerable Jetty versions during dependency audits years after the fix shipped, particularly in appliances and platforms that don't expose their embedded library versions clearly.

Remediation Steps

1. Inventory every Jetty instance, direct and transitive. Search build manifests (pom.xml, build.gradle), lockfiles, and container images for org.eclipse.jetty artifacts. Don't stop at direct dependencies — use mvn dependency:tree or gradle dependencies to surface Jetty pulled in transitively by frameworks like Spring Boot, Dropwizard, or vendor products.
2. Upgrade to a fixed release. Move to Jetty 9.4.39+ (for the 9.x line), 10.0.2+ (for 10.x), or 11.0.2+ (for 11.x). If you're on an end-of-life 9.4.x branch, plan a broader upgrade path since older 9.x releases eventually lose security support entirely.
3. Check embedded/vendored copies. If Jetty arrives bundled inside a third-party product (monitoring agents, CI servers, appliances, Java-based SaaS connectors), confirm with the vendor whether their shipped version is patched, and track their remediation timeline separately from your own code.
4. Apply network-layer mitigations as a stopgap. Where an immediate upgrade isn't feasible, terminate TLS at a hardened reverse proxy or load balancer in front of Jetty, and apply connection-rate limiting and idle-timeout tuning to reduce the blast radius of buffer-bloat attempts while the patch is scheduled.
5. Add memory and GC monitoring alerts. Configure alerting on heap utilization and GC pause frequency for Jetty-fronted services so that any residual buffer-management anomaly — from this CVE or a future one — triggers early warning before a full outage.
6. Re-scan after remediation. Confirm the fix with a fresh SBOM or dependency scan rather than relying on a build log; version pinning mistakes and transitive overrides are a common reason "fixed" services turn out to still ship the vulnerable class file.

How Safeguard Helps

Finding every copy of Jetty buried three dependency layers deep — and knowing which of your services actually terminate TLS through the vulnerable SslConnection path — is exactly the kind of noisy, manual work Safeguard is built to eliminate. Our SBOM generation and ingestion pipeline continuously maps every direct and transitive Jetty artifact across your codebases and container images, so CVE-2021-28165 exposure shows up as a single prioritized finding instead of a spreadsheet exercise. Reachability analysis then determines whether your application's code paths actually exercise the vulnerable SSL connection lifecycle, letting your team focus remediation effort on services that are genuinely exploitable rather than every instance where Jetty merely happens to be present. Griffin, Safeguard's AI-powered triage engine, correlates the CVSS, EPSS, and KEV signals covered above with your specific deployment context to tell you which Jetty findings deserve a same-day fix versus a routine patch cycle. And when it's time to act, Safeguard's auto-fix PRs open version bumps directly against your build files — targeting 9.4.39, 10.0.2, or 11.0.2 as appropriate — so remediation ships as a reviewable pull request instead of a manual dependency hunt.