Search for packages
| purl | pkg:maven/org.eclipse.jetty/jetty-server@9.4.38.v20210224 |
| Next non-vulnerable version | 9.4.57.v20241219 |
| Latest non-vulnerable version | 12.1.6 |
| Risk | 4.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-9xw3-4a4u-hbbb
Aliases: CVE-2023-26049 GHSA-p26g-97m4-6q7c |
Exposure of Sensitive Information to an Unauthorized Actor Jetty is a java based web server and servlet engine. 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: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE 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 or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue. |
Affected by 2 other vulnerabilities. Affected by 1 other vulnerability. Affected by 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-kx4x-gnk4-yugu
Aliases: CVE-2024-13009 GHSA-q4rv-gq96-w7c5 |
**UNSUPPORTED WHEN ASSIGNED** GzipHandler causes part of request body to be seen as request body of a separate request 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. |
Affected by 0 other vulnerabilities. |
|
VCID-kxtv-ma18-8fer
Aliases: CVE-2021-28163 GHSA-j6qj-j888-vvgq |
Directory exposure in jetty ### Impact If the `${jetty.base}` directory or the `${jetty.base}/webapps` directory is a symlink (soft link in Linux), the contents of the `${jetty.base}/webapps` directory may be deployed as a static web application, exposing the content of the directory for download. For example, the problem manifests in the following `${jetty.base}`: ```$ tree demo-base/ demo-base/ ├── etc ├── lib ├── resources ├── start.d ├── deploy │ └── async-rest.war └── webapps -> deploy ``` ### Workarounds Do not use a symlink |
Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-prd3-mmuv-n3dc
Aliases: CVE-2021-28165 GHSA-26vr-8j45-3r4w |
Jetty vulnerable to incorrect handling of invalid large TLS frame, exhausting CPU resources ### 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: ```java 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.mod` to `${jetty.base}/modules` + Edit the `${jetty.base}/modules/ssl.mod` file to have the following section: ``` [lib] lib/sslfix6072.jar ``` + 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 `org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory`. For example: ```xml <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 by 0 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-q35p-8qhp-aqec
Aliases: CVE-2021-34428 GHSA-m6cp-vxjx-65j6 |
SessionListener can prevent a session from being invalidated breaking logout ### 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 `SessionListener#sessionDestroyed()` implementations. |
Affected by 4 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 4 other vulnerabilities. Affected by 4 other vulnerabilities. |
|
VCID-q3k2-1x5q-buhy
Aliases: CVE-2023-40167 GHSA-hmr7-m48g-48f6 |
Improper Handling of Length Parameter Inconsistency Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario. |
Affected by 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-y3mv-vmwd-tydt
Aliases: CVE-2023-26048 GHSA-qw69-rqj8-6qw8 |
False positive This vulnerability has been marked as a false positive. |
Affected by 2 other vulnerabilities. Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-p7cu-h519-83hx | Authorization Before Parsing and Canonicalization in jetty Release 9.4.37 introduced a more precise implementation of [RFC3986](https://tools.ietf.org/html/rfc3986#section-3.3) with regards to URI decoding, together with some new compliance modes to optionally allow support of some URI that may have ambiguous interpretation within the Servlet specified API methods behaviours. The default mode allowed % encoded . characters to be excluded for URI normalisation, which is correct by the RFC, but is not assumed by common Servlet implementations. The default compliance mode allows requests with URIs that contain `%2e` or `%2e%2e` segments to access protected resources within the `WEB-INF` directory. For example a request to `/context/%2e/WEB-INF/web.xml` can retrieve the `web.xml` file. This can reveal sensitive information regarding the implementation of a web application. Workarounds found by HttpCompliance mode RFC7230_NO_AMBIGUOUS_URIS can be enabled by updating `start.d/http.ini` to include: jetty.http.compliance=RFC7230_NO_AMBIGUOUS_URIS. |
CVE-2021-28164
GHSA-v7ff-8wcx-gmc5 |