GHSA-26vr-8j45-3r4w
HIGHJetty vulnerable to incorrect handling of invalid large TLS frame, exhausting CPU resources
Blast Radius
org.eclipse.jetty:jetty-server☕org.eclipse.jetty:jetty-server☕org.eclipse.jetty:jetty-serverReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Impact
When using SSL/TLS with Jetty, either with HTTP/1.1, HTTP/2, or WebSocket, the server may receive an invalid large (greater than 17408) TLS frame that is incorrectly handled, causing CPU resources to eventually reach 100% usage.
Workarounds
The problem can be worked around by compiling the following class:
package org.eclipse.jetty.server.ssl.fix6072;
import java.nio.ByteBuffer;
import javax.net.ssl.SSLEngine;
import javax.net.ssl.SSLEngineResult;
import javax.net.ssl.SSLException;
import javax.net.ssl.SSLHandshakeException;
import org.eclipse.jetty.io.EndPoint;
import org.eclipse.jetty.io.ssl.SslConnection;
import org.eclipse.jetty.server.Connector;
import org.eclipse.jetty.server.SslConnectionFactory;
import org.eclipse.jetty.util.BufferUtil;
import org.eclipse.jetty.util.annotation.Name;
import org.eclipse.jetty.util.ssl.SslContextFactory;
public class SpaceCheckingSslConnectionFactory extends SslConnectionFactory
{
public SpaceCheckingSslConnectionFactory(@Name("sslContextFactory") SslContextFactory factory, @Name("next") String nextProtocol)
{
super(factory, nextProtocol);
}
@Override
protected SslConnection newSslConnection(Connector connector, EndPoint endPoint, SSLEngine engine)
{
return new SslConnection(connector.getByteBufferPool(), connector.getExecutor(), endPoint, engine, isDirectBuffersForEncryption(), isDirectBuffersForDecryption())
{
@Override
protected SSLEngineResult unwrap(SSLEngine sslEngine, ByteBuffer input, ByteBuffer output) throws SSLException
{
SSLEngineResult results = super.unwrap(sslEngine, input, output);
if ((results.getStatus() == SSLEngineResult.Status.BUFFER_UNDERFLOW ||
results.getStatus() == SSLEngineResult.Status.OK && results.bytesConsumed() == 0 && results.bytesProduced() == 0) &&
BufferUtil.space(input) == 0)
{
BufferUtil.clear(input);
throw new SSLHandshakeException("Encrypted buffer max length exceeded");
}
return results;
}
};
}
}
This class can be deployed by:
- The resulting class file should be put into a jar file (eg sslfix6072.jar)
- The jar file should be made available to the server. For a normal distribution this can be done by putting the file into ${jetty.base}/lib
- Copy the file
${jetty.home}/modules/ssl.modto${jetty.base}/modules - Edit the
${jetty.base}/modules/ssl.modfile to have the following section:
[lib]
lib/sslfix6072.jar
- Copy the file
${jetty.home}/etc/jetty-https.xmland${jetty.home}/etc/jetty-http2.xmlto${jetty.base}/etc - Edit files
${jetty.base}/etc/jetty-https.xmland${jetty.base}/etc/jetty-http2.xml, changing any reference oforg.eclipse.jetty.server.SslConnectionFactorytoorg.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory. For example:
<Call name="addIfAbsentConnectionFactory">
<Arg>
<New class="org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory">
<Arg name="next">http/1.1</Arg>
<Arg name="sslContextFactory"><Ref refid="sslContextFactory"/></Arg>
</New>
</Arg>
</Call>
- Restart Jetty
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.eclipse.jetty:jetty-server | ≥ 7.2.2&&< 9.4.39 | 9.4.39 |
| ☕Maven | org.eclipse.jetty:jetty-server | ≥ 10.0.0&&< 10.0.2 | 10.0.2 |
| ☕Maven | org.eclipse.jetty:jetty-server | ≥ 11.0.0&&< 11.0.2 | 11.0.2 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.eclipse.jetty:jetty-server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.eclipse.jetty:jetty-server to 9.4.39 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-26vr-8j45-3r4w is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-26vr-8j45-3r4w is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-26vr-8j45-3r4w. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-26vr-8j45-3r4w in your dependencies?
O3 detects GHSA-26vr-8j45-3r4w across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.