Export limit exceeded: 14561 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (820 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-71393 | 1 Surrealdb | 1 Surrealdb | 2026-07-28 | N/A |
| SurrealDB before 2.2.2 with scripting enabled fails to properly enforce recursion limits when native functions contain embedded JavaScript that issues new queries. Authenticated attackers can bypass the recursion limit by chaining native and JavaScript function calls to trigger infinite recursion and exhaust server memory. | ||||
| CVE-2024-58370 | 1 Surrealdb | 1 Surrealdb | 2026-07-28 | 6.5 Medium |
| SurrealDB versions before 1.1.0 fail to enforce recursion depth limits when parsing nested SurrealQL statements including IF, RELATE, and attribute access idioms. Authorized attackers can submit queries with excessive nesting depth to cause stack overflow and crash the server. | ||||
| CVE-2026-63760 | 1 Surrealdb | 1 Surrealdb | 2026-07-28 | 7.5 High |
| SurrealDB before 3.1.0 fails to enforce the configured recursion depth limit in the value and JSON parser when processing nested braces, brackets, or parentheses. Unauthenticated attackers can send deeply nested JSON payloads to the WebSocket /rpc endpoint to exhaust server memory and crash the process. | ||||
| CVE-2026-63759 | 1 Surrealdb | 1 Surrealdb | 2026-07-28 | 6.5 Medium |
| SurrealDB before 3.1.0 fails to enforce recursion depth limits in the type/kind parser when processing nested type annotations. Authenticated attackers can send queries with deeply nested type annotations to exhaust server memory and crash the process. | ||||
| CVE-2026-63737 | 1 Surrealdb | 1 Surrealdb | 2026-07-28 | 6.5 Medium |
| SurrealDB versions before 3.1.5 contain a denial of service vulnerability where authenticated users can crash the server with queries containing long chains of operators. Attackers can submit queries with tens of thousands of chained operators that create unbounded expression trees, causing stack overflow during query processing and aborting the entire process. | ||||
| CVE-2026-47180 | 1 Python-zeroconf | 1 Python-zeroconf | 2026-07-27 | 6.5 Medium |
| Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.5, DNSIncoming._decode_labels_at_offset recurses once per DNS-name compression pointer, and a single mDNS packet carrying chained pointers can trigger a RecursionError that escapes DNSIncoming.__init__, causing sustained CPU burn, log flooding, and degraded mDNS-dependent features for unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb). This issue is fixed in version 0.149.5. | ||||
| CVE-2026-42955 | 1 Nlnetlabs | 1 Unbound | 2026-07-27 | 3.7 Low |
| In NLnet Labs Unbound 1.16.2 up to and including 1.25.1, a similar vulnerability as with CVE-2026-40622 in the 'ghost domain names' family of attacks was found in Unbound that could extend the ghost domain window by up to one cached TTL configured value for A/AAAA glue records. Similar to other 'ghost domain names' attacks, an adversary needs to control a (ghost) zone and be able to query a vulnerable Unbound. A single client A/AAAA query can cause Unbound to overwrite the cached expired parent-side glue rrset and essentially extend the ghost domain window by up to one cached TTL configured value ('cache-max-ttl'). In configurations where 'harden-referral-path: yes' is used (non-default configuration), no client query is required since Unbound implicitly performs that query. This is a variant of CVE-2026-40622 which only addressed the NS query. | ||||
| CVE-2026-58227 | 1 Erlang | 3 Erlang/otp, Erlang\/otp, Otp | 2026-07-27 | N/A |
| The Erlang/OTP ssl application does not detect cycles when reconstructing an incomplete peer certificate chain during a TLS or DTLS handshake. In ssl_certificate:handle_incomplete_chain/5, the received chain is passed to ssl_certificate:build_certificate_chain/5, which walks issuer relationships via ssl_certificate:do_certificate_chain/7 with no cycle detection and no depth limit. When the peer supplies two mutually cross-signed certificates in unordered form (A issues B, B issues A), the issuer lookup alternates between the two certificates and the pair of functions recurses indefinitely, growing the call stack and chain accumulator without bound. An unauthenticated remote attacker can send a crafted certificate chain in a TLS or DTLS Certificate handshake message to exhaust available memory and crash the BEAM node. Only a TCP connection and a partial handshake are required; no authentication or completed handshake is needed, and both TLS/DTLS servers and clients are affected when processing peer certificate messages. This issue affects OTP from OTP 23.2 before OTP 29.0.4, OTP 28.5.0.4 and OTP 27.3.4.15, corresponding to ssl from 10.2 before 11.7.4, 11.6.0.4 and 11.2.12.11. | ||||
| CVE-2026-52684 | 1 Powerdns | 1 Recursor | 2026-07-27 | 3.7 Low |
| If the auth responds very slowly and the records expire in between, the capping of TTLs is not enforced for lack of data. This does not happen on regular resolve as then then the child records are used immediately if not expired and thus valid, or the records are expired, and in that case not used. So this case can only happen if almost expired records are used to refresh the authoritative NS records. | ||||
| CVE-2026-64345 | 1 Linux | 1 Linux Kernel | 2026-07-27 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_printer: take kref only for successful open printer_open() returns -EBUSY when the character device is already open, but it increments dev->kref regardless of the return value. VFS does not call ->release() for a failed open, so every rejected second open permanently leaks one reference. Move kref_get() into the successful-open branch. | ||||
| CVE-2026-64358 | 1 Linux | 1 Linux Kernel | 2026-07-27 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: cancel workqueue on release for supported platforms only Since a recent fix the mtk_jpeg_release function cancels any pending or running work present in the driver workqueue using cancel_work_sync function. Currently, only the multicore based variants use this workqueue and they have the jpeg_worker platform data field initialized with a workqueue callback function. For the others, this field value remain NULL by default. The cancel_work_sync function is unconditionally called in mtk_jpeg_release function, even for the variants that do not use the workqueue. This call generates a WARN_ON print in __flush_work because the workqueue callback function presence check fails in __flush_work function (used by cancel_work_sync). So, to avoid these warnings, call cancel_work_sync only if a workqueue callback is defined in platform data. | ||||
| CVE-2026-64466 | 1 Linux | 1 Linux Kernel | 2026-07-27 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: rust_binder: clear freeze listener on node removal Generally userspace is supposed to explicitly clear freeze listeners before they drop the refcount on the node ref to zero, but there's nothing forcing that. Currently, in this scenario the freeze listener remains in the freeze_listeners rbtree and in the remote node's freeze listener list, even though the ref for which the listener is registered is gone. This could potentially lead to a memory leak due to a refcount cycle. Thus, remove the freeze listener in this scenario. | ||||
| CVE-2026-64413 | 1 Linux | 1 Linux Kernel | 2026-07-27 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: zero chainstack array sashiko reports: looking at ebtables table translation, could a sparse cpu_possible_mask lead to an uninitialized pointer free? If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1]. Not a real-world bug, such allocation isn't expected to fail in the first place. | ||||
| CVE-2026-64289 | 1 Linux | 1 Linux Kernel | 2026-07-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iommufd: Set upper bounds on cache invalidation entry_num and entry_len iommufd_hwpt_invalidate() takes a user-controlled entry_num and entry_len, each bounded only by U32_MAX. An entry_len beyond the kernel's struct size makes the copy helper verify the extra bytes are zero, scanning that excess in one uninterruptible pass; a multi-gigabyte value over zeroed user memory trips the soft-lockup watchdog. A large entry_num is the other half, driving the backend invalidation loop with no reschedule. The VT-d nested handler, for one, copies each entry and flushes caches per iteration, pinning the CPU on a non-preemptible kernel. Cap both in the ioctl. entry_len is held under PAGE_SIZE, above any request struct, and entry_num under 1 << 19, the order of a hardware invalidation queue and well beyond any real batch, bounding the per-call loop length. | ||||
| CVE-2026-42791 | 1 Erlang | 3 Erlang/otp, Erlang\/otp, Otp | 2026-07-24 | 3.7 Low |
| Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_ocsp module) allows forged OCSP responses signed with an expired responder certificate to be accepted as valid. OCSP response verification in pubkey_ocsp:verify_response/5 and pubkey_ocsp:is_authorized_responder/3 in lib/public_key/src/pubkey_ocsp.erl does not check the validity period (notBefore/notAfter) of the OCSP responder certificate. An attacker who has obtained the private key of an expired CA-designated OCSP responder certificate can forge OCSP responses that Erlang/OTP accepts as valid. This affects TLS clients using OCSP stapling via the ssl application: a malicious or compromised server can present a revoked TLS certificate together with a forged OCSP response signed by an expired responder key, and the client will accept the revoked certificate as valid. It also affects applications calling public_key:pkix_ocsp_validate/5 directly, where the impact depends on the use case — server-side client certificate validation using this API may allow authentication bypass with a revoked client certificate. This issue affects OTP from OTP 27.0 before OTP 29.0.1, OTP 28.5.0.1 and OTP 27.3.4.12, corresponding to public_key from 1.16 before 1.21.1, 1.20.3.1 and 1.17.1.3. | ||||
| CVE-2026-63144 | 1 Elastic | 1 Elasticsearch | 2026-07-22 | 6.5 Medium |
| Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to denial of service via a specially crafted search request submitted by a low-privileged authenticated user. A user with read-level index access can submit a request that triggers unbounded recursive processing within the Elasticsearch query evaluation component, causing a fatal error that terminates the affected node. In single-node deployments, this results in complete service outage; in multi-node clusters, it causes repeated node restarts and sustained availability degradation. | ||||
| CVE-2026-14501 | 1 Ibm | 2 Agentics, Db2 Genius Hub | 2026-07-20 | 4.3 Medium |
| IBM Db2 Genius Hub 1.1, 1.1.1, 1.1.2 and IBM Agentics 1.0 could allow an attacker to execute arbitrary code or obtain sensitive information due to the use of dangerous functions without sufficient restrictions. | ||||
| CVE-2026-38755 | 1 Busybox | 1 Busybox | 2026-07-20 | 2.9 Low |
| A heap overflow in the evalcommand() function (shell/ash.c) of Busybox v1.38.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted input. | ||||
| CVE-2026-38752 | 1 Busybox | 1 Busybox | 2026-07-20 | 2.9 Low |
| A stack overflow in the evaluate() function (editors/awk.c) of BusyBox commit 371fe9 allows attackers to cause a Denial of Service (DoS) via supplying a crafted AWK script. | ||||
| CVE-2026-57081 | 1 Sanko | 1 Net::bittorrent | 2026-07-20 | 7.5 High |
| Net::BitTorrent versions through 2.1.0 for Perl allow remote memory exhaustion via deeply nested bencoded input. bdecode recurses once per nested list or dictionary level with no depth cap, and each recursive call receives the remaining buffer by value while the list and dictionary branches capture the whole remainder, so every live recursion frame keeps its own copy of the shrinking buffer (O(N^2) bytes for an N-deep input). The decoder runs on every untrusted bencode source: .torrent files, BEP09 metadata fetched from peers, DHT messages, and tracker responses. A bencoded input of roughly 150,000 nested lists (about 150 KB on the wire) drives multi-gigabyte peak memory, so one short message from any peer, or one crafted .torrent file or magnet link, terminates the client. | ||||