The Eclipse Foundation is a [Common Vulnerabilities and Exposures](https://cve.mitre.org/) (CVE) Numbering Authority. This issue it used to request and track the progress of the assignment of a CVE for a vulnerability in the project code for an Eclipse open source project. <!-- Required. Specify the project's name (e.g., "Eclipse Dash") and Eclipse Foundation ID, e.g., "technology.dash". --> ## Basic information **Project name:** Eclipse Jetty **Project id:** rt/jetty <!-- Required. Specify if you want a reservation only (in this case you may skip the fields below) or a publication (you need to fill all fields). Please note that you can do the reservation first, then ask us for publication when the project has made a release with the fix. --> **Request type:** reservation <!-- Required (if publication). Specify the version range as precisely as possible, e.g., "[3.0, 3.5.1]" or "[3.0, 3.5.1)". Note that using the standard range notion, square brackets are inclusive (i.e., that version is included in the range), and round brakets are exclusive (the vulnerability affects all versions up to but not including the named version). Multiple ranges can be provided. --> **Versions affected:** [12.0.0, 12.0.16] <!-- Required (if publication). The Common Weakness Enumeration (CWE) code comes from here: https://cwe.mitre.org/, e.g., "CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')". Multiple codes can be provided. --> **Common Weakness Enumeration:** - CWE-400 <!-- Optional. Provide a Common Vulnerability Scoring System (CVSS). Note that if you do not provide this, then some agencies (eg. NIST) will compute it on the project's behalf. Please be sure to include the CVSS version number, e.g., "3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H". There's help here: https://nvd.nist.gov/vuln-metrics/cvss --> **Common Vulnerability Scoring System:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H <!-- Required (if publication). The summary should start with the name of the project, e.g., "Eclipse Vert.x", then a description of the affected versions, followed by a description of the problem. The summary should be concise. For example, "In Eclipse Vert.x version 3.0 to 3.5.1, the HttpServer response headers and HttpClient request headers do not filter carriage return and line feed characters from the header value. This allow unfiltered values to inject a new header in the client request or server response." --> **Summary:** In Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGS_MAX_HEADER_LIST_SIZE. The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting. <!-- Required (if publication). Include a link to the issue (e.g., GitHub Security Advisory) that's being used to track/resolve the issue. Other links that provide more information can be provided. For example, you may later publish the link to the fix commit. --> **Links:** - https://github.com/jetty/jetty.project/security/advisories/GHSA-889j-63jv-qhr8 - https://github.com/jetty/jetty.project/issues/12690 ## Tracking **This section will completed by the project team**. - [x] Reserve an entry only - [x] We're ready for this issue to be reported to the central authority (i.e., make this public now) - [x] (when applicable) The GitHub Security Advisory is ready to be published now Note that for those projects that host their repositories on GitHub, the use of GitHub Security Advisories is recommended but is not required. **This section will be completed by the EMO**. **CVE:** {cve} - [ ] All required information is provided - [ ] CVE Assigned - [ ] Pushed to Mitre - [ ] Accepted by Mitre <!-- Quick actions will configure the state of the issue. Leave these. -->