Affected: Eclipse Foundation Eclipse Jetty, Red Hat HawtIO HawtIO 4.4.0, Red Hat AMQ Broker 7.14.0, Red Hat JBoss Enterprise Application Platform 8.1, Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 8, Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 9, Red Hat OpenShift Developer Tools and Services 4.12, Red Hat OpenShift Developer Tools and Services 4.13, Red Hat OpenShift Developer Tools and Services 4.14, Red Hat OpenShift Developer Tools and Services 4.15 and 28 more

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: tools.jackson.core:jackson-core

## Summary

Jackson Core 3.x does not consistently enforce `StreamReadConstraints.maxDocumentLength`. Oversized JSON documents can be accepted without a `StreamConstraintsException` in multiple parser entry points, which allows configured size limits to be bypassed and weakens denial-of-service protections.

## Details

Three code paths where `maxDocumentLength` is not fully enforced:

### 1. Blocking parsers skip validation of the final in-memory buffer

Blocking parsers validate only previously processed buffers, not the final in-memory buffer:

- `ReaderBasedJsonParser.java:255` - `UTF8StreamJsonParser.java:208`

Relevant code:

```java _currInputProcessed += bufSize; _streamReadConstraints.validateDocumentLength(_currInputProcessed); ```

This means the check occurs only when a completed buffer is rolled over. If an oversized document is fully contained in the final buffer, parsing can complete without any document-length exception.

### 2. Async parsers skip validation of the final chunk on end-of-input

Async parsers validate previously processed chunks, but do not validate the final chunk on end-of-input:

- `NonBlockingByteArrayJsonParser.java:49` - `NonBlockingByteBufferJsonParser.java:57` - `NonBlockingUtf8JsonParserBase.java:75`

Relevant code:

```java _currInputProcessed += _origBufferLen; _streamReadConstraints.validateDocumentLength(_currInputProcessed);

public void endOfInput() { _endOfInput = true; } ```

`endOfInput()` marks EOF but does not perform a…