Total
455 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-11896 | 2026-06-17 | N/A | N/A | ||
| In Xpdf 4.05 (and earlier), a PDF object loop in a CMap, via the "UseCMap" entry, leads to infinite recursion and a stack overflow. | |||||
| CVE-2025-10728 | 2026-06-17 | N/A | N/A | ||
| When the module renders a Svg file that contains a <pattern> element, it might end up rendering it recursively leading to stack overflow DoS | |||||
| CVE-2024-7866 | 1 Xpdfreader | 1 Xpdf | 2026-06-17 | N/A | 5.5 MEDIUM |
| In Xpdf 4.05 (and earlier), a PDF object loop in a pattern resource leads to infinite recursion and a stack overflow. | |||||
| CVE-2024-7254 | 2 Google, Netapp | 8 Protobuf, Protobuf-java, Protobuf-javalite and 5 more | 2026-06-17 | N/A | 7.5 HIGH |
| Any project that parses untrusted Protocol Buffers data containing an arbitrary number of nested groups / series of SGROUP tags can corrupted by exceeding the stack limit i.e. StackOverflow. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. | |||||
| CVE-2024-5971 | 2026-06-17 | N/A | 7.5 HIGH | ||
| A vulnerability was found in Undertow, where the chunked response hangs after the body was flushed. The response headers and body were sent but the client would continue waiting as Undertow does not send the expected 0\r\n termination of the chunked response. This results in uncontrolled resource consumption, leaving the server side to a denial of service attack. This happens only with Java 17 TLSv1.3 scenarios. | |||||
| CVE-2024-58264 | 1 Cosmwasm | 1 Serde-json-wasm | 2026-06-17 | N/A | 3.2 LOW |
| The serde-json-wasm crate before 1.0.1 for Rust allows stack consumption via deeply nested JSON data. | |||||
| CVE-2024-58103 | 2026-06-17 | N/A | 5.8 MEDIUM | ||
| Square Wire before 5.2.0 does not enforce a recursion limit on nested groups in ByteArrayProtoReader32.kt and ProtoReader.kt. | |||||
| CVE-2024-58102 | 1 Datalust | 1 Seq | 2026-06-17 | N/A | 5.7 MEDIUM |
| An issue was discovered in Datalust Seq before 2024.3.13545. An insecure default parsing depth limit allows stack consumption when parsing user-supplied queries containing deeply nested expressions. | |||||
| CVE-2024-57699 | 2026-06-17 | N/A | 7.5 HIGH | ||
| A security issue was found in Netplex Json-smart 2.5.0 through 2.5.1. When loading a specially crafted JSON input, containing a large number of ’{’, a stack exhaustion can be trigger, which could allow an attacker to cause a Denial of Service (DoS). This issue exists because of an incomplete fix for CVE-2023-1370. | |||||
| CVE-2024-57257 | 1 Denx | 1 U-boot | 2026-06-17 | N/A | 2.0 LOW |
| A stack consumption issue in sqfs_size in Das U-Boot before 2025.01-rc1 occurs via a crafted squashfs filesystem with deep symlink nesting. | |||||
| CVE-2024-54731 | 2026-06-17 | N/A | 4.0 MEDIUM | ||
| cpdf through 2.8 allows stack consumption via a crafted PDF document. | |||||
| CVE-2024-53090 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <TASK> dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> | |||||
| CVE-2024-4568 | 1 Xpdfreader | 1 Xpdf | 2026-06-17 | N/A | 2.9 LOW |
| In Xpdf 4.05 (and earlier), a PDF object loop in the PDF resources leads to infinite recursion and a stack overflow. | |||||
| CVE-2024-4340 | 2026-06-17 | N/A | 7.5 HIGH | ||
| Passing a heavily nested list to sqlparse.parse() leads to a Denial of Service due to RecursionError. | |||||
| CVE-2024-49363 | 2026-06-17 | N/A | 7.4 HIGH | ||
| Misskey is an open source, federated social media platform. In affected versions FileServerService (media proxy) in github.com/misskey-dev/misskey 2024.10.1 or earlier did not detect proxy loops, which allows remote actors to execute a self-propagating reflected/amplified distributed denial-of-service via a maliciously crafted note. FileServerService.prototype.proxyHandler did not check incoming requests are not coming from another proxy server. An attacker can execute an amplified denial-of-service by sending a nested proxy request to the server and end the request with a malicious redirect back to another nested proxy request. Leading to unbounded recursion until the original request is timed out. This issue has been addressed in version 2024.11.0-alpha.3. Users are advised to upgrade. Users unable to upgrade may configure the reverse proxy to block requests to the proxy with an empty User-Agent header or one containing Misskey/. An attacker can not effectively modify the User-Agent header without making another request to the server. | |||||
| CVE-2024-47831 | 1 Vercel | 1 Next.js | 2026-06-17 | N/A | 5.9 MEDIUM |
| Next.js is a React Framework for the Web. Cersions on the 10.x, 11.x, 12.x, 13.x, and 14.x branches before version 14.2.7 contain a vulnerability in the image optimization feature which allows for a potential Denial of Service (DoS) condition which could lead to excessive CPU consumption. Neither the `next.config.js` file that is configured with `images.unoptimized` set to `true` or `images.loader` set to a non-default value nor the Next.js application that is hosted on Vercel are affected. This issue was fully patched in Next.js `14.2.7`. As a workaround, ensure that the `next.config.js` file has either `images.unoptimized`, `images.loader` or `images.loaderFile` assigned. | |||||
| CVE-2024-44996 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: vsock: fix recursive ->recvmsg calls After a vsock socket has been added to a BPF sockmap, its prot->recvmsg has been replaced with vsock_bpf_recvmsg(). Thus the following recursiion could happen: vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() again We need to fix it by calling the original ->recvmsg() without any BPF sockmap logic in __vsock_recvmsg(). | |||||
| CVE-2024-44073 | 1 Rust-bitcoin | 1 Miniscript | 2026-06-17 | N/A | 7.5 HIGH |
| The Miniscript (aka rust-miniscript) library before 12.2.0 for Rust allows stack consumption because it does not properly track tree depth. | |||||
| CVE-2024-43414 | 1 Apollographql | 5 Apollo-router, Apollo Gateway, Apollo Helms-charts Router and 2 more | 2026-06-17 | N/A | 7.5 HIGH |
| Apollo Federation is an architecture for declaratively composing APIs into a unified graph. Each team can own their slice of the graph independently, empowering them to deliver autonomously and incrementally. Instances of @apollo/query-planner >=2.0.0 and <2.8.5 are impacted by a denial-of-service vulnerability. @apollo/gateway versions >=2.0.0 and < 2.8.5 and Apollo Router <1.52.1 are also impacted through their use of @apollo/query-panner. If @apollo/query-planner is asked to plan a sufficiently complex query, it may loop infinitely and never complete. This results in unbounded memory consumption and either a crash or out-of-memory (OOM) termination. This issue can be triggered if you have at least one non-@key field that can be resolved by multiple subgraphs. To identify these shared fields, the schema for each subgraph must be reviewed. The mechanism to identify shared fields varies based on the version of Federation your subgraphs are using. You can check if your subgraphs are using Federation 1 or Federation 2 by reviewing their schemas. Federation 2 subgraph schemas will contain a @link directive referencing the version of Federation being used while Federation 1 subgraphs will not. For example, in a Federation 2 subgraph, you will find a line like @link(url: "https://specs.apollo.dev/federation/v2.0"). If a similar @link directive is not present in your subgraph schema, it is using Federation 1. Note that a supergraph can contain a mix of Federation 1 and Federation 2 subgraphs. This issue results from the Apollo query planner attempting to use a Number exceeding Javascript’s Number.MAX_VALUE in some cases. In Javascript, Number.MAX_VALUE is (2^1024 - 2^971). When the query planner receives an inbound graphql request, it breaks the query into pieces and for each piece, generates a list of potential execution steps to solve the piece. These candidates represent the steps that the query planner will take to satisfy the pieces of the larger query. As part of normal operations, the query planner requires and calculates the number of possible query plans for the total query. That is, it needs the product of the number of query plan candidates for each piece of the query. Under normal circumstances, after generating all query plan candidates and calculating the number of all permutations, the query planner moves on to stack rank candidates and prune less-than-optimal options. In particularly complex queries, especially those where fields can be solved through multiple subgraphs, this can cause the number of all query plan permutations to balloon. In worst-case scenarios, this can end up being a number larger than Number.MAX_VALUE. In Javascript, if Number.MAX_VALUE is exceeded, Javascript represents the value as “infinity”. If the count of candidates is evaluated as infinity, the component of the query planner responsible for pruning less-than-optimal query plans does not actually prune candidates, causing the query planner to evaluate many orders of magnitude more query plan candidates than necessary. This issue has been addressed in @apollo/query-planner v2.8.5, @apollo/gateway v2.8.5, and Apollo Router v1.52.1. Users are advised to upgrade. This issue can be avoided by ensuring there are no fields resolvable from multiple subgraphs. If all subgraphs are using Federation 2, you can confirm that you are not impacted by ensuring that none of your subgraph schemas use the @shareable directive. If you are using Federation 1 subgraphs, you will need to validate that there are no fields resolvable by multiple subgraphs. | |||||
| CVE-2024-42369 | 1 Matrix | 1 Javascript Sdk | 2026-06-17 | N/A | 4.1 MEDIUM |
| matrix-js-sdk is a Matrix messaging protocol Client-Server SDK for JavaScript. A malicious homeserver can craft a room or room structure such that the predecessors form a cycle. The matrix-js-sdk's getRoomUpgradeHistory function will infinitely recurse in this case, causing the code to hang. This method is public but also called by the 'leaveRoomChain()' method, so leaving a room will also trigger the bug. This was patched in matrix-js-sdk 34.3.1. | |||||