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.
1253 vulnerabilities reference this CWE, most recent first.
GHSA-CM8F-H6J3-P25C
Vulnerability from github – Published: 2022-05-24 22:05 – Updated: 2023-08-29 23:32Impact
An attacker can send packets that will send Pion DTLS into an infinite loop when processing.
Patches
Upgrade to Pion DTLS v2.1.4
Workarounds
No workarounds available, upgrade to Pion DTLS v2.1.4
References
Thank you to Juho Nurminen and the Mattermost team for discovering and reporting this.
For more information
If you have any questions or comments about this advisory: * Open an issue in Pion DTLS * Email us at team@pion.ly
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/pion/dtls"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/pion/dtls/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-29190"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2022-05-24T22:05:00Z",
"nvd_published_at": "2022-05-21T00:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nAn attacker can send packets that will send Pion DTLS into an infinite loop when processing.\n\n### Patches\nUpgrade to Pion DTLS v2.1.4\n\n### Workarounds\nNo workarounds available, upgrade to Pion DTLS v2.1.4\n\n### References\nThank you to [Juho Nurminen](https://github.com/jupenur) and the Mattermost team for discovering and reporting this. \n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Pion DTLS](http://github.com/pion/dtls)\n* Email us at [team@pion.ly](mailto:team@pion.ly)\n",
"id": "GHSA-cm8f-h6j3-p25c",
"modified": "2023-08-29T23:32:40Z",
"published": "2022-05-24T22:05:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pion/dtls/security/advisories/GHSA-cm8f-h6j3-p25c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29190"
},
{
"type": "WEB",
"url": "https://github.com/pion/dtls/commit/e0b2ce3592e8e7d73713ac67b363a2e192a4cecf"
},
{
"type": "WEB",
"url": "https://github.com/pion/dtls/releases/tag/v2.1.4"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-0460"
},
{
"type": "PACKAGE",
"url": "github.com/pion/dtls"
}
],
"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": "Pion DTLS Header reconstruction method can be thrown into an infinite loop"
}
GHSA-CQ2J-HRGF-RXGP
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2024-03-21 03:34Unbound before 1.9.5 allows an infinite loop via a compressed name in dname_pkt_copy.
{
"affected": [],
"aliases": [
"CVE-2019-25040"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-27T06:15:00Z",
"severity": "HIGH"
},
"details": "Unbound before 1.9.5 allows an infinite loop via a compressed name in dname_pkt_copy.",
"id": "GHSA-cq2j-hrgf-rxgp",
"modified": "2024-03-21T03:34:04Z",
"published": "2022-05-24T17:48:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25040"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/05/msg00007.html"
},
{
"type": "WEB",
"url": "https://ostif.org/our-audit-of-unbound-dns-by-x41-d-sec-full-results"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210507-0007"
}
],
"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"
}
]
}
GHSA-CQ38-JH5F-37MQ
Vulnerability from github – Published: 2024-09-04 20:18 – Updated: 2024-09-04 21:34Impact
sigstore-go is susceptible to a denial of service attack when a verifier is provided a maliciously crafted Sigstore Bundle containing large amounts of verifiable data, in the form of signed transparency log entries, RFC 3161 timestamps, and attestation subjects. The verification of these data structures is computationally expensive. This can be used to consume excessive CPU resources, leading to a denial of service attack. TUF's security model labels this type of vulnerability an "Endless data attack," and can lead to verification failing to complete and disrupting services that rely on sigstore-go for verification.
The vulnerable loops are in the verification functions in the package github.com/sigstore/sigstore-go/pkg/verify. The first is the DSSE envelope verification loop in verifyEnvelopeWithArtifact, which decodes all the digests in an attestation can be found here:
https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/signature.go#L183-L193
The next loop is in the VerifyArtifactTransparencyLog function, which verifies all the signed entries in a bundle:
https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tlog.go#L74-L178
The next loop is the VerifyTimestampAuthority function, which verifies all the RFC 3161 timestamps in a bundle:
https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tsa.go#L59-L68
Patches
This vulnerability is addressed with sigstore-go 0.6.1, which adds hard limits to the number of verifiable data structures that can be processed in a bundle. Verification will fail if a bundle has data that exceeds these limits. The limits are:
- 32 signed transparency log entries
- 32 RFC 3161 timestamps
- 1024 attestation subjects
- 32 digests per attestation subject
These limits are intended to be high enough to accommodate the vast majority of use cases, while preventing the verification of maliciously crafted bundles that contain large amounts of verifiable data.
Workarounds
The best way to mitigate the risk is to upgrade to sigstore-go 0.6.1 or later. Users who are vulnerable but unable to quickly upgrade may consider adding manual bundle validation to enforce limits similar to those in the referenced patch prior to calling sigstore-go's verification functions.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.6.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/sigstore-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-45395"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-04T20:18:18Z",
"nvd_published_at": "2024-09-04T21:15:14Z",
"severity": "LOW"
},
"details": "### Impact\n\nsigstore-go is susceptible to a denial of service attack when a verifier is provided a maliciously crafted Sigstore Bundle containing large amounts of verifiable data, in the form of signed transparency log entries, RFC 3161 timestamps, and attestation subjects. The verification of these data structures is computationally expensive. This can be used to consume excessive CPU resources, leading to a denial of service attack. TUF\u0027s security model labels this type of vulnerability an \"Endless data attack,\" and can lead to verification failing to complete and disrupting services that rely on sigstore-go for verification.\n\nThe vulnerable loops are in the verification functions in the package `github.com/sigstore/sigstore-go/pkg/verify`. The first is the DSSE envelope verification loop in `verifyEnvelopeWithArtifact`, which decodes all the digests in an attestation can be found here:\n\nhttps://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/signature.go#L183-L193\n\nThe next loop is in the `VerifyArtifactTransparencyLog` function, which verifies all the signed entries in a bundle:\n\nhttps://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tlog.go#L74-L178\n\nThe next loop is the `VerifyTimestampAuthority` function, which verifies all the RFC 3161 timestamps in a bundle:\n\nhttps://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tsa.go#L59-L68\n\n### Patches\n\nThis vulnerability is addressed with sigstore-go 0.6.1, which adds hard limits to the number of verifiable data structures that can be processed in a bundle. Verification will fail if a bundle has data that exceeds these limits. The limits are:\n\n- 32 signed transparency log entries\n- 32 RFC 3161 timestamps\n- 1024 attestation subjects\n- 32 digests per attestation subject\n\nThese limits are intended to be high enough to accommodate the vast majority of use cases, while preventing the verification of maliciously crafted bundles that contain large amounts of verifiable data.\n\n### Workarounds\n\nThe best way to mitigate the risk is to upgrade to sigstore-go 0.6.1 or later. Users who are vulnerable but unable to quickly upgrade may consider adding manual bundle validation to enforce limits similar to those in the referenced patch prior to calling sigstore-go\u0027s verification functions.\n",
"id": "GHSA-cq38-jh5f-37mq",
"modified": "2024-09-04T21:34:54Z",
"published": "2024-09-04T20:18:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-go/security/advisories/GHSA-cq38-jh5f-37mq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45395"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-go/commit/01e70e89e58226286d7977b4dba43b6be472b12c"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/sigstore-go"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/signature.go#L183-L193"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tlog.go#L74-L178"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tsa.go#L59-L68"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "sigstore-go has an unbounded loop over untrusted input can lead to endless data attack"
}
GHSA-CQ9M-7482-XQ9J
Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2025-03-13 18:32In the Linux kernel, the following vulnerability has been resolved:
nvmet: Fix crash when a namespace is disabled
The namespace percpu counter protects pending I/O, and we can only safely diable the namespace once the counter drop to zero. Otherwise we end up with a crash when running blktests/nvme/058 (eg for loop transport):
[ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI [ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232 [ 2352.930438] [ T53909] Tainted: [W]=WARN [ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 2352.930443] [ T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] [ 2352.930449] [ T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180
as the queue is already torn down when calling submit_bio();
So we need to init the percpu counter in nvmet_ns_enable(), and wait for it to drop to zero in nvmet_ns_disable() to avoid having I/O pending after the namespace has been disabled.
{
"affected": [],
"aliases": [
"CVE-2025-21850"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T10:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: Fix crash when a namespace is disabled\n\nThe namespace percpu counter protects pending I/O, and we can\nonly safely diable the namespace once the counter drop to zero.\nOtherwise we end up with a crash when running blktests/nvme/058\n(eg for loop transport):\n\n[ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI\n[ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n[ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232\n[ 2352.930438] [ T53909] Tainted: [W]=WARN\n[ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014\n[ 2352.930443] [ T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]\n[ 2352.930449] [ T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180\n\nas the queue is already torn down when calling submit_bio();\n\nSo we need to init the percpu counter in nvmet_ns_enable(), and\nwait for it to drop to zero in nvmet_ns_disable() to avoid having\nI/O pending after the namespace has been disabled.",
"id": "GHSA-cq9m-7482-xq9j",
"modified": "2025-03-13T18:32:21Z",
"published": "2025-03-12T12:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21850"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4082326807072b71496501b6a0c55ffe8d5092a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc0607594f6813342b27c752c6fb6f6eb9980cb5"
}
],
"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-CQC3-8MFM-84P4
Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2024-07-23 15:31In the Linux kernel, the following vulnerability has been resolved:
vhost: fix hung thread due to erroneous iotlb entries
In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous entry.
Call Trace:
<TASK>
iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340
vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366
vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104
vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372
kthread+0x2e9/0x3a0 kernel/kthread.c:377
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
</TASK>
Reported by syzbot at: https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87
To fix this, do two things:
- Return -EINVAL in vhost_chr_write_iter() when userspace asks to map a range with size 0.
- Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries.
{
"affected": [],
"aliases": [
"CVE-2022-48862"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T13:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvhost: fix hung thread due to erroneous iotlb entries\n\nIn vhost_iotlb_add_range_ctx(), range size can overflow to 0 when\nstart is 0 and last is ULONG_MAX. One instance where it can happen\nis when userspace sends an IOTLB message with iova=size=uaddr=0\n(vhost_process_iotlb_msg). So, an entry with size = 0, start = 0,\nlast = ULONG_MAX ends up in the iotlb. Next time a packet is sent,\niotlb_access_ok() loops indefinitely due to that erroneous entry.\n\n\tCall Trace:\n\t \u003cTASK\u003e\n\t iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340\n\t vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366\n\t vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104\n\t vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372\n\t kthread+0x2e9/0x3a0 kernel/kthread.c:377\n\t ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295\n\t \u003c/TASK\u003e\n\nReported by syzbot at:\n\thttps://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87\n\nTo fix this, do two things:\n\n1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map\n a range with size 0.\n2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX]\n by splitting it into two entries.",
"id": "GHSA-cqc3-8mfm-84p4",
"modified": "2024-07-23T15:31:08Z",
"published": "2024-07-16T15:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48862"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1"
}
],
"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-CQGH-8P3P-MX4M
Vulnerability from github – Published: 2026-10-07 20:42 – Updated: 2026-10-07 20:42Summary
com.rabbitmq.tools.json.JSONReader.read() never returns when its input ends inside a quoted string or a // line comment. Both scanners walk the input with StringCharacterIterator.next() but only compare against a delimiter, so once the iterator reaches CharacterIterator.DONE () they loop forever. The string scanner (string(), line 210, while (c != sep)) also appends to a StringBuilder every iteration, so it fills the heap and throws OutOfMemoryError, taking down the JVM. The comment scanner (skipWhiteSpace(), lines 89-92, while (c != '\n')) pins a thread at 100% CPU with no allocation.
This is reachable with a single message. JsonRpcServer and JsonRpcClient fall back to DefaultJsonRpcMapper whenever no mapper is passed (JsonRpcServer.java:84 and :114, JsonRpcClient.java:186), and that mapper hands the raw message body straight to JSONReader.read() (DefaultJsonRpcMapper.java:42 for the server request, :52 for the client reply). A caller that can publish to the RPC request queue hangs the server; a malicious or MITM'd JSON-RPC service does the same to a client.
Proof of concept
Against amqp-client 5.36.0 from Maven Central:
import com.rabbitmq.tools.jsonrpc.DefaultJsonRpcMapper;
public class Poc {
public static void main(String[] args) {
DefaultJsonRpcMapper mapper = new DefaultJsonRpcMapper();
mapper.parse("{\"method\":\"x", String.class); // unterminated string
// mapper.parse("//", String.class); // unterminated // comment
System.out.println("unreachable");
}
}
java -Xmx64m -cp amqp-client-5.36.0.jar:. Poc throws OutOfMemoryError: Java heap space in about 0.1s and never prints. Swapping in the // line spins at 100% CPU and never returns. A well-formed body such as {"method":"x"} returns immediately.
Impact
Availability. One small, unauthenticated message stops a JSON-RPC endpoint: the unterminated string exhausts the heap, the unterminated comment pins a thread forever. Neither is recoverable per request - JsonRpcServer.doCall only catches ClassCastException, and an OutOfMemoryError affects the whole process.
Scope and fix
Only applications using the JSON-RPC-over-AMQP tooling (com.rabbitmq.tools.jsonrpc) with the default DefaultJsonRpcMapper are affected. DefaultJsonRpcMapper and JSONReader are deprecated in favour of JacksonJsonRpcMapper, but both still ship and remain the default when no mapper is supplied. The fix is to stop both loops at CharacterIterator.DONE.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.36.0"
},
"package": {
"ecosystem": "Maven",
"name": "com.rabbitmq:amqp-client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.36.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106121"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:42:33Z",
"nvd_published_at": "2026-10-06T19:17:43Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`com.rabbitmq.tools.json.JSONReader.read()` never returns when its input ends inside a quoted string or a `//` line comment. Both scanners walk the input with `StringCharacterIterator.next()` but only compare against a delimiter, so once the iterator reaches `CharacterIterator.DONE` (`\uffff`) they loop forever. The string scanner (`string()`, line 210, `while (c != sep)`) also appends `\uffff` to a `StringBuilder` every iteration, so it fills the heap and throws `OutOfMemoryError`, taking down the JVM. The comment scanner (`skipWhiteSpace()`, lines 89-92, `while (c != \u0027\\n\u0027)`) pins a thread at 100% CPU with no allocation.\n\nThis is reachable with a single message. `JsonRpcServer` and `JsonRpcClient` fall back to `DefaultJsonRpcMapper` whenever no mapper is passed (`JsonRpcServer.java:84` and `:114`, `JsonRpcClient.java:186`), and that mapper hands the raw message body straight to `JSONReader.read()` (`DefaultJsonRpcMapper.java:42` for the server request, `:52` for the client reply). A caller that can publish to the RPC request queue hangs the server; a malicious or MITM\u0027d JSON-RPC service does the same to a client.\n\n## Proof of concept\n\nAgainst `amqp-client` 5.36.0 from Maven Central:\n\n```java\nimport com.rabbitmq.tools.jsonrpc.DefaultJsonRpcMapper;\n\npublic class Poc {\n public static void main(String[] args) {\n DefaultJsonRpcMapper mapper = new DefaultJsonRpcMapper();\n mapper.parse(\"{\\\"method\\\":\\\"x\", String.class); // unterminated string\n // mapper.parse(\"//\", String.class); // unterminated // comment\n System.out.println(\"unreachable\");\n }\n}\n```\n\n`java -Xmx64m -cp amqp-client-5.36.0.jar:. Poc` throws `OutOfMemoryError: Java heap space` in about 0.1s and never prints. Swapping in the `//` line spins at 100% CPU and never returns. A well-formed body such as `{\"method\":\"x\"}` returns immediately.\n\n## Impact\n\nAvailability. One small, unauthenticated message stops a JSON-RPC endpoint: the unterminated string exhausts the heap, the unterminated comment pins a thread forever. Neither is recoverable per request - `JsonRpcServer.doCall` only catches `ClassCastException`, and an `OutOfMemoryError` affects the whole process.\n\n## Scope and fix\n\nOnly applications using the JSON-RPC-over-AMQP tooling (`com.rabbitmq.tools.jsonrpc`) with the default `DefaultJsonRpcMapper` are affected. `DefaultJsonRpcMapper` and `JSONReader` are deprecated in favour of `JacksonJsonRpcMapper`, but both still ship and remain the default when no mapper is supplied. The fix is to stop both loops at `CharacterIterator.DONE`.",
"id": "GHSA-cqgh-8p3p-mx4m",
"modified": "2026-10-07T20:42:33Z",
"published": "2026-10-07T20:42:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/security/advisories/GHSA-cqgh-8p3p-mx4m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106121"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/pull/2100"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/25fad817291feff3195c32620117d295598f8b41"
},
{
"type": "PACKAGE",
"url": "https://github.com/rabbitmq/rabbitmq-java-client"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/releases/tag/v5.37.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "RabbitMQ: JSONReader in the default JSON-RPC mapper never terminates on truncated input, causing DoS"
}
GHSA-CW22-F535-MJJW
Vulnerability from github – Published: 2026-08-17 18:31 – Updated: 2026-08-17 18:31In JetBrains Ktor before 3.4.1 potential DoS attack via WebSocket decompression was possible
{
"affected": [],
"aliases": [
"CVE-2026-68762"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-17T16:17:30Z",
"severity": "MODERATE"
},
"details": "In JetBrains Ktor before 3.4.1 potential DoS attack via WebSocket decompression was possible",
"id": "GHSA-cw22-f535-mjjw",
"modified": "2026-08-17T18:31:17Z",
"published": "2026-08-17T18:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68762"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CW9G-QWF2-42HW
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10In Contiki 3.0, potential nonterminating acknowledgment loops exist in the Telnet service. When the negotiated options are already disabled, servers still respond to DONT and WONT requests with WONT or DONT commands, which may lead to infinite acknowledgment loops, denial of service, and excessive CPU consumption.
{
"affected": [],
"aliases": [
"CVE-2021-38311"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-09T22:15:00Z",
"severity": "HIGH"
},
"details": "In Contiki 3.0, potential nonterminating acknowledgment loops exist in the Telnet service. When the negotiated options are already disabled, servers still respond to DONT and WONT requests with WONT or DONT commands, which may lead to infinite acknowledgment loops, denial of service, and excessive CPU consumption.",
"id": "GHSA-cw9g-qwf2-42hw",
"modified": "2022-05-24T19:10:37Z",
"published": "2022-05-24T19:10:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38311"
},
{
"type": "WEB",
"url": "https://github.com/contiki-os/contiki/issues/2685"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CWV3-863G-39VX
Vulnerability from github – Published: 2021-05-21 14:26 – Updated: 2024-10-31 21:22Impact
TFlite graphs must not have loops between nodes. However, this condition was not checked and an attacker could craft models that would result in infinite loop during evaluation. In certain cases, the infinite loop would be replaced by stack overflow due to too many recursive calls.
For example, the While implementation could be tricked into a scneario where both the body and the loop subgraphs are the same. Evaluating one of the subgraphs means calling the Eval function for the other and this quickly exhaust all stack space.
Patches
We have patched the issue in GitHub commit 9c1dc920d8ffb4893d6c9d27d1f039607b326743 (for the While operator) and in GitHub commit c6173f5fe66cdbab74f4f869311fe6aae2ba35f4 (in general).
The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.
For more information
Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.
Attribution
This vulnerability has been reported by members of the Aivul Team from Qihoo 360.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-29591"
],
"database_specific": {
"cwe_ids": [
"CWE-674",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-18T16:46:07Z",
"nvd_published_at": "2021-05-14T20:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nTFlite graphs must not have loops between nodes. However, this condition was not checked and an attacker could craft models that would result in infinite loop during evaluation. In certain cases, the infinite loop would be replaced by stack overflow due to too many recursive calls.\n\nFor example, the [`While` implementation](https://github.com/tensorflow/tensorflow/blob/106d8f4fb89335a2c52d7c895b7a7485465ca8d9/tensorflow/lite/kernels/while.cc) could be tricked into a scneario where both the body and the loop subgraphs are the same. Evaluating one of the subgraphs means calling the `Eval` function for the other and this quickly exhaust all stack space.\n \n### Patches \nWe have patched the issue in GitHub commit [9c1dc920d8ffb4893d6c9d27d1f039607b326743](https://github.com/tensorflow/tensorflow/commit/9c1dc920d8ffb4893d6c9d27d1f039607b326743) (for the `While` operator) and in GitHub commit [c6173f5fe66cdbab74f4f869311fe6aae2ba35f4](https://github.com/tensorflow/tensorflow/commit/c6173f5fe66cdbab74f4f869311fe6aae2ba35f4) (in general).\n \nThe fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution \nThis vulnerability has been reported by members of the Aivul Team from Qihoo 360.",
"id": "GHSA-cwv3-863g-39vx",
"modified": "2024-10-31T21:22:52Z",
"published": "2021-05-21T14:26:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-cwv3-863g-39vx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29591"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/9c1dc920d8ffb4893d6c9d27d1f039607b326743"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/c6173f5fe66cdbab74f4f869311fe6aae2ba35f4"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-519.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-717.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-228.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorflow/tensorflow"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/blob/106d8f4fb89335a2c52d7c895b7a7485465ca8d9/tensorflow/lite/kernels/while.cc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Stack overflow due to looping TFLite subgraph"
}
GHSA-CXQW-29JQ-PCJV
Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2022-05-24 17:44A vulnerability has been identified in SIMATIC S7-PLCSIM V5.4 (All versions). An attacker with local access to the system could cause a Denial-of-Service condition in the application when it is used to open a specially crafted file. As a consequence, the application could enter an infinite loop, become unresponsive and must be restarted to restore the service.
{
"affected": [],
"aliases": [
"CVE-2021-25673"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-15T17:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been identified in SIMATIC S7-PLCSIM V5.4 (All versions). An attacker with local access to the system could cause a Denial-of-Service condition in the application when it is used to open a specially crafted file. As a consequence, the application could enter an infinite loop, become unresponsive and must be restarted to restore the service.",
"id": "GHSA-cxqw-29jq-pcjv",
"modified": "2022-05-24T17:44:34Z",
"published": "2022-05-24T17:44:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25673"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-256092.pdf"
}
],
"schema_version": "1.4.0",
"severity": []
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.