Withdrawn by the publisher.

Affected: CleanStart: kafka-fips

Multiple security vulnerabilities affect the kafka-fips package. These issues are resolved in later releases. See references for individual vulnerability details.

In Eclipse Jetty, versions 12.0.0-12.0.31 and 12.1.0-12.0.5, class GzipHandler exposes a vulnerability when a compressed HTTP request, with Content-Encoding: gzip, is processed and the corresponding response is not compressed.

This happens because the JDK Inflater is allocated for decompressing the request, but it is not released because the release mechanism is tied to the compressed response. In this case, since the response is not compressed, the release mechanism does not trigger, causing the leak.

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

### Description (as reported)

There is a memory leak when using `GzipHandler` in jetty-12.0.30 that can cause off-heap OOMs. This can be used for DoS attacks so I'm reporting this as a vulnerability.

The leak is created by requests where the request is inflated (`Content-Encoding: gzip`) and the response is not deflated (no `Accept-Encoding: gzip`). In these conditions, a new inflator will be created by `GzipRequest` and never released back into `GzipRequest.__inflaterPool` because `gzipRequest.destory()` is not called.

In heap dumps one can see thousands of `java.util.zip.Inflator` objects, which use both Java heaps and native memory. Leaking native memory causes of off-heap OOMs.

Code path in `GzipHandler.handle()`: 1. Line 601: `GzipRequest` is created when request inflation is needed. 2. Lines 611-616: The callback is only wrapped in `GzipResponseAndCallback` when both inflation and deflation are needed. 3. Lines 619-625: If the handler accepts the request (returns true), `gzipRequest.destroy()` is only called in the "request not accepted" path (returns false)

When deflation is needed, `GzipResponseAndCallback` (lines 102 and 116) properly calls `gzipRequest.destroy()` in its `succeeded()` and `failed()` methods. But this wrapper is only created when deflation is needed.

Possible fix: The callback should be wrapped whenever a `GzipRequest` is created, not just when deflation is needed. This ensures `gzipRequest.destroy()` is always called when the request completes…

bouncycastle: BC-JAVA: GOSTCTR implementation unable to process more than 255 blocks correctly crypto/tls: crypto/tls: Incorrect certificate validation during TLS session resumption bouncycastle: BC-JAVA: LDAP injection vulnerability in LDAPStoreHelper.java undici: Undici: HTTP Request Smuggling and Denial of Service due to duplicate Content-Length headers undici: undici: Denial of Service via unbounded memory consumption during WebSocket permessage-deflate decompression undici: undici: Denial of Service via crafted WebSocket frame with large length org.eclipse.jetty/jetty-server: Eclipse Jetty: Denial of Service due to unreleased JDK Inflater from compressed HTTP requests undici: Undici: Denial of Service via invalid WebSocket permessage-deflate extension parameter markdown-it: markdown-it: Denial of Service via Regular Expression Denial of Service in linkify function bouncycastle: BC-JAVA: PKIX draft CompositeVerifier accepts empty signature sequence as valid minimatch: minimatch: Denial of Service via specially crafted glob patterns minimatch: Minimatch: Denial of Service via catastrophic backtracking in glob expressions svgo: SVGO: Denial of Service via XML entity expansion express-rate-limit: express-rate-limit: Denial of Service for IPv4 clients due to incorrect IPv6 subnet masking tar: tar: File overwrite via drive-relative symlink traversal flatted: flatted: Unbounded recursion DoS in parse() revive phase crypto/x509: crypto/tls: golang: Go: Denial of Service vulnera…

Affected: Ubuntu:16.04:LTS: jetty9, Ubuntu:18.04:LTS: jetty9, Ubuntu:20.04:LTS: jetty9, Ubuntu:22.04:LTS: jetty9, Ubuntu:24.04:LTS: jetty9, Ubuntu:25.10: jetty9, Ubuntu:26.04:LTS: jetty12, Ubuntu:26.04:LTS: jetty9

In Eclipse Jetty, versions 12.0.0-12.0.31 and 12.1.0-12.0.5, class GzipHandler exposes a vulnerability when a compressed HTTP request, with Content-Encoding: gzip, is processed and the corresponding response is not compressed. This happens because the JDK Inflater is allocated for decompressing the request, but it is not released because the release mechanism is tied to the compressed response. In this case, since the response is not compressed, the release mechanism does not trigger, causing the leak.

Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Eclipse Jetty ausnutzen, um einen Denial of Service Angriff durchzuführen.