CVE-2026-61799
MEDIUMCVE-2026-61799 is a medium-severity (CVSS 5.3) remote code execution vulnerability in io.netty.incubator:netty-incubator-codec-bhttp. O3 Security confirms whether CVE-2026-61799 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
netty-incubator-codec-ohttp: Binary HTTP parser unchecked varint length overflow causes decoder crash
Real-World Exposure
io.netty.incubator:netty-incubator-codec-bhttpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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(...)declaresint sumBytes = 0atBinaryHttpParser.java:386.- It reads
methodLengthas alongatBinaryHttpParser.java:394. - It performs
sumBytes += methodLengthatBinaryHttpParser.java:395, narrowing the result toint. - If
methodLengthis2^31,sumByteswraps negative and bypassesif (sumBytes >= in.readableBytes()) return nullatBinaryHttpParser.java:396-398. - The parser then computes
schemeLengthIdx = in.readerIndex() + sumBytesand callsin.getByte(schemeLengthIdx)atBinaryHttpParser.java:401-402, producing a negative index exception.
The same pattern is present in header parsing:
readFieldLine(...)usesint sumBytesand addslong nameLength/long valueLengthatBinaryHttpParser.java:659-680.valueLengthIdx = nameIdx + (int) nameLengthatBinaryHttpParser.java:674can also overflow.
getIndeterminateLength(...) similarly uses int sumBytes and long possibleTerminator at BinaryHttpParser.java:544-553.
Proof of concept
Safe local verification performed in this repository. After compiling codec-bhttp, the following minimal verifier uses a 15-byte payload:
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.incubator.codec.bhttp.BinaryHttpParser;
public final class VerifyBhttpOverflow {
public static void main(String[] args) {
byte[] payload = new byte[] {
0x00, (byte)0xc0, 0x00, 0x00, 0x00, (byte)0x80, 0x00, 0x00, 0x00,
0x47, 0x45, 0x54, 0x58, 0x58, 0x58
};
ByteBuf input = Unpooled.wrappedBuffer(payload);
try {
new BinaryHttpParser(8192).parse(input, false);
System.out.println("returned");
} catch (Throwable t) {
System.out.println(t.getClass().getName());
System.out.println(t.getMessage());
}
}
}
Payload interpretation:
00: known-length request frame indicator.c000000080000000: valid 8-byte varint encoding of0x80000000(2^31) as the method length.474554585858: a few dummy bytes so the parser proceeds far enough to compute the next index.
Observed result:
java.lang.ArrayIndexOutOfBoundsException
Index -2147483639 out of bounds for length 15
The parser should reject the malformed/incomplete message with a controlled decoder exception or return null awaiting more bytes; it should not allow integer wraparound to reach unchecked buffer indexing.
Impact
A remote peer can trigger an unchecked exception in the Binary HTTP decoder using a tiny payload. In typical Netty pipelines this closes or fails the affected channel. Depending on application-level exception handling, repeated payloads can cause sustained denial of service for exposed BHTTP endpoints. No memory corruption or information disclosure was observed because the failure occurs in Java/Netty bounds checks.
Suggested remediation
- Use
longfor all cumulative byte counts derived from protocol lengths. - Before converting any protocol length to
int, verify it is non-negative, no larger thanInteger.MAX_VALUE, and no larger than available readable bytes and configured limits. - Replace
sumBytes >= in.readableBytes()checks with precise checked arithmetic that permits exact-boundary complete fields but rejects impossible lengths. - Throw a controlled
CorruptedFrameException/TooLongFrameExceptionfor invalid or unsupported lengths. - Add regression tests for 8-byte varint lengths at and above
Integer.MAX_VALUEin request control data, response control data, known and indeterminate field sections, and field lines.
References
codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:386-402codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:659-680codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:544-553- RFC 9292: Binary Representation of HTTP Messages
- RFC 9000 variable-length integer encoding
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.netty.incubator:netty-incubator-codec-bhttp | all versions | 0.0.23.Final |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty.incubator:netty-incubator-codec-bhttp. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update io.netty.incubator:netty-incubator-codec-bhttp to 0.0.23.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-61799 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-61799 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-61799. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-61799 in your dependencies?
O3 detects CVE-2026-61799 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.