Common Weakness Enumeration
CWE-835
AllowedLoop with Unreachable Exit Condition ('Infinite Loop')
Abstraction: Base · Status: Incomplete
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
1144 vulnerabilities reference this CWE, most recent first.
GHSA-87MJ-5GGW-8QC3
Vulnerability from github – Published: 2026-03-25 20:05 – Updated: 2026-03-27 21:36
VLAI
Summary
pypdf: Possible infinite loop during recovery attempts in DictionaryObject.read_from_stream
Details
Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires reading a file in non-strict mode.
Patches
This has been fixed in pypdf==6.9.2.
Workarounds
If users cannot upgrade yet, consider applying the changes from PR #3693.
Severity
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pypdf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.9.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33699"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-25T20:05:22Z",
"nvd_published_at": "2026-03-27T01:16:19Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nAn attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires reading a file in non-strict mode.\n\n### Patches\n\nThis has been fixed in [pypdf==6.9.2](https://github.com/py-pdf/pypdf/releases/tag/6.9.2).\n\n### Workarounds\n\nIf users cannot upgrade yet, consider applying the changes from PR [#3693](https://github.com/py-pdf/pypdf/pull/3693).",
"id": "GHSA-87mj-5ggw-8qc3",
"modified": "2026-03-27T21:36:43Z",
"published": "2026-03-25T20:05:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-87mj-5ggw-8qc3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33699"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/pull/3693"
},
{
"type": "PACKAGE",
"url": "https://github.com/py-pdf/pypdf"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/releases/tag/6.9.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "pypdf: Possible infinite loop during recovery attempts in DictionaryObject.read_from_stream"
}
GHSA-88PH-HFRW-CHFM
Vulnerability from github – Published: 2024-04-30 00:30 – Updated: 2024-07-03 18:37
VLAI
Details
Open Networking Foundation SD-RAN ONOS onos-ric-sdk-go 0.8.12 allows infinite repetition of the processing of an error (in the Subscribe function implementation for the subscribed indication stream).
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2023-52726"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-30T00:15:07Z",
"severity": "MODERATE"
},
"details": "Open Networking Foundation SD-RAN ONOS onos-ric-sdk-go 0.8.12 allows infinite repetition of the processing of an error (in the Subscribe function implementation for the subscribed indication stream).",
"id": "GHSA-88ph-hfrw-chfm",
"modified": "2024-07-03T18:37:35Z",
"published": "2024-04-30T00:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52726"
},
{
"type": "WEB",
"url": "https://github.com/onosproject/onos-ric-sdk-go/issues/133"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-88V7-976W-9HC8
Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-12 00:00
VLAI
Details
In HTMLDOC 1.9.14, an infinite loop in the gif_read_lzw function can lead to a pointer arbitrarily pointing to heap memory and resulting in a buffer overflow.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2022-24191"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-04T11:15:00Z",
"severity": "MODERATE"
},
"details": "In HTMLDOC 1.9.14, an infinite loop in the gif_read_lzw function can lead to a pointer arbitrarily pointing to heap memory and resulting in a buffer overflow.",
"id": "GHSA-88v7-976w-9hc8",
"modified": "2022-04-12T00:00:58Z",
"published": "2022-04-05T00:00:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24191"
},
{
"type": "WEB",
"url": "https://github.com/michaelrsweet/htmldoc/issues/470"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6RPDZLHOMPSA2LBXXFTZ5UADZWGYYWH7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-88XM-3GM8-P46C
Vulnerability from github – Published: 2026-02-10 18:30 – Updated: 2026-02-10 18:30
VLAI
Details
Loop with unreachable exit condition ('infinite loop') for some Intel(R) Platform within Ring 0: Kernel may allow a denial of service. System software adversary with a privileged user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.
Severity
6.0 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-27560"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-10T17:16:14Z",
"severity": "MODERATE"
},
"details": "Loop with unreachable exit condition (\u0027infinite loop\u0027) for some Intel(R) Platform within Ring 0: Kernel may allow a denial of service. System software adversary with a privileged user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.",
"id": "GHSA-88xm-3gm8-p46c",
"modified": "2026-02-10T18:30:40Z",
"published": "2026-02-10T18:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27560"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01401.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-899C-QVC8-9HPP
Vulnerability from github – Published: 2024-08-07 18:30 – Updated: 2025-11-04 00:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up.
Neil suggested:
This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request().
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-42246"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-07T16:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket\n\nWhen using a BPF program on kernel_connect(), the call can return -EPERM. This\ncauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causing\nthe kernel to potentially freeze up.\n\nNeil suggested:\n\n This will propagate -EPERM up into other layers which might not be ready\n to handle it. It might be safer to map EPERM to an error we would be more\n likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.\n\nECONNREFUSED as error seems reasonable. For programs setting a different error\ncan be out of reach (see handling in 4fbac77d2d09) in particular on kernels\nwhich do not have f10d05966196 (\"bpf: Make BPF_PROG_RUN_ARRAY return -err\ninstead of allow boolean\"), thus given that it is better to simply remap for\nconsistent behavior. UDP does handle EPERM in xs_udp_send_request().",
"id": "GHSA-899c-qvc8-9hpp",
"modified": "2025-11-04T00:31:11Z",
"published": "2024-08-07T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42246"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/02ee1976edb21a96ce8e3fd4ef563f14cc16d041"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d8254e012996cee1a0f9cc920531cb7e4d9a011"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/626dfed5fa3bfb41e0dffd796032b555b69f9cde"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/934247ea65bc5eca8bdb7f8c0ddc15cef992a5d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc790261218952635f846aaf90bcc0974f6f62c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d6c686c01c5f12ff8f7264e0ddf71df6cb0d4414"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f2431e7db0fe0daccb2f06bb0d23740affcd2fa6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f388cfd913a2b96c05339a335f365795db1b36b6"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8C9G-77VH-M2JV
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-11-21 21:30
VLAI
Details
A flaw was found in the Linux kernel's implementation of biovecs in versions before 5.9-rc7. A zero-length biovec request issued by the block subsystem could cause the kernel to enter an infinite loop, causing a denial of service. This flaw allows a local attacker with basic privileges to issue requests to a block device, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2020-25641"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-06T14:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the Linux kernel\u0027s implementation of biovecs in versions before 5.9-rc7. A zero-length biovec request issued by the block subsystem could cause the kernel to enter an infinite loop, causing a denial of service. This flaw allows a local attacker with basic privileges to issue requests to a block device, resulting in a denial of service. The highest threat from this vulnerability is to system availability.",
"id": "GHSA-8c9g-77vh-m2jv",
"modified": "2022-11-21T21:30:17Z",
"published": "2022-05-24T17:30:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25641"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1881424"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e24969022cbd61ddc586f14824fc205661bb124"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00032.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00034.html"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4576-1"
},
{
"type": "WEB",
"url": "https://www.kernel.org/doc/html/latest/block/biovecs.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00021.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00042.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/10/06/9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8CFX-WX3Q-MH5Q
Vulnerability from github – Published: 2026-08-20 18:43 – Updated: 2026-08-20 18:43
VLAI
Summary
netty-incubator-codec-ohttp: Binary HTTP parser infinite loop on known-length field section boundary
Details
Summary
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 enterswhile (fieldSectionLength != 0)atBinaryHttpParser.java:619.- Inside the loop, it records
readableBytes, callsreadFieldLine(...), computesread = readableBytes - in.readableBytes(), assertsread > 0, and subtractsreadfromfieldSectionLengthatBinaryHttpParser.java:620-625. readFieldLine(...)returnsnullwithout consuming bytes when the field line ends exactly at the end of the readable slice because it usesif (sumBytes >= in.readableBytes()) return nullafter adding the value length (BinaryHttpParser.java:678-681).- With JVM assertions disabled (the production default),
assert read > 0is not active. The parser therefore subtracts zero forever and never returns.
The boundary condition is reachable with a valid known-length field section containing exactly one complete field line and no extra byte after that line. Example field section: length 4, then name length 1, name a, value length 1, value b.
Proof of concept
Safe local verification performed in this repository:
- Compile the module and classpath:
./mvnw -q -pl codec-bhttp -am compile test-compile
./mvnw -q -pl codec-bhttp dependency:build-classpath -Dmdep.outputFile=/tmp/codec-bhttp-cp.txt
printf '%s' "codec-bhttp/target/classes:$(cat /tmp/codec-bhttp-cp.txt)" > /tmp/codec-bhttp-run-cp.txt
- Compile and run this minimal verifier with production-style assertions disabled:
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.incubator.codec.bhttp.BinaryHttpParser;
import io.netty.incubator.codec.bhttp.VarIntCodecUtils;
import java.nio.charset.StandardCharsets;
public final class VerifyBhttpHang {
private static void writeAscii(ByteBuf out, String value) {
VarIntCodecUtils.writeVariableLengthInteger(out, value.length());
out.writeCharSequence(value, StandardCharsets.US_ASCII);
}
public static void main(String[] args) {
ByteBuf buffer = Unpooled.buffer();
VarIntCodecUtils.writeVariableLengthInteger(buffer, 0); // known-length request
writeAscii(buffer, "GET");
writeAscii(buffer, "https");
writeAscii(buffer, "example.com");
writeAscii(buffer, "/");
VarIntCodecUtils.writeVariableLengthInteger(buffer, 4); // field section length
writeAscii(buffer, "a");
writeAscii(buffer, "b");
new BinaryHttpParser(8192).parse(buffer, false);
System.out.println("returned");
}
}
Execution result observed locally:
timeout 3 java -cp "/tmp:$(cat /tmp/codec-bhttp-run-cp.txt)" VerifyBhttpHang
exit=124
Exit code 124 from timeout confirms the parser did not return within three seconds. When assertions are enabled by Surefire, the same payload fails at BinaryHttpParser.java:622 (assert read > 0), confirming the non-progress condition.
Impact
A peer that can deliver crafted BHTTP bytes can cause the parser to loop forever. In Netty deployments this can pin the event-loop thread or worker responsible for the channel, reducing or eliminating availability for other channels on the same event loop. Through OHTTP, the same parser is used after successful decryption of protected payloads, so authenticated/decryptable OHTTP peers can trigger the same condition in the inner BHTTP parser.
Suggested remediation
- Treat
readFieldLine(...) == nullas incomplete input and returnnullfromreadFieldSection(...)instead of continuing. - Replace boundary checks in
readFieldLine(...)that require an extra byte after a complete field line. A complete field line ending exactly at the known field-section boundary should be accepted. - Add a production runtime guard that throws a controlled decoder exception if a parser loop iteration makes no progress.
- Add regression tests with JVM assertions disabled for known-length header and trailer field sections that end exactly at the field-section boundary.
References
codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:619-625codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:678-681- RFC 9292: Binary Representation of HTTP Messages
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.0.22.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty.incubator:netty-incubator-codec-bhttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.23.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-63124"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T18:43:25Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\n`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.\n\n## Details\n\nIn `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:\n\n- `readFieldSection(...)` parses the known-length field section and enters `while (fieldSectionLength != 0)` at `BinaryHttpParser.java:619`.\n- Inside the loop, it records `readableBytes`, calls `readFieldLine(...)`, computes `read = readableBytes - in.readableBytes()`, asserts `read \u003e 0`, and subtracts `read` from `fieldSectionLength` at `BinaryHttpParser.java:620-625`.\n- `readFieldLine(...)` returns `null` without consuming bytes when the field line ends exactly at the end of the readable slice because it uses `if (sumBytes \u003e= in.readableBytes()) return null` after adding the value length (`BinaryHttpParser.java:678-681`).\n- With JVM assertions disabled (the production default), `assert read \u003e 0` is not active. The parser therefore subtracts zero forever and never returns.\n\nThe boundary condition is reachable with a valid known-length field section containing exactly one complete field line and no extra byte after that line. Example field section: length `4`, then name length `1`, name `a`, value length `1`, value `b`.\n\n## Proof of concept\n\nSafe local verification performed in this repository:\n\n1. Compile the module and classpath:\n\n```bash\n./mvnw -q -pl codec-bhttp -am compile test-compile\n./mvnw -q -pl codec-bhttp dependency:build-classpath -Dmdep.outputFile=/tmp/codec-bhttp-cp.txt\nprintf \u0027%s\u0027 \"codec-bhttp/target/classes:$(cat /tmp/codec-bhttp-cp.txt)\" \u003e /tmp/codec-bhttp-run-cp.txt\n```\n\n2. Compile and run this minimal verifier with production-style assertions disabled:\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.buffer.Unpooled;\nimport io.netty.incubator.codec.bhttp.BinaryHttpParser;\nimport io.netty.incubator.codec.bhttp.VarIntCodecUtils;\nimport java.nio.charset.StandardCharsets;\n\npublic final class VerifyBhttpHang {\n private static void writeAscii(ByteBuf out, String value) {\n VarIntCodecUtils.writeVariableLengthInteger(out, value.length());\n out.writeCharSequence(value, StandardCharsets.US_ASCII);\n }\n public static void main(String[] args) {\n ByteBuf buffer = Unpooled.buffer();\n VarIntCodecUtils.writeVariableLengthInteger(buffer, 0); // known-length request\n writeAscii(buffer, \"GET\");\n writeAscii(buffer, \"https\");\n writeAscii(buffer, \"example.com\");\n writeAscii(buffer, \"/\");\n VarIntCodecUtils.writeVariableLengthInteger(buffer, 4); // field section length\n writeAscii(buffer, \"a\");\n writeAscii(buffer, \"b\");\n new BinaryHttpParser(8192).parse(buffer, false);\n System.out.println(\"returned\");\n }\n}\n```\n\nExecution result observed locally:\n\n```text\ntimeout 3 java -cp \"/tmp:$(cat /tmp/codec-bhttp-run-cp.txt)\" VerifyBhttpHang\nexit=124\n```\n\nExit code `124` from `timeout` confirms the parser did not return within three seconds. When assertions are enabled by Surefire, the same payload fails at `BinaryHttpParser.java:622` (`assert read \u003e 0`), confirming the non-progress condition.\n\n## Impact\n\nA peer that can deliver crafted BHTTP bytes can cause the parser to loop forever. In Netty deployments this can pin the event-loop thread or worker responsible for the channel, reducing or eliminating availability for other channels on the same event loop. Through OHTTP, the same parser is used after successful decryption of protected payloads, so authenticated/decryptable OHTTP peers can trigger the same condition in the inner BHTTP parser.\n\n## Suggested remediation\n\n- Treat `readFieldLine(...) == null` as incomplete input and return `null` from `readFieldSection(...)` instead of continuing.\n- Replace boundary checks in `readFieldLine(...)` that require an extra byte after a complete field line. A complete field line ending exactly at the known field-section boundary should be accepted.\n- Add a production runtime guard that throws a controlled decoder exception if a parser loop iteration makes no progress.\n- Add regression tests with JVM assertions disabled for known-length header and trailer field sections that end exactly at the field-section boundary.\n\n## References\n\n- `codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:619-625`\n- `codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:678-681`\n- RFC 9292: Binary Representation of HTTP Messages",
"id": "GHSA-8cfx-wx3q-mh5q",
"modified": "2026-08-20T18:43:25Z",
"published": "2026-08-20T18:43:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty-incubator-codec-ohttp/security/advisories/GHSA-8cfx-wx3q-mh5q"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty-incubator-codec-ohttp"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty-incubator-codec-ohttp/releases/tag/netty-incubator-codec-parent-ohttp-0.0.23.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "netty-incubator-codec-ohttp: Binary HTTP parser infinite loop on known-length field section boundary"
}
GHSA-8G7P-JF3G-GXCP
Vulnerability from github – Published: 2026-03-23 06:30 – Updated: 2026-07-21 13:42
VLAI
Summary
jsrsasign is vulnerable to DoS through Infinite Loop when processing zero or negative inputs
Details
Versions of the package jsrsasign before 11.1.1 are vulnerable to Infinite loop via the bnModInverse function in ext/jsbn2.js when the BigInteger.modInverse implementation receives zero or negative inputs, allowing an attacker to hang the process permanently by supplying such crafted values (e.g., modInverse(0, m) or modInverse(-1, m)).
Severity
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "jsrsasign"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-4598"
],
"database_specific": {
"cwe_ids": [
"CWE-1287",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-29T15:51:28Z",
"nvd_published_at": "2026-03-23T06:16:21Z",
"severity": "HIGH"
},
"details": "Versions of the package jsrsasign before 11.1.1 are vulnerable to Infinite loop via the bnModInverse function in ext/jsbn2.js when the BigInteger.modInverse implementation receives zero or negative inputs, allowing an attacker to hang the process permanently by supplying such crafted values (e.g., modInverse(0, m) or modInverse(-1, m)).",
"id": "GHSA-8g7p-jf3g-gxcp",
"modified": "2026-07-21T13:42:15Z",
"published": "2026-03-23T06:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4598"
},
{
"type": "WEB",
"url": "https://github.com/kjur/jsrsasign/pull/648"
},
{
"type": "WEB",
"url": "https://github.com/kjur/jsrsasign/commit/ca5b027240287a1e71fe63019fc4400332594323"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JS-JSRSASIGN-15370938"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-15812263"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-4598.json"
},
{
"type": "PACKAGE",
"url": "https://github.com/kjur/jsrsasign"
},
{
"type": "WEB",
"url": "https://gist.github.com/Kr0emer/a1bf5cd4547cc630d2dcc5e761de8264"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2450210"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-4598"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6720"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6568"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23361"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22840"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19410"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19409"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19375"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "jsrsasign is vulnerable to DoS through Infinite Loop when processing zero or negative inputs"
}
GHSA-8G9J-VP2C-MG7R
Vulnerability from github – Published: 2022-05-13 01:52 – Updated: 2022-05-13 01:52
VLAI
Details
The AP4_FtypAtom class in Core/Ap4FtypAtom.cpp in Bento4 1.5.1.0 has an Infinite loop via a crafted MP4 file that triggers size mishandling.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2018-5253"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-05T21:29:00Z",
"severity": "HIGH"
},
"details": "The AP4_FtypAtom class in Core/Ap4FtypAtom.cpp in Bento4 1.5.1.0 has an Infinite loop via a crafted MP4 file that triggers size mishandling.",
"id": "GHSA-8g9j-vp2c-mg7r",
"modified": "2022-05-13T01:52:45Z",
"published": "2022-05-13T01:52:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5253"
},
{
"type": "WEB",
"url": "https://github.com/axiomatic-systems/Bento4/issues/233"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8H93-38HX-VV92
Vulnerability from github – Published: 2025-06-07 09:30 – Updated: 2025-06-09 15:31
VLAI
Details
Due to a mistake in libcurl's WebSocket code, a malicious server can send a particularly crafted packet which makes libcurl get trapped in an endless busy-loop.
There is no other way for the application to escape or exit this loop other than killing the thread/process.
This might be used to DoS libcurl-using application.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2025-5399"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-07T08:15:20Z",
"severity": "HIGH"
},
"details": "Due to a mistake in libcurl\u0027s WebSocket code, a malicious server can send a\nparticularly crafted packet which makes libcurl get trapped in an endless\nbusy-loop.\n\nThere is no other way for the application to escape or exit this loop other\nthan killing the thread/process.\n\nThis might be used to DoS libcurl-using application.",
"id": "GHSA-8h93-38hx-vv92",
"modified": "2025-06-09T15:31:41Z",
"published": "2025-06-07T09:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5399"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3168039"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2025-5399.html"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2025-5399.json"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/06/04/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.