GitHub Advisoryadvisory · Maven

GHSA-qw69-rqj8-6qw8 OutOfMemoryError for large multipart without filename in Eclipse Jetty

MEDIUM Published 2023-04-19 Modified 2023-04-19 Official page ↗
Aliases
CVE-2023-26048
Ecosystem
Maven
Packages
org.eclipse.jetty:jetty-server
Severity
Moderate
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Weaknesses
CWE-400, CWE-770
Reviewed
2023-04-19

Affected packages

• Maven org.eclipse.jetty:jetty-server: < 9.4.51.v20230217 → fixed in 9.4.51.v20230217 • Maven org.eclipse.jetty:jetty-server: >= 10.0.0, < 10.0.14 → fixed in 10.0.14 • Maven org.eclipse.jetty:jetty-server: >= 11.0.0, < 11.0.14 → fixed in 11.0.14

Description

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

Related

Alias · CVE (1)

  • CVE-2023-26048 Jetty is a java based web server and servlet engine. vulnerability

Weakness · CWE (2)

  • CWE-400 Uncontrolled Resource Consumption weakness
  • CWE-770 Allocation of Resources Without Limits or Throttling weakness

References