Search for packages
| purl | pkg:maven/org.eclipse.jetty/jetty-server@9.4.20.v20190813 |
| Next non-vulnerable version | 9.4.57.v20241219 |
| Latest non-vulnerable version | 12.0.9 |
| Risk | 4.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-5e9v-g286-zyd9
Aliases: CVE-2023-26048 GHSA-qw69-rqj8-6qw8 |
OutOfMemoryError for large multipart without filename in Eclipse Jetty ### 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 parameter `maxFileSize` won't be enough because an attacker can send a large number of parts that summed up will cause memory issues. ### References * https://github.com/eclipse/jetty.project/issues/9076 * https://github.com/jakartaee/servlet/blob/6.0.0/spec/src/main/asciidoc/servlet-spec-body.adoc#32-file-upload |
Affected by 2 other vulnerabilities. Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-65kw-jwxu-53f9
Aliases: CVE-2023-26049 GHSA-p26g-97m4-6q7c |
Eclipse Jetty's cookie parsing of quoted values can exfiltrate values from other cookies 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. ### Impact 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. ### Patches * 9.4.51.v20230217 - via PR #9352 * 10.0.15 - via PR #9339 * 11.0.15 - via PR #9339 ### Workarounds No workarounds ### References * https://www.rfc-editor.org/rfc/rfc2965 * https://www.rfc-editor.org/rfc/rfc6265 |
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-a3cg-7nkv-s3gb
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 8 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-b5fq-sj47-vyde
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 9 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-c5aj-3a1x-bfhu
Aliases: CVE-2021-28165 GHSA-26vr-8j45-3r4w |
denial of service |
Affected by 0 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. Affected by 5 other vulnerabilities. |
|
VCID-j7u4-b9k8-rff6
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-s3d8-ywz4-17dt
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 1 other vulnerability. Affected by 8 other vulnerabilities. Affected by 7 other vulnerabilities. Affected by 7 other vulnerabilities. |
|
VCID-t2tr-gg1r-nbhv
Aliases: CVE-2023-40167 GHSA-hmr7-m48g-48f6 |
Jetty accepts "+" prefixed value in Content-Length ### Impact 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. ### Workarounds There is no workaround as there is no known exploit scenario. ### Original Report [RFC 9110 Secion 8.6](https://www.rfc-editor.org/rfc/rfc9110#section-8.6) defined the value of Content-Length header should be a string of 0-9 digits. However we found that Jetty accepts "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. Payload: ``` POST / HTTP/1.1 Host: a.com Content-Length: +16 Connection: close 0123456789abcdef ``` When sending this payload to Jetty, it can successfully parse and identify the length. When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. |
Affected by 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-ysf1-dbk7-vkh7
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. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||