| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| python-markdown2 through 2.5.5 contains a denial of service vulnerability that allows remote users to exhaust CPU by submitting Markdown with unclosed inline link destinations. Attackers can submit repeated '[a](' or '. |
| A vulnerability was identified in smg-project smg 1.7.0/1.8.0/1.9.0/1.10.0/1.10.1. Affected is the function jpeg_turbo::decode_jpeg_rgb of the file crates/multimodal/src/jpeg_turbo.rs of the component llm-multimodal. The manipulation leads to uncontrolled memory allocation. The attack can be initiated remotely. The exploit is publicly available and might be used. Upgrading to version 1.11.0 is able to address this issue. The identifier of the patch is 8f51b57e219a914089e345b704c3c8de37a3bb8e. It is advisable to upgrade the affected component. |
| OpenStack Ironic through 39.0.1 allows a denial of service via a configdrive that results in a very large amount of uncompressed data, aka a gzip bomb. |
| Cpanel::JSON::XS versions before 4.80 for Perl leak the decoded arguments of a tagged value when its THAW method dies in decode_tag.
With allow_tags, a tagged value's class name and argument array are decoded and passed to the class's THAW method. Both are released only after THAW returns, so a THAW that dies leaves the whole decoded argument structure allocated.
Each rejected document leaks data of a size the sender chooses, so a process that catches the error and keeps running exhausts its memory. |
| Cpanel::JSON::XS versions from 3.0202 before 4.80 for Perl leak memory and retain overloaded objects when encoding values as strings in encode_stringify.
encode_stringify writes a value in its string form under allow_stringify, under convert_blessed for objects without TO_JSON, and under allow_bignum. For an array or hash object with a "" overload, and from 4.20 a scalar object, it takes an extra reference that is never released, so the object and everything it references are never freed. From 4.10 it also never frees its copy of the string.
Repeatedly encoding data that contains such values grows process memory without bound. |
| RE2JS is the JavaScript port of RE2, a regular expression engine that provides linear time matching. From 2.2.0 until 2.8.7, enabling LOOKBEHINDS and using repeated matching through matcher().find(), matchAll(), split(), or matcher().replaceAll() can cause quadratic total work. Machine.match restarts lookbehind scanning from offset zero for each requested start position, while Matcher-based APIs request capture slots that prevent the early exit used for captureless matching. Dense matches therefore repeatedly rescan the input, allowing attacker-influenced text to monopolize a single-threaded worker and deny service. This issue is fixed in version 2.8.7. |
| 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. |
| 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. |
| RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.24, 4.1.15, 4.2.10, and 4.3.4, deps/amqp10_common/src/amqp10_binary_parser.erl materializes each element of AMQP 1.0 arrays whose shared constructor has zero width, while limiting only the number of elements in each array and not the aggregate arrays in a frame. After completing SASL authentication, a low-privilege client can send an ordinary frame containing many individually permitted arrays, causing a small frame to expand into a very large reader-process heap before later frame validation or authorization. Because deps/rabbit/src/rabbit_amqp_reader.erl clears the pre-authentication max_heap_size guard after login, repeated or concurrent frames can trigger the node-wide memory alarm, block publishers, or exhaust broker memory. This issue is fixed in versions 4.0.24, 4.1.15, 4.2.10, and 4.3.4. |
| Twisted is an event-based framework for internet applications, supporting Python 3.6+. Prior to 26.10.0rc1, twisted.mail.imap4.IMAP4Server reaches twisted.mail.imap4.parseNestedParens with a negative literal size in an authenticated SEARCH command after the client enters the selected mailbox state. The negative size moves the parser cursor below zero, and Python's negative indexing prevents the synchronous scanning loop from terminating. The loop freezes the single-threaded reactor, stopping other IMAP connections and any SMTP or POP3 services hosted in the same process until restart. This issue is fixed in version 26.10.0rc1. |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.21.2, an attacker can craft a PDF that repeatedly references the same nonexistent indirect object, causing relevant file parts such as pages to trigger repeated full-file recovery loads and long runtimes when accessed. This issue is fixed in version 6.21.2. |
| MIME::Parser versions before 5.521 for Perl allow memory exhaustion via indented error messages from a truncated, deeply nested message.
Each stored parser diagnostic is indented by three spaces per nesting level. When a message nested N levels deep ends without its closing boundaries, every level logs an error at its own depth, so the stored diagnostics grow with the square of N. The defaults place no limit on nesting depth. |
| MIME::Words versions before 5.521 for Perl allow memory exhaustion via repeated "=?" sequences in decode_mimewords.
For each "=?" that does not start a complete encoded word, decode_mimewords appends an error message containing the whole input string to $@. A boundary of 8,000 "=?" pairs (16,000 bytes) adds 8,000 copies of itself to $@, about 128 MB.
From version 5.518, MIME::Parser decodes every multipart boundary this way, so a remote sender can exhaust the memory of the parsing process with one Content-Type header. |
| HTTP::Body versions before 1.23_01 for Perl allow CPU exhaustion via quadratic rescanning of a multipart body with a missing or malformed boundary.
Before the first part, and between parts, the multipart parser searches the whole buffered body for the next boundary. On a miss it keeps everything and searches again from the start when the next chunk arrives. A body with no boundary, or with a delimiter followed by neither CRLF nor "--", is therefore rescanned on every chunk, taking time quadratic in its size.
A remote attacker can exhaust worker CPU with a few such requests. |
| 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). |
| 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. |
