A vulnerability in Netty's HttpContentEncoder allows unbounded growth of a per-connection queue due to HTTP/1.1 pipelining. This can lead to resource exhaustion and denial of service when an attacker floods a connection with requests faster than responses are produced. The flaw affects specific versions prior to 4.2.16.Final and 4.1.136.Final.
CVE-2026-59898 is a vulnerability in io.netty:netty-codec-http affecting WebSocket V07/V08 handshakers. The flaw allows an attacker to bypass the required 'Connection: Upgrade' and 'Upgrade: websocket' headers by sending 'Sec-WebSocket-Version: 7', causing the server to complete a WebSocket protocol switch that proxies may not recognize. This can enable HTTP request smuggling and protocol confusion attacks. The issue affects versions >=4.2.0.Final <4.2.16.Final and <4.1.136.Final. Fixed versions are 4.2.16.Final and 4.1.136.Final. The CVSS 4.0 score is 6.3 (medium severity). No known exploits are reported in the wild.
Netty's OcspServerCertificateValidator has a time-of-check to time-of-use (TOCTOU) vulnerability where it forwards the TLS handshake completion event before asynchronous OCSP validation finishes. This allows a client to send sensitive data to a revoked server certificate before the connection is closed. The issue affects versions prior to 4.2.16.Final and 4.1.136.Final and has a high severity rating.
Netty's OcspServerCertificateValidator improperly processes out-of-date OCSP responses by flagging them but still treating them as valid. This flaw allows an attacker to replay stale but previously valid OCSP responses, bypassing certificate revocation checks. The vulnerability affects versions prior to 4.2.16.Final and 4.1.136.Final. A fix is available in these versions.
Netty's OcspClient component fails to validate that the CertificateID in an OCSP response matches the requested certificate's CertificateID. This flaw allows an attacker to replay a valid OCSP 'GOOD' status response for an unrelated certificate issued by the same CA, bypassing revocation checks. The vulnerability affects versions prior to 4.2.16.Final and 4.1.136.Final. A fix is available in these versions.
CVE-2026-56817 is a high-severity vulnerability in the io.netty:netty-codec-xml library where an unconfigured XML parser with active DTD and entity handling allows an attacker to send XML with a DOCTYPE declaration. This misconfiguration can lead to XML External Entity (XXE) injection depending on the behavior of the underlying Aalto XML async parser. The issue affects versions 4.2.0.Final up to but not including 4.2.16.Final and 4.1.0.Final up to but not including 4.1.136.Final. Fixed versions are available.
Netty's HTTP/3 codec (Http3FrameCodec) improperly trusts the payload length of reserved HTTP/3 frame types without enforcing any maximum size. An attacker can exploit this by sending reserved frames with very large payload lengths, causing the server to buffer excessive data in memory. This leads to memory exhaustion and a denial of service when multiple such streams are opened concurrently. The issue affects Netty versions prior to 4.2.16.Final and has been assigned CVE-2026-56816.
Netty's CorsHandler has a vulnerability in its short-circuit logic that allows bypassing cross-origin request restrictions when the Origin header is set to null. This flaw causes unauthorized requests to reach backend applications despite intended access controls. The issue is due to a logical error in handling null origins, leading to the short-circuit mechanism being bypassed.
CVE-2026-56745 is a high-severity vulnerability in Netty's SPDY-to-HTTP codec (SpdyHttpDecoder) where a pooled ByteBuf is leaked when processing RST_STREAM frames or when content length limits are exceeded. This leak leads to native memory exhaustion. The issue affects versions 4.2.0.Final up to but not including 4.2.16.Final and 4.1.0.Final up to but not including 4.1.136.Final. Fixed versions are 4.2.16.Final and 4.1.136.Final.
A vulnerability in Netty's codec-haproxy module allows an attacker to cause unbounded memory exhaustion by exploiting a signed-byte sentinel collision in the HAProxyMessageDecoder. The decoder misinterprets a crafted version byte, causing it to loop indefinitely requesting more data without consuming input, leading to JVM direct memory exhaustion.
A vulnerability in Netty's SPDY header decoding allows a remote unauthenticated attacker to send a compressed SPDY HEADERS block that inflates beyond the configured maxHeaderSize limit, causing excessive CPU and memory usage. This leads to a denial of service (DoS) condition. The issue affects specific versions of io.netty:netty-codec-http prior to fixed releases 4.2.16.Final and 4.1.136.Final.
Netty's SPDY SETTINGS decoder in versions before 4.2.16.Final and 4.1.136.Final accepts a peer-declared SETTINGS entry count up to the 24-bit frame-length limit without limiting the number of unique setting IDs. This allows a remote unauthenticated SPDY/3.1 peer to send a single large SETTINGS frame that creates over 262,000 map entries, causing significant heap memory growth and CPU usage. This results in a resource exhaustion denial of service condition.
An incomplete fix in jackson-core's async JSON parser allows an attacker to bypass the maxNumberLength limit by streaming JSON numbers in many small chunks without terminators, causing unbounded memory allocation. This affects versions prior to 2.18.8, certain 2.19.x and 2.21.x versions, and some 3.x versions. The vulnerability leads to memory exhaustion due to unchecked growth of the internal text buffer during integer parsing in non-blocking mode.
A vulnerability in jackson-databind versions 2.18.0 through 2.18.8 and 2.21.0 through 2.21.4 allows bypassing the @JsonView filter for creator properties annotated with @JsonTypeInfo(include=As.EXTERNAL_PROPERTY). This occurs because the active view check is missing in the creator-property branch of the deserialization code, enabling attacker-controlled JSON to populate restricted properties even when a more restrictive view is active.
A vulnerability in PostgreSQL JDBC Driver versions 42.7.4 through 42.7.11 allows silent downgrade of channel-binding authentication from SCRAM-SHA-256-PLUS to SCRAM-SHA-256 when using the 'channelBinding=require' setting. This downgrade removes the man-in-the-middle protection that channel binding is intended to provide. The issue arises from a combination of the SCRAM client library returning an empty binding hash for certain certificate algorithms and pgJDBC not enforcing channel binding properly. The vulnerability is fixed in version 42.7.12.
### Summary
The JLine3 Telnet server (`remote-telnet` module) does not limit the number of
environment variables a client may inject via the Telnet NEW-ENVIRON option. An
unauthenticated attacker can flood the server with a large number of unique
variable pairs before sending the terminating IAC SE byte, exhausting JVM heap
memory and causing an OutOfMemoryError (denial of service). Approximately 3–4 MB of
network traffic is sufficient to consume a 512 MB JVM heap.
### Details
`TelnetIO.readNEVariables()` (TelnetIO.java:1127-1180) processes incoming NEW-ENVIRON
variable pairs in a loop and stores each pair in a `HashMap` held by `ConnectionData`:
```java
// TelnetIO.java:1139-1178
boolean cont = true;
if (i == NE_VAR || i == NE_USERVAR) {
do {
switch (readNEVariableName(sbuf)) {
case NE_VAR_OK:
TelnetIO.this.connectionData.getEnvironment().put(str, sbuf.toString());
// ← no per-connection count limit
break;
case NE_VAR_UNDEFINED:
break; // cont remains true, loop continues
}
} while (cont); // cont is never set to false; only exits via return
}
```
The variable accumulator map is a plain `HashMap` initialized with capacity 20 and
**no maximum size**:
```java
// ConnectionData.java:98
environment = new HashMap<String, String>(20);
```
Per-variable limits exist (name: max 50 chars, value: max 1000 chars), but there is no
cap on the *count* of variables. Each map entry occupies approximately 2 KB of heap
(String headers + `Map.Entry` + backing char arrays). On a JVM with a 512 MB heap,
approximately 250,000 unique entries trigger an `OutOfMemoryError`.
Network cost: using sequential 1-byte names (e.g., `\x01`, `\x02`, ...) and 1-byte
values, each variable pair requires roughly 13 protocol bytes. Sending 250,000 pairs
requires only ~3.25 MB of network traffic — feasible in seconds over any reasonable
network connection.
No authentication is required. NEW-ENVIRON negotiation occurs before login.
Affected source files:
- `remote-telnet/src/main/java/org/jline/builtins/telnet/TelnetIO.java` lines 1127-1180
- `remote-telnet/src/main/java/org/jline/builtins/telnet/ConnectionData.java` line 98
### PoC
Connect to the JLine3 Telnet server and, after completing WILL/DO option negotiation,
send a NEW-ENVIRON SEND subneg followed by a single large IS subneg containing
thousands of unique variable pairs before the final IAC SE.
Protocol structure (no authentication required):
1. Standard Telnet option negotiation (IAC DO NEW-ENVIRON, IAC WILL NEW-ENVIRON)
2. Server sends IAC SB NEW-ENVIRON SEND IAC SE
3. Client responds with: IAC SB NEW-ENVIRON IS
[NE_VAR 0x01 NE_VALUE 0x01] ← variable pair 1
[NE_VAR 0x02 NE_VALUE 0x01] ← variable pair 2
... repeated N times ...
IAC SE ← only sent after N pairs
Each iteration adds one entry to the per-connection environment map. The connection
thread blocks reading from the socket while accumulating pairs, so the attacker
controls the timing of the OOM.
Reproduction environment:
- JLine3 built from current master on x86_64 Linux, OpenJDK 25.0.2
- `remote-telnet` module started with its default configuration
- Confirmed by source-code analysis; loop exit condition and missing count guard
verified by inspection of `readNEVariables()` and `ConnectionData` constructor
### Impact
**Type**: Denial of Service (heap memory exhaustion / OutOfMemoryError)
**Who is affected**: Any application embedding the JLine3 `remote-telnet` module and
exposing its Telnet server. No credentials are required. A single connection can exhaust
the entire JVM heap, crashing the host process or triggering JVM out-of-memory
handling that impacts all users sharing that JVM instance.
### Credits
This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.
A vulnerability in HAPI FHIR's org.hl7.fhir.core module allows denial of service via inefficient regular expression evaluation. Versions prior to 6.9.4.2 and between 6.9.5 and before 6.9.9 accept arbitrary FHIRPath expressions without sufficient input validation. The matches(), matchesFull(), and replaceMatches() functions pass user-controlled regex patterns to Java's Pattern.compile() and String.replaceAll() with an incomplete timeout mechanism, enabling catastrophic backtracking and CPU exhaustion. This issue is fixed in versions 6.9.9 and 6.9.4.2.
### Summary
The JLine3 Telnet server (`remote-telnet` module) does not apply an upper bound to
terminal dimensions received via the Telnet NAWS (Negotiate About Window Size) option.
An unauthenticated remote attacker can send a NAWS subnegotiation advertising a
65535×65535 terminal and repeatedly alternate values to trigger continuous, expensive
rendering work on the server, causing CPU exhaustion and denial of service.
### Details
`TelnetIO.handleNAWS()` (TelnetIO.java:856-879) reads the client-supplied width and
height as 16-bit unsigned integers and passes them to `setTerminalGeometry()`:
```java
// TelnetIO.java:869-875
private void setTerminalGeometry(int columns, int rows) {
if (columns < SMALLEST_BELIEVABLE_WIDTH) columns = DEFAULT_WIDTH; // lower bound only
if (rows < SMALLEST_BELIEVABLE_HEIGHT) rows = DEFAULT_HEIGHT;
connectionData.setTerminalGeometry(columns, rows);
connection.processConnectionEvent(
new ConnectionEvent(connection, ConnectionEvent.Type.CONNECTION_TERMINAL_GEOMETRY_CHANGED));
}
```
Only a *lower* bound is enforced (minimum 20 columns / 6 rows). Values up to 65535 are
accepted and stored. The geometry change event propagates to Telnet.java:153-158 where
it calls:
terminal.setSize(new Size(65535, 65535));
terminal.raise(Signal.WINCH);
The WINCH signal triggers `LineReaderImpl.handleSignal()` → `redisplay()`. Inside
`redisplay()`, multiple paths iterate up to `size.getColumns()` times:
- `freshLine()` (LineReaderImpl.java:937,953): loops `size.getColumns()-1` = **65534
iterations**, building and writing a space-padding string across the network socket.
- `columnSplitLength(terminal, size.getColumns(), ...)`: called multiple times,
each processing all characters against the 65535-wide line width.
Because WINCH only fires on *change*, the attacker alternates between two large values
(e.g., 65535 and 65534) to trigger an unlimited stream of expensive render cycles.
No authentication is required; the NAWS option is negotiated before any login sequence.
Affected source files:
- `remote-telnet/src/main/java/org/jline/builtins/telnet/TelnetIO.java` lines 856-879
- `remote-telnet/src/main/java/org/jline/builtins/telnet/Telnet.java` lines 140-175
- `reader/src/main/java/org/jline/reader/impl/LineReaderImpl.java` lines 929-962, 1293-1313
### PoC
Send the following two raw Telnet packets in a loop to a running JLine Telnet server.
No login or authentication is required.
Packet 1 — NAWS 65535 × 65535:
FF FA 1F FF FF FF FF FF F0
(IAC SB NAWS 0xFF 0xFF 0xFF 0xFF IAC SE)
Packet 2 — NAWS 65534 × 65534:
FF FA 1F FF FE FF FE FF F0
(IAC SB NAWS 0xFF 0xFE 0xFF 0xFE IAC SE)
Sending these alternately at ~10 packets/second is sufficient to peg one CPU core on
the server. The server remains in this state for as long as the connection is open.
Reproduction environment:
- JLine3 built from current master on x86_64 Linux, OpenJDK 25.0.2
- `remote-telnet` module started with its default `Telnet` server configuration
- Test confirmed by source-code analysis and tracing the call chain at runtime
### Impact
**Type**: Denial of Service (CPU exhaustion)
**Who is affected**: Any application that embeds the JLine3 `remote-telnet` module and
exposes its Telnet server on a network interface. The attacker requires no credentials.
A single connection making ~10 alternating NAWS packets per second fully occupies the
connection-handling thread and produces continuous I/O on the server's output stream.
Because connection threads are re-used for the life of the session, one attacker per
available connection slot can deny service to all users of that slot.
### Credits
This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.
# CVE-2026-45799
## Maintainer summary
Wire's protobuf group-skipping logic did not reject negative lengths before skipping a
length-delimited field inside a group. A crafted protobuf payload could cause Wire to throw an
unchecked runtime exception during decoding instead of the documented `IOException` /
`ProtocolException` failure path.
This can crash services that decode untrusted protobuf payloads and only handle Wire's documented
checked decoding failures.
## Affected artifacts
### `com.squareup.wire:wire-runtime`
Affected versions: vulnerable releases before `6.3.0`.
Patched versions: `6.3.0` and later.
Users should upgrade to `com.squareup.wire:wire-runtime:6.3.0` or later.
### `com.squareup.wire:wire-runtime-jvm`
Affected versions: vulnerable releases before `6.3.0`.
Patched versions: `6.3.0` and later.
Users should upgrade to `com.squareup.wire:wire-runtime:6.3.0` or later.
### Wire 7 alpha releases
The fix has been merged to `master` and will be included in the next Wire 7 alpha release. Until
that release is available, Wire 7 alpha users should avoid decoding untrusted protobuf payloads with
affected alpha versions or build from a commit containing the fix.
## Fix
The issue is fixed in Wire `6.3.0`.
The fix rejects negative lengths while skipping groups and throws `ProtocolException` instead of
allowing the reader to move to an invalid position and later throw an unchecked runtime exception.
## Credit
Reported by @TrekLaps.
## Technical details
The following technical details are based on the original report, updated by the maintainers to
reflect the assigned CVE, the supported fixed artifact, and the discontinued status of
`com.squareup.wire:wire-runtime-jvm`.
`ByteArrayProtoReader32.skipGroup()` in `wire-runtime` did not validate that a
`LENGTH_DELIMITED` field's length is non-negative before calling `skip()`. A crafted protobuf
varint encodes `-128` as a signed `Int`. When `skip(-128)` runs, the internal position counter
underflows to an invalid negative position. The next `readByte()` accesses the source with that
negative position, throwing `ArrayIndexOutOfBoundsException`, a `RuntimeException` that escapes
Wire's documented `IOException` boundary and can crash the request handler.
`ProtoAdapter.decode(byte[])` is declared to throw `IOException`. Callers following the documented
API may catch only `IOException`, so unchecked runtime exceptions from malformed input can escape
the expected error boundary.
The originally confirmed vulnerable legacy versions include `5.3.1` and `5.3.3` for the
discontinued `com.squareup.wire:wire-runtime-jvm` coordinate. The supported replacement coordinate
is `com.squareup.wire:wire-runtime`, fixed in version `6.3.0`.
## Root cause
In the originally reported vulnerable code path, `ByteArrayProtoReader32.skipGroup()` read the
length as a signed `Int` and used it without validating that it was non-negative:
```kotlin
STATE_LENGTH_DELIMITED -> {
val length = internalReadVarint32() // returns signed Int and can be negative
skip(length) // no negative check
}
```
The internal `skip()` implementation then accepted the negative count because the computed
position was not greater than the limit:
```kotlin
private fun skip(byteCount: Int) {
val newPos = pos + byteCount // for example, 7 + (-128) = -121
if (newPos > limit) throw EOFException()
pos = newPos // pos = -121
}
```
The next read could then index the source with the invalid negative position:
```kotlin
private fun readByte(): Byte {
if (pos == limit) throw EOFException()
return source[pos++] // source[-121] throws ArrayIndexOutOfBoundsException
}
```
Wire already rejected negative lengths in normal length-delimited field decoding. The same
validation was missing from group-skipping code.
The fix adds this validation when skipping groups:
```kotlin
STATE_LENGTH_DELIMITED -> {
val length = internalReadVarint32()
if (length < 0) throw ProtocolException("Negative length: $length...")
skip(length)
}
```
The fix was applied to both `ByteArrayProtoReader32.skipGroup()` and `ProtoReader.skipGroup()`.
## Reproduction
The following reproduction was provided for vulnerable legacy `wire-runtime-jvm` releases such as
`5.3.1` and `5.3.3`:
```bash
curl -sL https://repo1.maven.org/maven2/com/squareup/wire/wire-runtime-jvm/5.3.3/wire-runtime-jvm-5.3.3.jar -o wire.jar
curl -sL https://repo1.maven.org/maven2/com/squareup/okio/okio-jvm/3.9.1/okio-jvm-3.9.1.jar -o okio.jar
curl -sL https://repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib/2.1.0/kotlin-stdlib-2.1.0.jar -o stdlib.jar
```
```java
// WirePoc.java
import com.squareup.wire.AnyMessage;
public class WirePoc {
public static void main(String[] args) throws Exception {
byte[] payload = new byte[] {
(byte) 0x9B, 0x06, // field 99, START_GROUP
0x0A,
A vulnerability in com.ongres.scram:scram-client versions prior to 3.3 allows a TLS man-in-the-middle attacker to silently downgrade SCRAM authentication from SCRAM-SHA-256-PLUS (with channel binding) to SCRAM-SHA-256 (without channel binding). This occurs when the server presents an X.509 certificate using modern signature algorithms that the client cannot parse properly, causing fallback to a less secure authentication method without error. This can bypass strict channel binding policies in affected deployments.