CVE-2026-118260 is a high-severity vulnerability in the labstack Echo Go web framework versions 4.0.0 through 4.16.0. The opt-in BodyDump middleware reads entire request and response bodies into memory without limits, allowing unauthenticated clients to cause uncontrolled memory consumption by sending large requests or triggering large responses. This can exhaust process memory and potentially disrupt service. The issue is fixed in version 4.16.1.
A user with the Viewer role in Grafana can crash the server by submitting a crafted server-side math expression (uncontrolled recursion). A user with permission to provision alert rules can make the outage persist across restarts.
When a broker decodes a compressed record batch, the per-record decoder reads a declared body size from the decompressed stream and allocates a buffer of that size before validating it against the bytes available or any configured limit. The size is attacker-controlled, and the batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce request can declare a body size of up to about 2 GiB and force the broker to attempt that allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request size limit, and client/broker quotas bound only the compressed wire size, not the declared decompressed size.
Impact:
An authenticated principal with Write on a topic can crash broker request-handler threads (reached when a batch's codec differs from the topic's compression.type and records are re-encoded) and any consumer that fetches the record, denying service. On brokers started with -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the broker JVM. More seriously, a crafted record is accepted at ingest and written to disk; when the log-cleaner later reads it on a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner thread, which is not restarted. With the default of a single cleaner thread, log compaction then stops for the entire broker, including the internal __consumer_offsets and __transaction_state topics, and the condition persists across restarts until the offending record is removed. The impact is availability only; no data is disclosed or altered.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set max.decompressed.message.bytes (at the broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is not sufficient: for backward compatibility this configuration defaults to an effectively unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a value at or slightly above the largest legitimate decompressed record your applications produce, and comfortably below the broker heap divided by the number of request-handler and cleaner threads. Until you can upgrade and configure the limit, restrict Write access to trusted producers; quotas and max.message.bytes do not mitigate this issue.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record's declared decompressed body size against max.decompressed.message.bytes before allocating, on the produce-validation, log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with InvalidRecordException. Operators must set this configuration to a bounded value to be protected, as its default is effectively unlimited.
Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde).
Impact:
An attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected. The reachable surface depends on the path: writing a crafted record to a Streams application's internal changelog or repartition topics, or committing crafted offset metadata to its consumer group (Streams internal paths); writing a crafted record to any topic that a consumer reads with ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its topic, the error can recur on restart. The record size limit (max.message.bytes) does not help, because the allocation is driven by a size field rather than by the input's length.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write access to each application's internal topics and consumer group to its own principal, and restrict who can produce to topics that are consumed with ListSerde.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check.
Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field.
Impact:
Request parsing happens before any authorization check. On a listener that does not require authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent requests that each declare a very large=
array length and allocate many times their wire size in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification). On listeners that require authentication, the attacker needs valid credentials but no specific ACL, since parsing precedes authorization..
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand, and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).
The broker-side PushTelemetry API (KIP-714) validates only the compressed size of a client's metrics payload against telemetry.max.bytes (default 1 MB) before decompressing it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the decompressed output size, growing a heap buffer until the compressed input is exhausted. A small, highly compressible payload (for example gzip-compressed zeros) can therefore expand to hundreds of megabytes of broker heap.
Impact:
An authenticated client can send a PushTelemetry request with a small compressed payload that decompresses to a very large size, consuming broker heap out of proportion to the request size. Repeated or concurrent requests can exhaust the broker heap and cause an OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers can affect cluster availability. PushTelemetry is available to any authenticated client and is not gated by an ACL.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully prevents the amplification, because telemetry.max.bytes bounds only the compressed size; lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a partial mitigation.
Resolution:
- From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an over-large or highly compressible payload is rejected instead of being fully expanded in heap. The decompressed size is therefore bounded by default.
CVE-2026-116774 is a resource consumption vulnerability in the Eugeny russh Rust SSH client and server library versions 0.60.0 through 0.64.x. The flaw allows an authenticated client or malicious server to cause asynchronous write operations to remain pending indefinitely by specifying a maximum_packet_size of zero. This leads to accumulation of affected tasks, channels, and connections without error, potentially exhausting resources. The issue is fixed in version 0.65.0.
CVE-2026-77167 is a denial-of-service vulnerability in Nextcloud server affecting versions 22.0.0 through 34.0.0. An attacker can abuse the federated share endpoint to write arbitrary rows into the oc_share_external database table. These rows persist indefinitely without automatic cleanup, causing three distinct self-renewing denial-of-service conditions triggered from an unauthenticated source on a 24-hour cycle.
CVE-2026-70380 is a denial-of-service vulnerability in the Miracast over Infrastructure Connection Establishment (MICE) service of WolfVision Cynap devices. An unauthenticated attacker with network access to the MICE service can exhaust connection capacity, blocking legitimate Miracast connections. Miracast P2P is unaffected, and MICE is disabled by default, requiring explicit enablement. Some devices may experience complete Miracast disruption when WLAN is set to Infrastructure mode.
CVE-2026-115927 is a medium severity vulnerability in the Tornado Python web framework prior to version 6.6.0. It involves uncontrolled resource consumption due to inefficient handling of HTTP/1.1 chunked transfer encoding. A remote unauthenticated attacker can send many small chunks to monopolize the event loop, stalling other connections and causing denial of service. The issue is fixed in Tornado 6.6.0.
There is s denial of service vulnerability in Esri ArcGIS Server versions 12.0 and prior that may allow a remote, unauthenticated attacker to supply crafted requests that may, under exceptional circumstances, consume all available worker threads and deny service to users. A patch is provided for ArcGIS Server software in General Availability and Extended support status, which includes versions 12.0, 11.5, 11.3, and 11.1. Other versions are in mature or retired status, which are not patch eligible. Users working with unlisted versions are advised to upgrade and apply the patch.
vLLM versions from 0.16.0 up to but not including 0.32.0 contain a vulnerability in the /v1/responses endpoint that allows an authenticated user to supply a malicious template in chat_template_kwargs[chat_template]. This bypasses the intended trust policy and can lead to uncontrolled CPU or memory consumption during Jinja template rendering. The issue is resolved in version 0.32.0.
CVE-2026-115911 is a vulnerability in vllm, an inference and serving engine for large language models, affecting versions from 0.19.0 up to but not including 0.32.0. Authenticated users can supply a chat template that is compiled and rendered without limits on execution time or output size, potentially causing resource exhaustion. This can block server responses or exhaust memory, leading to denial of service. The issue is fixed in version 0.32.0.
zip is a zip library for Rust that supports reading and writing simple ZIP files. From 1.3.0 until 9.0.0, ZipArchive::extract in src/read/mod.rs calls Vec::with_capacity for a symbolic link target using the attacker-controlled ZIP64 uncompressed_size before reading entry data. A small archive can request an impossible capacity, causing the infallible allocation path to abort the process before the entry is validated. The failure cannot be contained with catch_unwind or a worker thread, allowing repeated denial of service in archive-processing applications. This issue is fixed in version 9.0.0.
A vulnerability in the zip-rs zip2 Rust library versions 5.1.0 through before 9.0.0 allows an attacker to cause uncontrolled resource consumption. This occurs when applications using the legacy-zip feature reserve output capacity based on attacker-controlled ZIP64 uncompressed sizes before validating the compressed stream. The flaw can cause a panic due to capacity overflow during archive extraction, potentially terminating the archive-processing service. The issue is fixed in version 9.0.0.
CVE-2026-115778 is a high-severity vulnerability in the Twisted event-based framework for Python. Prior to version 26.10.0rc1, the Telnet dataReceived method in twisted.conch.telnet improperly accumulates data in a subnegotiation buffer without a maximum length limit. Because Telnet option negotiation occurs before authentication, an unauthenticated attacker can send data without the expected terminator, causing uncontrolled memory growth. This can lead to memory exhaustion and process termination, affecting all services hosted by the process. The issue is fixed in version 26.10.0rc1.
CVE-2026-115776 is a high-severity vulnerability in the Twisted framework prior to version 26.10.0rc1. It involves uncontrolled resource consumption due to the IRC protocol implementation buffering all received bytes without a line feed and lacking a maximum line length limit. This allows unauthenticated connections to grow the buffer indefinitely, potentially exhausting server memory and causing denial of service by dropping all users. The issue is fixed in version 26.10.0rc1.
CVE-2026-115775 is a high-severity vulnerability in the Twisted framework prior to version 26.10.0rc1. It involves uncontrolled resource consumption due to the twisted.words.xish.domish ExpatElementStream parser allowing an unauthenticated remote peer to keep a container element open while continuously adding child elements. This causes the parser to retain an unfinished stanza as an in-memory tree without limits, potentially exhausting server memory and terminating the process. The issue is fixed in version 26.10.0rc1.
CVE-2026-115774 is a vulnerability in the Twisted framework prior to version 26.10.0rc1. It involves an uncontrolled resource consumption issue triggered by a negative literal size in an authenticated IMAP SEARCH command. This causes the parser cursor to move below zero, leading to an infinite loop that freezes the single-threaded reactor. As a result, all IMAP connections and any SMTP or POP3 services hosted in the same process become unresponsive until the process is restarted. The issue is fixed in version 26.10.0rc1.
A vulnerability in pypdf prior to version 6.21.2 allows crafted PDF files with malformed cross-reference streams to cause excessive resource consumption. This occurs because an incomplete fix for repeated malformed cross-reference entries causes the library to reload the entire PDF stream multiple times during recovery attempts, leading to long runtimes. The issue is resolved in version 6.21.2.