Most recent entries from all

bdu:2023-05675

certfr-2023-avi-0705 — De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre el…

certfr-2023-avi-0705

Withdrawn: CLEANSTART-2026-IF26545 — Security fixes in apache-hive 4.0.1-r1

Withdrawn by the publisher.

Affected: CleanStart: apache-hive

Package apache-hive version 4.0.1-r1 fixes 27 vulnerabilities: CVE-2024-47561, CVE-2024-7254, CVE-2024-47554, CVE-2022-41881, CVE-2023-34462...

EUVD-2026-216341

fkie_cve-2023-26048

Jetty is a java based web server and servlet engine. In affected versions 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 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. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).

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

Affected: Maven: org.eclipse.jetty:jetty-server

### 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

gsd-2023-26048

OESA-2024-2268 — jetty security update

Affected: openEuler:20.03-LTS-SP4: jetty

%global desc \ Jetty is a 100% Java HTTP Server and Servlet Container. This means that you\ do not need to configure and run a separate web server (like Apache) in order\ to use Java, servlets and JSPs to generate dynamic content. Jetty is a fully\ featured web server for static and dynamic content. Unlike separate\ server/container solutions, this means that your web server and web\ application run in the same process, without interconnection overheads\ and complications. Furthermore, as a pure java component, Jetty can be simply\ included in your application for demonstration, distribution or deployment.\ Jetty is available on all Java supported platforms. \ %global extdesc \\ \ This package contains Security Fix(es): Jetty is a java based web server and servlet engine. In affected versions 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 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. This issue has been patched in versions…

openSUSE-SU-2024:12949-1 — jetty-annotations-9.4.51-1.1 on GA media

jetty-annotations-9.4.51-1.1 on GA media

RHSA-2023:5165 — Red Hat Security Advisory: Red Hat AMQ Streams 2.5.0 release and security update

netty-codec: Bzip2Decoder doesn't allow setting size restrictions for decompressed data netty-codec: SnappyFrameDecoder doesn't restrict chunk length and may buffer skippable chunks in an unnecessary way SnakeYaml: Constructor Deserialization Remote Code Execution netty: world readable temporary file containing sensitive data scala: deserialization gadget chain RESTEasy: creation of insecure temp files guava: insecure temporary directory creation okio: GzipSource class improper exception handling jetty-server: OutOfMemoryError for large multipart without filename read via request.getParameter() jetty-server: Cookie parsing of quoted values can exfiltrate values from other cookies bouncycastle: potential blind LDAP injection attack using a self-signed certificate snappy-java: Integer overflow in shuffle leads to DoS snappy-java: Integer overflow in compress leads to DoS snappy-java: Unchecked chunk length leads to DoS netty: SniHandler 16MB allocation leads to OOM

UBUNTU-CVE-2023-26048

Affected: Ubuntu:14.04:LTS: jetty, Ubuntu:16.04:LTS: jetty

WID-SEC-W-2023-1009 — Eclipse Jetty: Mehrere Schwachstellen

Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Eclipse Jetty ausnutzen, um einen Denial of Service Angriff durchzuführen oder Informationen offenzulegen.