Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
BinaryHttpParser: Unauthenticated CPU-exhaustion DoS via infinite loop in field-section decoding - ID: BHTTP-LOOP-001 - Severity: High - CVSS v3.1: 7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - CWE: CWE-835 (Loop with Unreachable Exit Condition) — secondary CWE-400 (Uncontrolled Resource Consumption) - Affected component: codec-bhttp → io.netty.incubator.codec.bhttp.BinaryHttpParser#readFieldSection, file codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:619-626 - Affected version: netty-incubator-codec-ohttp HEAD d3f2b49 (release 0.0.22.Final + 3 commits). The loop has existed since the parser was introduced and is present in the latest code; all published advisory fixes are already applied. - Reachable from: io.netty.incubator.codec.ohttp.OHttpRequestResponseContext$ContentDecoder#decodeChunk (codec-ohttp/.../OHttpRequestResponseContext.java:214), i.e. the auto-wired OHTTP server and client codecs. - Confidence: High (empirically reproduced hang…
Recommended action: Upgrade to 0.0.23.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
We don't enforce any limits for the encoded variable lengths that are used for fields. As the remote peer controls these it's easy for the remote peer to have us buffer data forever and so ultimately OOM.
Recommended action: Upgrade to 0.0.23.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
io.netty.incubator:netty-incubator-codec-bhttp can enter a non-terminating parse loop when a known-length Binary HTTP field section ends exactly after a complete field line. A remote peer that can send Binary HTTP input to a Netty pipeline using BinaryHttpParser / BinaryHttpDecoder can use a tiny malformed request or response to keep the parsing thread busy indefinitely, causing denial of service. Details In codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java, readFieldSection(...) tracks the remaining field-section length in fieldSectionLength, then repeatedly calls readFieldLine(...) until the length reaches zero: - readFieldSection(...) parses the known-length field section and enters while (fieldSectionLength != 0) at BinaryHttpParser.java:619. - Inside the loop, it records readableBytes, calls readFieldLine(...), computes read = readableBytes - in.readableBytes(), asserts read 0, and subtracts read from fieldSectionLength at…
Recommended action: Upgrade to 0.0.23.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
io.netty.incubator:netty-incubator-codec-bhttp uses attacker-controlled Binary HTTP variable-length integers as long values but accumulates them into int offsets. Large valid varint lengths wrap the internal offset negative, leading to unchecked ArrayIndexOutOfBoundsException / IndexOutOfBoundsException from a tiny malformed BHTTP payload. A remote peer can trigger connection-level denial of service in applications that expose BinaryHttpParser / BinaryHttpDecoder to untrusted input. Details In codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java, several parser paths store cumulative byte offsets in int sumBytes and then add attacker-controlled long lengths using compound assignment. In Java, int += long narrows the result back to int, so a length such as 2^31 wraps sumBytes negative. Primary request-control-data path: - readRequestHead(...) declares int sumBytes = 0 at BinaryHttpParser.java:386. - It reads methodLength as a long at…
Recommended action: Upgrade to 0.0.23.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
BinaryHttpParser does not properly validate input values thus giving attackers almost complete control over the HTTP requests constructed from the parsed output. Attackers can abuse several issues individually to perform various injection attacks including HTTP request smuggling, desync attacks, HTTP header injections, request queue poisoning, caching attacks and Server Side Request Forgery (SSRF). Attacker could also combine several issues to create well-formed messages for other text-based protocols which may result in attacks beyond the HTTP protocol. Details Path, Authority, Scheme The BinaryHttpParser class implements the readRequestHead method which performs most of the relevant parsing of the received request. The data structure prefixes values with a variable length integer value. The algorithm to create a variable length integer value is below: The parsing code below first gets the lengths of the values from the prefixed variable length integer. After it has all of…
Recommended action: Upgrade to 0.0.13.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.