Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
29 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact The original report: Server handling of 100-Continue requests can lead to memory leak that can be abused to cause a Denial of Service state. After investigation, turns out that every request that has a body, but reading the body may end up in reading 0 bytes, leaks a buffer. This is particularly the case for 100-Continue, but any request where the network is slow can leak. Affected Versions Jetty 11.0.0-11.0.22 (EOL) Jetty 10.0.0-10.0.22 (EOL) Patched Versions Jetty 11.0.23 Jetty 10.0.23 Patches https://github.com/jetty/jetty.project/pull/12156 Workarounds No workarounds.
Recommended action: Upgrade to 11.0.23 or 10.0.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jetty currently accepts HTTP/2 and HTTP/3 requests where the regular Host header and the pseudo-header :authority do not match. As a result, the same request can carry two different host identities through Jetty: - logic based on HttpURI / Request.getServerName(request) uses :authority - logic based on raw request headers continues to use Host This creates a host/authority confusion condition that can break security assumptions in higher layers. Jetty already performs an explicit authority/Host consistency check on the HTTP/1.1 path, but equivalent validation is missing on the HTTP/2 and HTTP/3 paths. Security Impact This issue is not inherently remote code execution, but it can become security-relevant in deployments that rely on the request host for security-sensitive decisions, including: - host-based access control - virtual host isolation - multi-tenant routing by hostname - login/logout/callback URL construction - reverse proxy and forwarded-header trust chains -…
Recommended action: Upgrade to 12.1.9 or 12.0.35 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FINDING — MEDIUM (HTTP/1.1 keep-alive connections with trailers) HttpConnection.trailers Cross-Request Leakage (Never Reset Between Requests) Location: jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/ HttpConnection.java:107, 1157-1161, 1170 Detail: trailers (line 107) is a connection-scoped HttpFields.Mutable field. parsedTrailer() (line 1157) populates it when request N carries HTTP trailers. messageComplete() (line 1170) checks "if (trailers != null)" — evaluates true from request N's data — and stamps it onto request N+1. Grep confirms: ZERO occurrences of "trailers = null" in entire HttpConnection.java. Scenario: Request N: POST /upload (trailers: X-Checksum: abc123) Request N+1: GET /data (no trailers) app: request.getTrailers() on N+1 → returns {X-Checksum: abc123} ← STALE Application logic branching on getTrailers() != null produces incorrect behavior. Not cross-connection (same keep-alive connection only). More dangerous scenario: TOCTOU —…
Recommended action: Upgrade to 12.1.10 or 12.0.36 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(as reported) There is a memory leak when using GzipHandler in jetty-12.0.30 that can cause off-heap OOMs. This can be used for DoS attacks so I'm reporting this as a vulnerability. The leak is created by requests where the request is inflated (Content-Encoding: gzip) and the response is not deflated (no Accept-Encoding: gzip). In these conditions, a new inflator will be created by GzipRequest and never released back into GzipRequest.inflaterPool because gzipRequest.destory() is not called. In heap dumps one can see thousands of java.util.zip.Inflator objects, which use both Java heaps and native memory. Leaking native memory causes of off-heap OOMs. Code path in GzipHandler.handle(): 1. Line 601: GzipRequest is created when request inflation is needed. 2. Lines 611-616: The callback is only wrapped in GzipResponseAndCallback when both inflation and deflation are needed. 3. Lines 619-625: If the handler accepts the request (returns true), gzipRequest.destroy() is only…
Recommended action: Upgrade to 12.1.6 or 12.0.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests.
Recommended action: Upgrade to 9.4.57.v20241219 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Remote DOS attack can cause out of memory Description There exists a security vulnerability in Jetty's ThreadLimitHandler.getRemote() which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory. Affected Versions Jetty 12.0.0-12.0.8 (Supported) Jetty 11.0.0-11.0.23 (EOL) Jetty 10.0.0-10.0.23 (EOL) Jetty 9.3.12-9.4.55 (EOL) Patched Versions Jetty 12.0.9 Jetty 11.0.24 Jetty 10.0.24 Jetty 9.4.56 Workarounds Do not use ThreadLimitHandler. Consider use of QoSHandler instead to artificially limit resource utilization. References Jetty 12 - https://github.com/jetty/jetty.project/pull/11723
Recommended action: Upgrade to 12.0.9, 11.0.24, 10.0.24 or 9.4.56 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
11.0.149.4.51.v2023021710.0.14· Vendor fix available
Issue
Impact Servlets with multipart support (e.g. annotated with @MultipartConfig) that call HttpServletRequest.getParameter() or HttpServletRequest.getParts() may cause OutOfMemoryError when the client sends a multipart request with a part that has a name but no filename and a very large content. This happens even with the default settings of fileSizeThreshold=0 which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw OutOfMemoryError. However, the server may be able to recover after the OutOfMemoryError and continue its service -- although it may take some time. A very large number of parts may cause the same problem. Patches Patched in Jetty versions 9.4.51.v20230217 - via PR #9345 10.0.14 - via PR #9344 11.0.14 - via PR #9344 Workarounds Multipart parameter maxRequestSize must be set to a non-negative value, so the whole multipart content is limited (although still read into memory). Limiting multipart…
Recommended action: Upgrade to 11.0.14, 10.0.14 or 9.4.51.v20230217 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
11.0.1412.0.0.beta09.4.51.v2023021710.0.14· Vendor fix available
Issue
Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with " (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: DISPLAYLANGUAGE="b; JSESSIONID=1337; c=d" will be parsed as one cookie, with the name DISPLAYLANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. Impact This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAYLANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAYLANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server. Patches…
Recommended action: Upgrade to 12.0.0.beta0, 11.0.14, 10.0.14 or 9.4.51.v20230217 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact SslConnection does not release ByteBuffers in case of error code paths. For example, TLS handshakes that require client-auth with clients that send expired certificates will trigger a TLS handshake errors and the ByteBuffers used to process the TLS handshake will be leaked. Workarounds Configure explicitly a RetainableByteBufferPool with max[Heap|Direct]Memory to limit the amount of memory that is leaked. Eventually the pool will be full of "active" entries (the leaked ones) and will provide ByteBuffers that will be GCed normally. With embedded-jetty With jetty-home/jetty-base Create a ${jetty.base}/etc/retainable-byte-buffer-config.xml And then reference it in ${jetty.base}/start.d/retainable-byte-buffer-config.ini References https://github.com/eclipse/jetty.project/issues/8161 For more information Email us at security@webtide.com
Recommended action: Upgrade to 11.0.10 or 10.0.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jetty 8.1.0.RC2 and earlier computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters.
Recommended action: Upgrade to 8.1.0.RC4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jetty before 4.2.27, 5.1 before 5.1.12, 6.0 before 6.0.2, and 6.1 before 6.1.0pre3 generates predictable session identifiers using java.util.random, which makes it easier for remote attackers to guess a session identifier through brute force attacks, bypass authentication requirements, and possibly conduct cross-site request forgery attacks.
Recommended action: Upgrade to 6.1.0pre3 (pre-release), 6.0.2, 5.1.12 or 4.2.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If an exception is thrown from the SessionListener#sessionDestroyed() method, then the session ID is not invalidated in the session ID manager. On deployments with clustered sessions and multiple contexts this can result in a session not being invalidated. This can result in an application used on a shared computer being left logged in. There is no known path for an attacker to induce such an exception to be thrown, thus they must rely on an application to throw such an exception. The OP has also identified that during the call to sessionDestroyed, the getLastAccessedTime() throws an IllegalStateException, which potentially contrary to the servlet spec, so applications calling this method may always throw and fail to log out. If such an application was only tested on a non clustered test environment, then it may be deployed on a clustered environment with multiple contexts and fail to log out. Workarounds The application should catch all Throwables within their…
Recommended action: Upgrade to 11.0.3, 10.0.3 or 9.4.41 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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.mod to ${jetty.base}/modules + Edit the ${jetty.base}/modules/ssl.mod file to have the following section: + Copy the file ${jetty.home}/etc/jetty-https.xml and${jetty.home}/etc/jetty-http2.xml to ${jetty.base}/etc + Edit files ${jetty.base}/etc/jetty-https.xml and ${jetty.base}/etc/jetty-http2.xml, changing any reference of org.eclipse.jetty.server.SslConnectionFactory to…
Recommended action: Upgrade to 11.0.2, 10.0.2 or 9.4.39 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When Jetty handles a request containing request headers with a large number of “quality” (i.e. q) parameters (such as what are seen on the Accept, Accept-Encoding, and Accept-Language request headers), the server may enter a denial of service (DoS) state due to high CPU usage while sorting the list of values based on their quality values. A single request can easily consume minutes of CPU time before it is even dispatched to the application. The only features within Jetty that can trigger this behavior are: - Default Error Handling - the Accept request header with the QuotedQualityCSV is used to determine what kind of content to send back to the client (html, text, json, xml, etc) - StatisticsServlet - uses the Accept request header with the QuotedQualityCSV to determine what kind of content to send back to the client (xml, json, text, html, etc) - HttpServletRequest.getLocale() - uses the Accept-Language request header with the QuotedQualityCSV to determine which “preferred”…
Recommended action: Upgrade to 11.0.1, 10.0.1 or 9.4.37 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection and if an attacker can send a request with a body that is received entirely by not consumed by the application, then a subsequent request on the same connection will see that body prepended to it's body. The attacker will not see any data, but may inject data into the body of the subsequent request CVE score is 4.8 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L Workarounds The problem can be worked around by either: - Disabling compressed request body inflation by GzipHandler. - By always fully consuming the request content before sending a response. - By adding a Connection: close to any response where the servlet does not fully consume request content.
Recommended action: Upgrade to 9.4.35.v20201120 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with response2 data. Thread1 then proceeds to write the buffer that now contains response2 data. This results in client1, which issued request1 and expects responses, to see response2 which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.).
Recommended action: Upgrade to 9.4.30.v20200611 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Eclipse Jetty versions 9.4.21.v20190926, 9.4.22.v20191022, and 9.4.23.v20191118, the generation of default unhandled Error response content (in text/html and text/json Content-Type) does not escape Exception messages in stacktraces included in error output.
Recommended action: Upgrade to 9.4.24.v20191120 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
9.2.28.v201904189.3.27.v201904189.4.17.v20190418· Vendor fix available
Issue
In Eclipse Jetty version 9.2.27, 9.3.26, and 9.4.16, the server running on Windows is vulnerable to exposure of the fully qualified Base Resource directory name on Windows to a remote client when it is configured for showing a Listing of directory contents. This information reveal is restricted to only the content in the configured base resource directories.
Recommended action: Upgrade to 9.4.17.v20190418, 9.3.27.v20190418 or 9.2.28.v20190418 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
9.2.28.v201904189.3.27.v201904189.4.17.v20190418· Vendor fix available
Issue
In Eclipse Jetty version 7.x, 8.x, 9.2.27 and older, 9.3.26 and older, and 9.4.16 and older, the server running on any OS and Jetty version combination will reveal the configured fully qualified directory base resource location on the output of the 404 error for not finding a Context that matches the requested path. The default server behavior on jetty-distribution and jetty-home will include at the end of the Handler tree a DefaultHandler, which is responsible for reporting this 404 error, it presents the various configured contexts as HTML for users to click through to. This produced HTML includes output that contains the configured fully qualified directory base resource location for each context.
Recommended action: Upgrade to 9.4.17.v20190418, 9.3.27.v20190418 or 9.2.28.v20190418 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
9.3.26.v201904039.4.16.v201904119.2.27.v20190403· Vendor fix available
Issue
In Eclipse Jetty version 9.2.26 and older, 9.3.25 and older, and 9.4.15 and older, the server is vulnerable to XSS conditions if a remote client USES a specially formatted URL against the DefaultServlet or ResourceHandler that is configured for showing a Listing of directory contents.
Recommended action: Upgrade to 9.4.16.v20190411, 9.3.26.v20190403 or 9.2.27.v20190403 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
9.3.25.v201809049.4.12.v20180830· Vendor fix available
Issue
In Eclipse Jetty version 9.3.x and 9.4.x, the server is vulnerable to Denial of Service conditions if a remote client sends either large SETTINGs frames container containing many settings, or many small SETTINGs frames. The vulnerability is due to the additional CPU and memory allocations required to handle changed settings.
Recommended action: Upgrade to 9.4.12.v20180830 or 9.3.25.v20180904 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The exception handling code in Eclipse Jetty prior to 9.2.9.v20150224 allows remote attackers to obtain sensitive information from process memory via illegal characters in an HTTP header, aka JetLeak.
Recommended action: Upgrade to 9.2.9.v20150224 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
9.4.11.v201806059.2.25.v201806069.3.24.v20180605· Vendor fix available
Issue
Eclipse Jetty Server versions 9.2.x and older, 9.3.x (all non HTTP/1.x configurations), and 9.4.x (all HTTP/1.x configurations), are vulnerable to HTTP Request Smuggling when presented with two content-lengths headers, allowing authorization bypass. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decides on the shorter length, but still passes on the longer body, then body content could be interpreted by Jetty as a pipelined request. If the intermediary is imposing authorization, the fake pipelined request bypasses that authorization.
Recommended action: Upgrade to 9.4.11.v20180605, 9.3.24.v20180605 or 9.2.25.v20180606 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
9.4.11.v201806059.3.24.v20180605· Vendor fix available
Issue
Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), contain an HTTP Request Smuggling Vulnerability that can result in cache poisoning.
Recommended action: Upgrade to 9.4.11.v20180605 or 9.3.24.v20180605 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The path normalization mechanism in PathResource class in Eclipse Jetty 9.3.x before 9.3.9 on Windows allows remote attackers to bypass protected resource restrictions and other security constraints via a URL with certain escaped characters, related to backslashes.
Recommended action: Upgrade to 9.3.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.