| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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 message body that is deeply nested and decoded by pn_message_body() could overflow the stack and cause a crash.
This issue affects Apache Qpid Proton C: through 0.40.0.
Users are recommended to upgrade to version 0.41.1, which fixes the issue. |
| 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. |
| Improper neutralization of special elements used in a command ('command injection') in Windows Shell allows an unauthorized attacker to bypass a security feature over a network. |
| 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. |
| 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. |
| HTTP::Body versions before 1.24_01 for Perl allow memory exhaustion via unbounded buffering of chunked request bodies.
In chunked mode, used when no content length is given, add() holds each chunk in memory until all of it has arrived. A line that is not a chunk-size line, a size line without CRLF, or a size too large to fit an integer leaves the parser waiting forever, and every later add() grows the buffer.
A remote attacker can exhaust memory in applications that pass chunked request bodies to HTTP::Body. |
| MIME::Parser versions before 5.521 for Perl set no limit on the number of message parts by default, allowing memory exhaustion.
The max_parts option defaulted to -1, which disables the limit, so a parser created with default settings builds an entity for every part however many a message has.
Version 5.521 sets max_parts to 1000 and max_depth to 64 by default. Setting either to -1 still removes the limit. |
| HTTP::Body versions before 1.23_01 for Perl allow memory and temporary file exhaustion via an unlimited number of form fields and multipart parts.
The urlencoded parser splits the whole body on its separators at once, creating one scalar per separator before any field is stored. This costs about 90 bytes of memory per separator byte. The multipart parser creates a temporary file for every part that carries a filename. Neither parser limits how many fields or parts a body may hold.
A remote attacker can exhaust worker memory with a body made of separators, or create thousands of temporary files with one request of small file parts. |
| 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. |
| HTTP::Body versions before 1.23_01 for Perl allow memory exhaustion via an unbounded multipart part header block.
The multipart parser takes everything up to the first blank line after a boundary as the part's header block, with no limit on its size or number of lines. Every line is stored in the part's header hash, so a block of short lines costs about 60 bytes of memory per input byte.
A remote attacker can exhaust worker memory with a single request. |
| 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. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
power: sequencing: pcie-m2: Fix leaking array from of_regulator_bulk_get_all()
of_regulator_bulk_get_all() allocates the consumers array and hands it to
the caller, who is expected to free it at an appropriate time.
pwrseq-pcie-m2.c never did, leading to a memory leak.
Add an explicit kfree() for the consumers array. |
| In the Linux kernel, the following vulnerability has been resolved:
net: team: free skb when broadcast has no txable port
bc_transmit() sends the original skb through the last txable port.
When no port is txable, it returns false without consuming the skb, but
team_xmit() still returns NETDEV_TX_OK. AF_PACKET sends then retain the
skb and its socket write-memory charge.
A TX-enabled, link-down port keeps the broadcast transmit op installed.
Carrier can stay up through a second link-up, TX-disabled port or be
forced on by userspace. Free the original skb on the no-port path while
leaving the existing drop accounting intact.
Discovered by Sashiko during review of previous commit. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: account non-AQL frames per peer rather than per link
The driver increments wcid->non_aql_packets when a frame goes to the
hardware queue. The completion path decrements the counter again.
For an MLO peer, the hardware reports the completion on the link that it
used for the transmission. This link can differ from the link that the
driver queued the frame on. In that case, the increment and the
decrement go to different link wcids, and the count drifts upwards until
it blocks the station.
Keep the count on the wcid of the primary link, like the other peer-wide
state. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't stash io_uring encoded data across -EAGAIN
Returning -EAGAIN while leaving btrfs_uring_encoded_data in the cmd PDU
leaks if the request is cancelled or the ring exits before reissue.
io_uring does not free driver PDU allocations on cleanup.
Write: io_queue_sqe() always issues with IO_URING_F_NONBLOCK first, so
return -EAGAIN before allocating and free data on every exit.
Read: free on nowait -EAGAIN too; only -EIOCBQUEUED keeps the allocation
for btrfs_uring_read_finished(). |
| Pipecat is an open-source Python framework for building real-time voice and multimodal conversational agents. From 0.0.98 until 1.6.0, the pipecat-ai package's built-in development runner exposes unauthenticated endpoints including /start, /daily, and /daily-dialin-webhook that can create bot sessions and Daily rooms. The runner binds to localhost by default and is intended only for local development, so exploitation requires an operator to expose it to untrusted traffic through --host 0.0.0.0, a published port, or a tunnel without access controls. An unauthenticated caller can consume local resources and third-party quotas and, depending on configuration, receive a room URL and join token. Version 1.6.0 adds a prominent development-runner banner and documentation that clarifies the unauthenticated boundary and directs production deployments to an authenticated dispatcher or managed runtime, while the endpoint behavior remains by design. This issue is fixed in version 1.6.0. |
