Total
2711 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-60108 | 1 Zeek | 1 Zeek | 2026-10-24 | N/A | 7.5 HIGH |
| Zeek before 8.0.9 contains an uncontrolled memory consumption vulnerability in the FTP analyzer that allows unauthenticated remote attackers to cause process termination by sending a crafted FTP control session negotiating AUTH GSSAPI followed by a large ADAT control line. Attackers can exploit the NVT_Analyzer component's lack of a maximum line length check, causing it to continuously double its internal buffer without bounds during base64 decoding of an attacker-controlled ADAT token, resulting in denial of service of the Zeek sensor. | |||||
| CVE-2026-25800 | 2026-10-24 | N/A | 7.5 HIGH | ||
| Quinn is a pure-Rust, async-compatible implementation of the IETF QUIC transport protocol. Starting in version 0.1.0 and prior to version 0.11.15, the `Assembler` component that assembles unordered stream fragments into consecutive chunks of the stream incurs some overhead for non-contiguous fragments. Readers that read from a `RecvStream` in order (through an `AsyncRead` impl for example) will be sensitive to peers that send fragments while leaving out early parts of the stream, and in particular, fragments with many gaps (because these cannot be defragmented). In such a scenario, the receiving connection suffers from high buffer overhead, enabling memory exhaustion. Version 0.11.15 fixes the issue. | |||||
| CVE-2026-58389 | 1 Apache | 1 Thrift | 2026-10-24 | N/A | 7.5 HIGH |
| Allocation of Resources Without Limits or Throttling vulnerability in Apache Thrift Rust bindings. This issue affects Apache Thrift: before 0.24.0. Users are recommended to upgrade to version 0.24.0, which fixes the issue. | |||||
| CVE-2026-22925 | 1 Siemens | 2 Simatic Cn 4100, Simatic Cn 4100 Firmware | 2026-10-24 | N/A | 7.5 HIGH |
| A vulnerability has been identified in SIMATIC CN 4100 (All versions < V5.0). The affected application is susceptible to resource exhaustion when subjected to high volume of TCP SYN packets This could allow an attacker to render the service unavailable and cause denial-of-service conditions by overwhelming system resources. | |||||
| CVE-2026-67432 | 2026-10-24 | N/A | 7.5 HIGH | ||
| MCP Ruby SDK is the official Ruby SDK for Model Context Protocol servers and clients. Prior to 0.23.0, MCP::Server::Transports::StreamableHTTPTransport in the mcp gem reads and parses an entire JSON-RPC POST body without a size limit, allowing an unauthenticated remote attacker to exhaust process memory. This issue is fixed in version 0.23.0. | |||||
| CVE-2026-13074 | 1 Mongodb | 1 Mongodb | 2026-10-24 | N/A | 5.3 MEDIUM |
| An unauthenticated remote client can cause excessive CPU consumption on a MongoDB server by sending a specific combination of parameters to the awaitable hello command in exhaust mode. The server's handling of this combination results in a response loop that bypasses normal throttling, allowing a small number of connections to degrade server availability. | |||||
| CVE-2026-65624 | 2026-10-24 | N/A | N/A | ||
| Allocation of Resources Without Limits or Throttling vulnerability in ninenines cowboy allows an unauthenticated remote attacker to exhaust connection process memory over HTTP/1.1. The HTTP/1.1 handler in cowboy_http enforces the max_headers limit by counting the number of distinct header names in a map (maps:size(Headers)). When a request contains multiple header lines with the same name, the values are concatenated into a single ever-growing binary stored under that one map key (", " for regular headers, "; " for cookies), so the map size stays at one and the max_headers cap (default 100) is never reached. Because no accumulator bounds the total number of header lines or the total byte size of the header block (only per-line max_header_name_length and max_header_value_length apply), an unauthenticated client can send an arbitrary number of header lines with the same name and grow the connection process's binary memory to arbitrary size within the request window. The impact per connection is bounded by request_timeout (default 5 seconds, not reset by header data), and by max_heap_size when set (the offending connection process is killed once its heap grows past the limit). When max_heap_size is left at the default (unset), sustained abuse can drive the Erlang VM into out-of-memory conditions. This issue affects cowboy from 2.0.0-pre.4 before 2.18.0. | |||||
| CVE-2026-64646 | 1 Vercel | 1 Next.js | 2026-10-24 | N/A | 5.3 MEDIUM |
| Next.js is a React framework for building full-stack web applications. In versions 13.0.0 through 15.5.20 and 16.0.0 through 16.2.10, requests targeting Next.js applications using App Router with at least one Server Action can lead to excessive memory consumption if that Server Actions uses the Edge runtime. This issue has been fixed in versions 15.5.21 and 16.2.11. | |||||
| CVE-2022-43768 | 1 Siemens | 48 Simatic Cp 1242-7 V2, Simatic Cp 1242-7 V2 Firmware, Simatic Cp 1243-1 and 45 more | 2026-10-23 | N/A | 7.5 HIGH |
| A vulnerability has been identified in SIMATIC CP 1242-7 V2 (6GK7242-7KX31-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-1 (6GK7243-1BX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-7 LTE EU (6GK7243-7KX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-7 LTE US (6GK7243-7SX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1542SP-1 (6GK7542-6UX00-0XE0) (All versions < V2.3), SIMATIC CP 1542SP-1 IRC (6GK7542-6VX00-0XE0) (All versions < V2.3), SIMATIC CP 1543SP-1 (6GK7543-6WX00-0XE0) (All versions < V2.3), SIMATIC CP 443-1 (6GK7443-1EX30-0XE0) (All versions < V3.3), SIMATIC CP 443-1 (6GK7443-1EX30-0XE1) (All versions < V3.3), SIMATIC CP 443-1 Advanced (6GK7443-1GX30-0XE0) (All versions < V3.3), SIPLUS ET 200SP CP 1542SP-1 IRC TX RAIL (6AG2542-6VX00-4XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC (6AG1543-6WX00-7XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC TX RAIL (6AG2543-6WX00-4XE0) (All versions < V2.3), SIPLUS NET CP 1242-7 V2 (6AG1242-7KX31-7XE0) (All versions < V3.4.29), SIPLUS NET CP 443-1 (6AG1443-1EX30-4XE0) (All versions < V3.3), SIPLUS NET CP 443-1 Advanced (6AG1443-1GX30-4XE0) (All versions < V3.3), SIPLUS S7-1200 CP 1243-1 (6AG1243-1BX30-2AX0) (All versions < V3.4.29), SIPLUS S7-1200 CP 1243-1 RAIL (6AG2243-1BX30-1XE0) (All versions < V3.4.29), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.3.6), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.3.6). The webserver of the affected products contains a vulnerability that may lead to a denial of service condition. An attacker may cause a denial of service situation of the webserver of the affected product. | |||||
| CVE-2026-14539 | 1 Google | 1 Mcp Toolbox For Databases | 2026-10-23 | N/A | 7.5 HIGH |
| An allocation of resources without limits vulnerability in the HTTP handler component of Google mcp-toolbox versions up to and including 1.4.0 allows an unauthenticated attacker to cause a denial of service (DoS). The /mcp endpoint handler reads incoming payloads directly into system memory using an unrestricted buffer loop (io.ReadAll) without applying defensive constraints such as http.MaxBytesReader or pre-read Content-Length enforcement. By submitting a single, massive HTTP request body, an attacker can linearly consume available host memory until the runtime process is terminated by an Out-Of-Memory (OOM) error. | |||||
| CVE-2023-23916 | 5 Debian, Fedoraproject, Haxx and 2 more | 13 Debian Linux, Fedora, Curl and 10 more | 2026-10-23 | N/A | 6.5 MEDIUM |
| An allocation of resources without limits or throttling vulnerability exists in curl <v7.88.0 based on the "chained" HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with differentalgorithms. The number of acceptable "links" in this "decompression chain" wascapped, but the cap was implemented on a per-header basis allowing a maliciousserver to insert a virtually unlimited number of compression steps simply byusing many headers. The use of such a decompression chain could result in a "malloc bomb", making curl end up spending enormous amounts of allocated heap memory, or trying to and returning out of memory errors. | |||||
| CVE-2023-36521 | 1 Siemens | 12 Simatic Mv540 H, Simatic Mv540 H Firmware, Simatic Mv540 S and 9 more | 2026-10-23 | N/A | 8.6 HIGH |
| A vulnerability has been identified in SIMATIC MV540 H (All versions < V3.3.4), SIMATIC MV540 S (All versions < V3.3.4), SIMATIC MV550 H (All versions < V3.3.4), SIMATIC MV550 S (All versions < V3.3.4), SIMATIC MV560 U (All versions < V3.3.4), SIMATIC MV560 X (All versions < V3.3.4). The result synchronization server of the affected products contains a vulnerability that may lead to a denial of service condition. An attacker may cause a denial of service situation of all socket-based communication of the affected products if the result server is enabled. | |||||
| CVE-2026-68494 | 2026-10-23 | N/A | N/A | ||
| The fix released in jackson-core 2.18.6 and 2.21.1 for CVE-2026-18401 (GHSA-72hv-8253-57qq, number length constraint bypass in the non-blocking parser) is incomplete. This record covers the remaining bypass. The earlier fix wired validateIntegerLength() into a new _setIntLength() helper and invoked it wherever the integer portion of a number is decided: a terminator byte arrives, a '.' or 'e'/'E' is seen, or input ends inside a fully buffered value. It was not invoked on the attacker-relevant path where the parser runs out of input while still inside the MINOR_NUMBER_INTEGER_DIGITS minor state and returns NOT_AVAILABLE to the caller. As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, keeps the parser inside MINOR_NUMBER_INTEGER_DIGITS indefinitely. _textBuffer.expandCurrentSegment() grows the accumulator on every chunk while validateIntegerLength() is never called. The accumulator is bounded only by maxStringLength (20 MiB by default) rather than by maxNumberLength (1000 by default), an amplification of roughly 20,000x over the documented limit. Because Java char values occupy two bytes, a single connection can be driven to approximately 40 MiB of heap before the validator finally fires when the value completes. The equivalent fraction-path code is correct: _finishFloatFraction() calls _setFractLength() before its NOT_AVAILABLE return. The missing call affects the integer-digit paths in _startPositiveNumber(), _startNegativeNumber() and _finishNumberIntegralPart() in NonBlockingUtf8JsonParserBase. Impact: reactive frameworks such as Spring WebFlux/Reactor, Quarkus, Helidon and Vert.x feed inbound HTTP or gRPC bytes to the async parser as they arrive, which is precisely the chunked-feed shape required. Operators who set StreamReadConstraints.maxNumberLength expecting it to cap memory per number value do not get that guarantee; memory accumulates per concurrent connection and attacker-controlled concurrency can exhaust the JVM heap. The synchronous parsers (UTF8StreamJsonParser, ReaderBasedJsonParser) and the async parser operating on complete input are not affected. Exploitation requires only the ability to stream data to a parsing endpoint; no privileges or user interaction are needed. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.7, and from 2.19.0 through 2.21.3, and tools.jackson.core:jackson-core from 3.0.0 through 3.1.3. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-r7wm-3cxj-wff9 states the affected 2.x range without a lower bound. The 2.22.x and 3.2.x release lines are not affected: those branches were created after the fix commit landed on 2026-05-21 and therefore contain it from their initial releases (2.22.0, tagged 2026-06-03, and 3.2.0, tagged 2026-06-08). | |||||
| CVE-2026-18401 | 2026-10-23 | N/A | N/A | ||
| The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses. Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond the ability to submit data for parsing are required. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0. | |||||
| CVE-2026-54638 | 2026-10-23 | N/A | 7.5 HIGH | ||
| gotd/td is a T Telegram MTProto API client in Go. Prior to 0.145.1, proto.UnencryptedMessage.Decode in proto/unencrypted_message.go read attacker controlled dataLen from an unauthenticated MTProto unencrypted packet and allocated make([]byte, dataLen) before checking the remaining buffer, allowing remote unauthenticated denial of service through excessive memory allocation and CPU or garbage collection pressure. This issue is fixed in version 0.145.1. | |||||
| CVE-2026-54609 | 2026-10-23 | N/A | 8.6 HIGH | ||
| QTI Neon is a minimal, game-agnostic, relay-based UDP multiplayer protocol library. In version 1.0.0, the relay's handleReconnectRequest forwards RECONNECT_REQUEST packets to the host without bounding them, so an unauthenticated client can drive relay-to-host amplification and cause a denial of service on the host. No fixed version is available as of this review. | |||||
| CVE-2026-67199 | 2026-10-23 | N/A | 6.5 MEDIUM | ||
| Perspective 5.0.0 contains a denial of service vulnerability that allows remote attackers to block the server event loop indefinitely by submitting a crafted expression containing unbounded for or while loop constructs in a TableMakeViewReq message. Attackers can embed an arbitrarily large iteration count in an expression column evaluated once per table row, causing the Tornado IOLoop to block without any iteration cap, deadline, or cancellation check, rendering the server unresponsive to all connected clients. | |||||
| CVE-2026-109298 | 2026-10-23 | N/A | 6.5 MEDIUM | ||
| Open WebUI 0.11.0 before 0.11.4 compiles user-chosen grep patterns for its knowledge and chat file search tools with a regex engine that expands nested counted repetition unbounded at compile time and caches the result. Authenticated users can have the model call grep_knowledge_files with short nested-repetition patterns, blocking the event loop and exhausting worker memory. | |||||
| CVE-2026-18362 | 2026-10-23 | N/A | 5.9 MEDIUM | ||
| The IRIS web application in version 2.4.26 and possibly others does not protect its user authentication against brute-force attacks. | |||||
| CVE-2026-55733 | 1 Ueberauth | 1 Guardian | 2026-10-23 | N/A | 7.5 HIGH |
| Allocation of Resources Without Limits or Throttling in ueberauth guardian allows denial of service via unbounded atom creation from attacker-controlled binary input. Guardian.Permissions.AtomEncoding encodes permission scopes by passing arbitrary binaries to String.to_atom/1. When encode/3 in lib/guardian/permissions/atom_encoding.ex is called with a list, each binary entry is handled by the encode_value/3 binary clause, which calls String.to_atom(value) with no allow-list check. The perm_set argument (the application's small, finite set of legitimate permission names) is discarded, so any external string flows straight into atom creation. This encoder is selected with use Guardian.Permissions, encoding: Guardian.Permissions.AtomEncoding and reached through the imported encode/3 entry point. String.to_atom/1 creates a brand-new atom for every previously unseen binary, atoms are never garbage collected, and the BEAM atom table is fixed at roughly 1,048,576 entries by default. An application that funnels attacker-influenced permission scopes (from a request body, a JWT claim, or other external input) into encode/3 therefore mints one permanent atom per distinct value. A modest stream of varied, unauthenticated input permanently consumes the atom table and crashes the BEAM node with system_limit, taking down every application running on it. The default encoder is Guardian.Permissions.BitwiseEncoding, which is not affected. This issue affects guardian: from 2.0.0 before 2.4.1. | |||||