Search for packages
| purl | pkg:deb/debian/jetty9@9.2.21-1%2Bdeb9u1 |
| Next non-vulnerable version | 9.4.57-1.1~deb12u1 |
| Latest non-vulnerable version | 9.4.57-1.1~deb12u1 |
| Risk | 10.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-12gq-ezut-ckhz
Aliases: CVE-2017-7657 GHSA-vgg8-72f2-qm23 |
Affected by 28 other vulnerabilities. |
|
|
VCID-1ejr-3tea-kydr
Aliases: CVE-2024-6762 GHSA-r7m4-f9h5-gr79 |
Eclipse Jetty's PushSessionCacheFilter can cause remote DoS attacks ### Impact Jetty PushSessionCacheFilter can be exploited by unauthenticated users to launch remote DoS attacks by exhausting the server’s memory. ### Patches * https://github.com/jetty/jetty.project/pull/9715 * https://github.com/jetty/jetty.project/pull/9716 ### Workarounds The session usage is intrinsic to the design of the PushCacheFilter. The issue can be avoided by: + not using the PushCacheFilter. Push has been deprecated by the various IETF specs and early hints responses should be used instead. + reducing the reducing the idle timeout on unauthenticated sessions will reduce the time such session stay in memory. + configuring a session cache to use [session passivation](https://jetty.org/docs/jetty/12/programming-guide/server/session.html), so that sessions are not stored in memory, but rather in a database or file system that may have significantly more capacity than memory. ### References * https://github.com/jetty/jetty.project/pull/10756 * https://github.com/jetty/jetty.project/pull/10755 |
Affected by 0 other vulnerabilities. |
|
VCID-3f6t-fkt7-wub9
Aliases: CVE-2021-34429 GHSA-vjv5-gp2w-65vm |
Information Exposure For Eclipse Jetty, URIs can be crafted using some encoded characters to access the content of the WEB-INF directory and/or bypass some security constraints. This is a variation of the vulnerability reported in CVE-2021-28164. |
Affected by 5 other vulnerabilities. |
|
VCID-5781-s1ny-q7ey
Aliases: CVE-2023-44487 GHSA-2m7v-gc89-fjqf GHSA-qppj-fm5r-hxr3 GHSA-vx74-f528-fxqg GHSA-xpw8-rcwv-8f8p GMS-2023-3377 VSV00013 |
Affected by 5 other vulnerabilities. |
|
|
VCID-5qhm-ase5-5qhy
Aliases: CVE-2024-22201 GHSA-rggv-cv7r-mw98 |
Connection leaking on idle timeout when TCP congested ### Impact If an HTTP/2 connection gets TCP congested, when an idle timeout occurs the HTTP/2 session is marked as closed, and then a GOAWAY frame is queued to be written. However it is not written because the connection is TCP congested. When another idle timeout period elapses, it is then supposed to hard close the connection, but it delegates to the HTTP/2 session which reports that it has already been closed so it does not attempt to hard close the connection. This leaves the connection in ESTABLISHED state (i.e. not closed), TCP congested, and idle. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The client may also be impacted (if the server does not read causing a TCP congestion), but the issue is more severe for servers. ### Patches Patched versions: * 9.4.54 * 10.0.20 * 11.0.20 * 12.0.6 ### Workarounds Disable HTTP/2 and HTTP/3 support until you can upgrade to a patched version of Jetty. HTTP/1.x is not affected. ### References * https://github.com/jetty/jetty.project/issues/11256. |
Affected by 5 other vulnerabilities. |
|
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 5 other vulnerabilities. |
|
VCID-ahev-zdjd-gqg1
Aliases: CVE-2019-10241 GHSA-7vx9-xjhr-rw6h |
Cross-site Scripting Jetty 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. |
Affected by 28 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-czhb-gqt2-17av
Aliases: CVE-2019-10247 GHSA-xc67-hjx6-cgg6 |
Information Exposure In Eclipse Jetty, 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 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 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. |
Affected by 28 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-dvyn-8phs-a3a6
Aliases: CVE-2022-2048 GHSA-wgmr-mf83-7x4j |
Jetty vulnerable to Invalid HTTP/2 requests that can lead to denial of service ### Description Invalid HTTP/2 requests (for example, invalid URIs) are incorrectly handled by writing a blocking error response directly from the selector thread. If the client manages to exhaust the HTTP/2 flow control window, or TCP congest the connection, the selector thread will be blocked trying to write the error response. If this is repeated for all the selector threads, the server becomes unresponsive, causing the denial of service. ### Impact A malicious client may render the server unresponsive. ### Patches The fix is available in Jetty versions 9.4.47. 10.0.10, 11.0.10. ### Workarounds No workaround available within Jetty itself. One possible workaround is to filter the requests before sending them to Jetty (for example in a proxy) ### For more information If you have any questions or comments about this advisory: * Email us at security@webtide.com. |
Affected by 5 other vulnerabilities. |
|
VCID-dznb-x27e-kqan
Aliases: CVE-2017-9735 GHSA-wfcc-pff6-rgc5 |
Jetty through 9.4.x is prone to a timing channel in util/security/Password.java, which makes it easier for remote attackers to obtain access by observing elapsed times before rejection of incorrect passwords. |
Affected by 32 other vulnerabilities. |
|
VCID-g3ff-brt6-vkeh
Aliases: CVE-2021-28169 GHSA-gwcr-j4wh-j3cq |
Jetty Utility Servlets ConcatServlet Double Decoding Information Disclosure Vulnerability Requests to the `ConcatServlet` and `WelcomeFilter` are able to access protected resources within the `WEB-INF` directory. For example a request to the `ConcatServlet` with a URI of `/concat?/%2557EB-INF/web.xml` can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application. This occurs because both `ConcatServlet` and `WelcomeFilter` decode the supplied path to verify it is not within the `WEB-INF` or `META-INF` directories. It then uses this decoded path to call `RequestDispatcher` which will also do decoding of the path. This double decoding allows paths with a doubly encoded `WEB-INF` to bypass this security check. ### Impact This affects all versions of `ConcatServlet` and `WelcomeFilter` in versions before 9.4.41, 10.0.3 and 11.0.3. ### Workarounds If you cannot update to the latest version of Jetty, you can instead deploy your own version of the [`ConcatServlet`](https://github.com/eclipse/jetty.project/blob/4204526d2fdad355e233f6bf18a44bfe028ee00b/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/ConcatServlet.java) and/or the [`WelcomeFilter`](https://github.com/eclipse/jetty.project/blob/4204526d2fdad355e233f6bf18a44bfe028ee00b/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/WelcomeFilter.java) by using the code from the latest version of Jetty. |
Affected by 28 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-gdcf-9axf-1yaq
Aliases: CVE-2025-5115 GHSA-mmxm-8w33-wc4h |
Eclipse Jetty affected by MadeYouReset HTTP/2 vulnerability ## Technical Details Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” ### MadeYouReset Vulnerability Summary The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. ### Mechanism The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: 1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) 2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) 3. PRIORITY frame with a length other than 5. (section 6.3) From our experience, the primitives are likely to exist in the decreasing order listed above. Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. ### Attack Flow For example, a possible attack scenario can be: 1. Attacker opens an HTTP/2 connection to the server. 2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. 3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. 4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependant) ### Comparison to Rapid Reset The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. ### Suggested Mitigations for MadeYouReset A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. If you have any questions, we will be happy to clarify or schedule a Zoom call. Gal, Anat and Yaniv. ## Jetty's Team Notes ### Impact A denial of service vulnerability similar to [Rapid Reset](https://github.com/jetty/jetty.project/security/advisories/GHSA-c745-7wm4-7738), but where the client triggers a reset from the server by sending a malformed or invalid frame. In particular, this may be triggered by WINDOW_UPDATE frames that are invalid (e.g. with `delta==0` or when the delta makes the window exceed `2^31-1`). ### Patches Patch has been merged into 12.0.x mainline via https://github.com/jetty/jetty.project/pull/13449. ### Workarounds No workarounds apart disabling HTTP/2. |
Affected by 0 other vulnerabilities. |
|
VCID-gq93-ctd4-aqbp
Aliases: CVE-2024-8184 GHSA-g8m5-722r-8whq |
Eclipse Jetty's ThreadLimitHandler.getRemote() vulnerable to remote DoS attacks ### 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 |
Affected by 0 other vulnerabilities. |
|
VCID-kvqz-fppe-d7fe
Aliases: CVE-2017-7658 GHSA-6x9x-8qw9-9pp6 |
Affected by 28 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. |
|
VCID-memq-11qz-9qem
Aliases: CVE-2024-9823 GHSA-j26w-f9rq-mr2q |
Eclipse Jetty has a denial of service vulnerability on DosFilter Description There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. Vulnerability details The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. Impact Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. Patches The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. Patched releases: * 9.4.54 * 10.0.18 * 11.0.18 * 12.0.3 |
Affected by 0 other vulnerabilities. |
|
VCID-nubz-xqaw-tkfr
Aliases: CVE-2020-27216 GHSA-g3wg-6mcf-8jj6 |
Local Temp Directory Hijacking Vulnerability ### Impact On Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability. Additionally, any user code uses of [WebAppContext::getTempDirectory](https://www.eclipse.org/jetty/javadoc/9.4.31.v20200723/org/eclipse/jetty/webapp/WebAppContext.html#getTempDirectory()) would similarly be vulnerable. Additionally, any user application code using the `ServletContext` attribute for the tempdir will also be impacted. See: https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletContext.html#TEMPDIR For example: ```java import java.io.File; import java.io.IOException; import javax.servlet.ServletContext; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class ExampleServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { File tempDir = (File)getServletContext().getAttribute(ServletContext.TEMPDIR); // Potentially compromised // do something with that temp dir } } ``` Example: The JSP library itself will use the container temp directory for compiling the JSP source into Java classes before executing them. ### CVSSv3.1 Evaluation This vulnerability has been calculated to have a [CVSSv3.1 score of 7.8/10 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H&version=3.1) ### Patches Fixes were applied to the 9.4.x branch with: - https://github.com/eclipse/jetty.project/commit/53e0e0e9b25a6309bf24ee3b10984f4145701edb - https://github.com/eclipse/jetty.project/commit/9ad6beb80543b392c91653f6bfce233fc75b9d5f These will be included in releases: 9.4.33, 10.0.0.beta3, 11.0.0.beta3 ### Workarounds A work around is to set a temporary directory, either for the server or the context, to a directory outside of the shared temporary file system. For recent releases, a temporary directory can be created simple by creating a directory called `work` in the ${jetty.base} directory (the parent directory of the `webapps` directory). Alternately the java temporary directory can be set with the System Property `java.io.tmpdir`. A more detailed description of how jetty selects a temporary directory is below. The Jetty search order for finding a temporary directory is as follows: 1. If the [`WebAppContext` has a temp directory specified](https://www.eclipse.org/jetty/javadoc/current/org/eclipse/jetty/webapp/WebAppContext.html#setTempDirectory(java.io.File)), use it. 2. If the `ServletContext` has the `javax.servlet.context.tempdir` attribute set, and if directory exists, use it. 3. If a `${jetty.base}/work` directory exists, use it (since Jetty 9.1) 4. If a `ServletContext` has the `org.eclipse.jetty.webapp.basetempdir` attribute set, and if the directory exists, use it. 5. Use `System.getProperty("java.io.tmpdir")` and use it. Jetty will end traversal at the first successful step. To mitigate this vulnerability the directory must be set to one that is not writable by an attacker. To avoid information leakage, the directory should also not be readable by an attacker. #### Setting a Jetty server temporary directory. Choices 3 and 5 apply to the server level, and will impact all deployed webapps on the server. For choice 3 just create that work directory underneath your `${jetty.base}` and restart Jetty. For choice 5, just specify your own `java.io.tmpdir` when you start the JVM for Jetty. ``` shell [jetty-distribution]$ java -Djava.io.tmpdir=/var/web/work -jar start.jar ``` #### Setting a Context specific temporary directory. The rest of the choices require you to configure the context for that deployed webapp (seen as `${jetty.base}/webapps/<context>.xml`) Example (excluding the DTD which is version specific): ``` xml <Configure class="org.eclipse.jetty.webapp.WebAppContext"> <Set name="contextPath"><Property name="foo"/></Set> <Set name="war">/var/web/webapps/foo.war</Set> <Set name="tempDirectory">/var/web/work/foo</Set> </Configure> ``` ### References - https://github.com/eclipse/jetty.project/issues/5451 - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - [CodeQL Query PR To Detect Similar Vulnerabilities](https://github.com/github/codeql/pull/4473) ### Similar Vulnerabilities Similar, but not the same. - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - Google Guava - https://github.com/google/guava/issues/4011 - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 ### For more information The original report of this vulnerability is below: > On Thu, 15 Oct 2020 at 21:14, Jonathan Leitschuh <jonathan.leitschuh@gmail.com> wrote: > Hi WebTide Security Team, > > I'm a security researcher writing some custom CodeQL queries to find Local Temporary Directory Hijacking Vulnerabilities. One of my queries flagged an issue in Jetty. > > https://lgtm.com/query/5615014766184643449/ > > I've recently been looking into security vulnerabilities involving the temporary directory because on unix-like systems, the system temporary directory is shared between all users. > There exists a race condition between the deletion of the temporary file and the creation of the directory. > > ```java > // ensure file will always be unique by appending random digits > tmpDir = File.createTempFile(temp, ".dir", parent); // Attacker knows the full path of the file that will be generated > // delete the file that was created > tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty. > // and make a directory of the same name > // SECURITY VULNERABILITY: Race Condition! - Attacker beats Jetty and now owns this directory > tmpDir.mkdirs(); > ``` > > https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L511-L518 > > In several cases the `parent` parameter will not be the system temporary directory. However, there is one case where it will be, as the last fallback. > > > https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L467-L468 > > If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability. > > Would your team be willing to open a GitHub security advisory to continue the discussion and disclosure there? https://github.com/eclipse/jetty.project/security/advisories > > **This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.** > > Cheers, > Jonathan Leitschuh |
Affected by 28 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-nyxu-ekhs-gyb5
Aliases: CVE-2020-27218 GHSA-86wm-rrjm-8wh8 |
Buffer not correctly recycled in Gzip Request inflation ### 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](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L&version=3.1) ### 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. |
Affected by 5 other vulnerabilities. |
|
VCID-p7cu-h519-83hx
Aliases: CVE-2021-28164 GHSA-v7ff-8wcx-gmc5 |
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. |
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 28 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 28 other vulnerabilities. Affected by 5 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 5 other vulnerabilities. |
|
VCID-rpc4-u4aq-4qde
Aliases: CVE-2023-41900 GHSA-pwh8-58vv-vw48 |
Jetty's OpenId Revoked authentication allows one request If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. |
Affected by 5 other vulnerabilities. |
|
VCID-sw3q-jzqx-dkbn
Aliases: CVE-2019-17638 GHSA-x3rh-m7vp-35f2 |
Operation on a Resource after Expiration or Release in Jetty Server 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.). |
Affected by 5 other vulnerabilities. |
|
VCID-thpu-76e5-j3d3
Aliases: CVE-2023-36479 GHSA-3gh6-v5v9-6v9j |
Jetty vulnerable to errant command quoting in CGI Servlet If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. ```java if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) execCmd = "\"" + execCmd + "\""; ``` |
Affected by 5 other vulnerabilities. |
|
VCID-tqm9-4ch7-s7b3
Aliases: CVE-2022-2047 GHSA-cj7v-27pg-wf7q |
Jetty invalid URI parsing may produce invalid HttpURI.authority ### Description URI use within Jetty's `HttpURI` class can parse invalid URIs such as `http://localhost;/path` as having an authority with a host of `localhost;`. A URIs of the type `http://localhost;/path` should be interpreted to be either invalid or as `localhost;` to be the userinfo and no host. However, `HttpURI.host` returns `localhost;` which is definitely wrong. ### Impact This can lead to errors with Jetty's `HttpClient`, and Jetty's `ProxyServlet` / `AsyncProxyServlet` / `AsyncMiddleManServlet` wrongly interpreting an authority with no host as one with a host. ### Patches Patched in PR [#8146](https://github.com/eclipse/jetty.project/pull/8146) for Jetty version 9.4.47. Patched in PR [#8014](https://github.com/eclipse/jetty.project/pull/8015) for Jetty versions 10.0.10, and 11.0.10 ### Workarounds None. ### For more information If you have any questions or comments about this advisory: * Email us at security@webtide.com. |
Affected by 5 other vulnerabilities. |
|
VCID-u2b5-uyd6-fbh9
Aliases: CVE-2018-12536 GHSA-9rgv-h7x4-qw8g |
In Eclipse Jetty Server, all 9.x versions, on webapps deployed using default Error Handling, when an intentionally bad query arrives that doesn't match a dynamic url-pattern, and is eventually handled by the DefaultServlet's static file serving, the bad characters can trigger a java.nio.file.InvalidPathException which includes the full path to the base resource directory that the DefaultServlet and/or webapp is using. If this InvalidPathException is then handled by the default Error Handler, the InvalidPathException message is included in the error response, revealing the full server path to the requesting system. |
Affected by 28 other vulnerabilities. |
|
VCID-uuju-ey95-tyfq
Aliases: CVE-2020-27223 GHSA-m394-8rww-3jr7 |
DOS vulnerability for Quoted Quality CSV headers ### 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” language is returned on this call. - `HttpservletRequest.getLocales()` - is similar to the above, but returns an ordered list of locales based on the quality values on the `Accept-Language` request header. - `DefaultServlet` - uses the `Accept-Encoding` request header with the `QuotedQualityCSV` to determine which kind of pre-compressed content should be sent back for static content (content that is not matched against a url-pattern in your web app) ### Versions `QuotedQualityCSV` was introduced to Jetty 9.3.9.v20160517 and the bug that introduced the vulnerability was in 9.4.6.v20170531. Currently, known vulnerable versions include: - 9.4.6.v20170531 thru to 9.4.36.v20210114 - 10.0.0 - 11.0.0 ### Workarounds Quality ordered values are used infrequently by jetty so they can be avoided by: * Do not use the default error page/handler. * Do not deploy the `StatisticsServlet` exposed to the network * Do not call `getLocale` API * Do not enable precompressed static content in the `DefaultServlet` ### Patches All patches are available for download from the Eclipse Jetty website at [https://www.eclipse.org/jetty/download.php](https://www.eclipse.org/jetty/download.php) - 9.4.37.v20210219 and greater - 10.0.1 and greater - 11.0.1 and greater |
Affected by 28 other vulnerabilities. Affected by 5 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 5 other vulnerabilities. |
|
VCID-ypc7-f1nd-t7gn
Aliases: CVE-2023-36478 GHSA-wgh7-54f2-x98r |
Uncontrolled Resource Consumption Eclipse Jetty provides a web server and servlet container. In versions 11.0.0 through 11.0.15, 10.0.0 through 10.0.15, and 9.0.0 through 9.4.52, an integer overflow in `MetaDataBuilder.checkSize` allows for HTTP/2 HPACK header values to exceed their size limit. `MetaDataBuilder.java` determines if a header name or value exceeds the size limit, and throws an exception if the limit is exceeded. However, when length is very large and huffman is true, the multiplication by 4 in line 295 will overflow, and length will become negative. `(_size+length)` will now be negative, and the check on line 296 will not be triggered. Furthermore, `MetaDataBuilder.checkSize` allows for user-entered HPACK header value sizes to be negative, potentially leading to a very large buffer allocation later on when the user-entered size is multiplied by 2. This means that if a user provides a negative length value (or, more precisely, a length value which, when multiplied by the 4/3 fudge factor, is negative), and this length value is a very large positive number when multiplied by 2, then the user can cause a very large buffer to be allocated on the server. Users of HTTP/2 can be impacted by a remote denial of service attack. The issue has been fixed in versions 11.0.16, 10.0.16, and 9.4.53. There are no known workarounds. |
Affected by 5 other vulnerabilities. |
|
VCID-zdt8-jrn2-m3ff
Aliases: CVE-2019-17632 GHSA-5h9j-q6j2-253f |
Unescaped exception messages in error responses in Jetty 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. |
Affected by 5 other vulnerabilities. |
|
VCID-znv6-77jf-v3gu
Aliases: CVE-2017-7656 GHSA-84q7-p226-4x5w |
In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), HTTP/0.9 is handled poorly. An HTTP/1 style request line (i.e. method space URI space version) that declares a version of HTTP/0.9 was accepted and treated as a 0.9 request. If deployed behind an intermediary that also accepted and passed through the 0.9 version (but did not act on it), then the response sent could be interpreted by the intermediary as HTTP/1 headers. This could be used to poison the cache if the server allowed the origin client to generate arbitrary content in the response. |
Affected by 28 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-12gq-ezut-ckhz |
CVE-2017-7657
GHSA-vgg8-72f2-qm23 |
|
| VCID-kvqz-fppe-d7fe |
CVE-2017-7658
GHSA-6x9x-8qw9-9pp6 |
|
| VCID-znv6-77jf-v3gu | In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), HTTP/0.9 is handled poorly. An HTTP/1 style request line (i.e. method space URI space version) that declares a version of HTTP/0.9 was accepted and treated as a 0.9 request. If deployed behind an intermediary that also accepted and passed through the 0.9 version (but did not act on it), then the response sent could be interpreted by the intermediary as HTTP/1 headers. This could be used to poison the cache if the server allowed the origin client to generate arbitrary content in the response. |
CVE-2017-7656
GHSA-84q7-p226-4x5w |