Total
184 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-40148 | 1 Praison | 1 Praisonai | 2026-10-26 | N/A | 6.5 MEDIUM |
| PraisonAI is a multi-agent teams system. Prior to 4.5.128, the _safe_extractall() function in PraisonAI's recipe registry validates archive members against path traversal attacks but performs no checks on individual member sizes, cumulative extracted size, or member count before calling tar.extractall(). An attacker can publish a malicious recipe bundle containing highly compressible data (e.g., 10GB of zeros compressing to ~10MB) that exhausts the victim's disk when pulled via LocalRegistry.pull() or HttpRegistry.pull(). This vulnerability is fixed in 4.5.128. | |||||
| CVE-2026-40192 | 1 Python | 1 Pillow | 2026-10-26 | N/A | 7.5 HIGH |
| Pillow is a Python imaging library. Versions 10.3.0 through 12.1.1 did not limit the amount of GZIP-compressed data read when decoding a FITS image, making them vulnerable to decompression bomb attacks. A specially crafted FITS file could cause unbounded memory consumption, leading to denial of service (OOM crash or severe performance degradation). If users are unable to immediately upgrade, they should only open specific image formats, excluding FITS, as a workaround. | |||||
| CVE-2026-42886 | 2026-10-26 | N/A | 4.9 MEDIUM | ||
| Audiobookshelf is a self-hosted audiobook and podcast server. Prior to 2.32.2, the POST /api/backups/upload endpoint decompresses the details entry from an uploaded .audiobookshelf ZIP file entirely into memory using zip.entryData(), with no limit on the decompressed size. The upload middleware also has no file size limit. An admin user can upload a crafted ZIP containing a highly compressed details entry that, when decompressed, consumes hundreds of megabytes or gigabytes of memory, crashing the server process via out-of-memory. This vulnerability is fixed in 2.32.2. | |||||
| CVE-2026-93850 | 2026-10-26 | N/A | 6.5 MEDIUM | ||
| Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 fail to bind the volume of text extracted from an uploaded PDF which allows an authenticated user to exhaust server memory and cause a denial of service via a crafted PDF whose compressed content stream expands into a very large amount of text.. Mattermost Advisory ID: MMSA-2026-00769 | |||||
| CVE-2026-43970 | 2026-10-26 | N/A | N/A | ||
| Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in ninenines cowlib allows unauthenticated remote denial of service via memory exhaustion. cow_spdy:inflate/2 in cowlib passes peer-supplied compressed bytes directly to zlib:inflate/2 with no output size bound. The SPDY header compression dictionary (?ZDICT) is public, and zlib compresses long runs of repeated bytes at roughly 1024:1, so a few kilobytes of SPDY frame payload can decompress to gigabytes on the BEAM heap, OOM-killing the node. A single unauthenticated SPDY frame is sufficient to trigger the condition. The parsers for syn_stream, syn_reply, and headers frame types are all affected via cow_spdy:parse_headers/2. This issue affects cowlib from 0.1.0 before 2.16.1. | |||||
| CVE-2026-97200 | 2026-10-26 | N/A | N/A | ||
| Allocation of Resources Without Limits or Throttling vulnerability in hackney_conn in benoitc hackney allows a malicious HTTP server to exhaust client memory via an oversized or highly compressed response body. hackney:request/5 and hackney:body/1 return the whole response body, and nothing bounds how much the connection process buffers. Any server the client requests can trigger it. hackney_conn:read_full_body/2 and the HTTP/2 and HTTP/3 accumulators append every chunk until the body ends. With {auto_decompress, true} the buffered body is then inflated in one step with zlib:gunzip/1 or zlib:inflate/2, which return the whole output at once. This issue affects hackney: from 2.0.0-beta.1 before 4.9.0. | |||||
| CVE-2026-109584 | 2026-10-26 | N/A | N/A | ||
| Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a small HPACK-compressed HEADERS block. The block stores one large cookie value in the HPACK dynamic table and then references it tens of thousands of times with 1-byte indexed fields. In the reporter's run, a 49 KB block made a server with default settings allocate a 183 MB cookie binary before any application code ran, and every concurrent stream can repeat the cost. Bandit.HTTP2.Connection caps only the compressed block (max_header_block_size), and its check of the decoded list against max_header_list_size never fires because that setting defaults to :infinity. combine_cookie_crumbs/1 in lib/bandit/http2/stream.ex then joins every crumb into one binary. This issue affects bandit: from 0.3.3 before 1.14.0. | |||||
| CVE-2026-47774 | 2 Envoyproxy, Redhat | 2 Envoy, Openshift Service Mesh | 2026-10-26 | N/A | 7.5 HIGH |
| Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1, a vulnerability in Envoy's HTTP/2 downstream request processing allows an unauthenticated remote client to trigger excessive memory consumption, potentially resulting in OOM termination of the Envoy process and denial of service. The issue arises from the combination of two behaviors. First, cookie header bytes are not fully accounted for during request header size validation in Envoy. Second, HPACK header block limits in oghttp2/quiche are enforced on encoded bytes without a corresponding limit on total decoded header size. Together, these behaviors allow a malicious client to cause large decoded header allocations while bypassing the intended request header size protections. Versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1 contain a fix. No complete workaround is known short of applying a fix. Possible temporary mitigations include disabling downstream HTTP/2 where operationally feasible; enforcing stricter request header and cookie limits before traffic reaches Envoy; and monitoring Envoy memory usage for abnormal growth under HTTP/2 traffic. | |||||
| CVE-2026-54314 | 1 N8n | 1 N8n | 2026-10-26 | N/A | 7.5 HIGH |
| n8n is an open source workflow automation platform. Prior to 2.24.0, the Compression node's Decompress operation expanded attacker-controlled archives into memory without enforcing limits on decompressed output size. An unauthenticated attacker could send a small compressed archive to a public webhook workflow using this node, causing the n8n process to terminate due to memory exhaustion and disrupting all workflows in the same instance. This vulnerability is fixed in 2.24.0. | |||||
| CVE-2026-54278 | 1 Aiohttp | 1 Aiohttp | 2026-10-25 | N/A | 7.5 HIGH |
| AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, during cleanup it is possible for a compressed request body to be decompressed into memory in one chunk. An attacker may be able to send a compressed payload in specific situations that could be decompressed into memory, potentially leading to DoS (a zip bomb edge case). This vulnerability is fixed in 3.14.1. | |||||
| CVE-2026-53430 | 2026-10-25 | N/A | N/A | ||
| Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc (GRPC.Compressor.Gzip, GRPC.Message modules) allows a denial of service via a gzip decompression bomb. This vulnerability is associated with program files lib/grpc/compressor/gzip.ex, lib/grpc/message.ex and program routines 'Elixir.GRPC.Compressor.Gzip':decompress/1, 'Elixir.GRPC.Message':from_data/2. 'Elixir.GRPC.Compressor.Gzip':decompress/1 calls :zlib.gunzip/1 directly on attacker-controlled bytes with no decompressed-size limit, ratio check, or incremental decoding. Because this module is the registered gzip GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries the grpc-encoding: gzip header. :zlib.gunzip/1 allocates the entire decompressed result as a single binary, so a small highly compressible payload (for example a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single call. The max_receive_message_length limit is enforced only against the already-decompressed message, so it provides no protection. An unauthenticated remote peer can send a single crafted frame to exhaust the BEAM node's heap and trigger an out-of-memory kill. This issue affects grpc: from 0.4.0 before 1.0.0. | |||||
| CVE-2026-54233 | 1 Vllm | 1 Vllm | 2026-10-25 | N/A | 6.5 MEDIUM |
| vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.23.1rc0, vLLM's /v1/audio/transcriptions endpoint limits compressed upload size but not decoded PCM output. A 25MB OPUS file expands to ~14.9GB of float32 PCM at decode time. This vulnerability is fixed in 0.23.1rc0. | |||||
| CVE-2026-55195 | 2026-10-25 | N/A | N/A | ||
| py7zr is a Python-based library and utility to support 7zip archive compression, decompression, encryption and decryption. Prior to 1.1.3, py7zr's Worker.decompress() extracted archive entries without tracking total decompressed size, allowing a crafted .7z file such as a 15.6 KB archive that expands to 100 MB to exhaust disk or memory before extraction completes. This issue is fixed in version 1.1.3. | |||||
| CVE-2026-44018 | 1 Docling | 1 Docling | 2026-10-25 | N/A | 5.5 MEDIUM |
| Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.45.0 until 2.91.0, the METS-GBS backend's XML parsing and the input document format detection lacked security controls. An attacker could craft malicious METS-GBS archives that, when processed, could read sensitive files, exhaust system resources, or cause application crashes. This vulnerability is fixed in 2.91.0. | |||||
| CVE-2026-59803 | 2026-10-25 | N/A | 7.5 HIGH | ||
| rpcx through 1.9.3, fixed in commit 047aec1, contains a denial-of-service vulnerability in protocol.Message.Decode (protocol/message.go). When a message has the compression flag set, the payload is gzip-decompressed via util.Unzip with no limit on the decompressed output size. The only built-in size guard, protocol.MaxMessageLength, is checked against the compressed on-the-wire frame length, not the decompressed size, so it provides no protection. Because decoding (and decompression) occurs in readRequest before authentication, a single unauthenticated connection can send a small (under 2 MB) gzip-compressed message that expands to gigabytes of heap allocation, leading to out-of-memory conditions and service unavailability. | |||||
| CVE-2026-48044 | 1 Envoyproxy | 1 Envoy | 2026-10-25 | N/A | 7.5 HIGH |
| Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.23.0 until 1.35.11, 1.36.7, 1.37.3, and 1.38.1, a vulnerability has been identified in Envoy's zstd decompressor implementation (ZstdDecompressorImpl). When zstd decompression is enabled, processing a specially crafted, highly compressed zstd payload can lead to massive memory allocation. An attacker can exploit this to cause severe memory exhaustion, potentially resulting in an Out-Of-Memory (OOM) kill and Denial of Service (DoS) for the Envoy proxy. This vulnerability is fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1. | |||||
| CVE-2026-44160 | 1 Fluentd | 1 Fluentd | 2026-10-25 | N/A | 7.5 HIGH |
| Fluentd collects events from various data sources and writes them to files, RDBMS, NoSQL, IaaS, SaaS, Hadoop and so on. Prior to 1.19.3, Fluentd's in_http and in_forward plugins support gzip-compressed data but enforce limits only on compressed payloads through settings such as body_size_limit and chunk_size_limit, allowing crafted compressed payloads to decompress in memory to an excessive size and cause denial of service through memory exhaustion. This issue is fixed in version 1.19.3. | |||||
| CVE-2026-24264 | 2 Linux, Nvidia | 2 Linux Kernel, Triton Inference Server | 2026-10-25 | N/A | 7.5 HIGH |
| NVIDIA Triton Inference Server for Linux contains a vulnerability where an attacker can cause improper handling of highly compressed data. A successful exploit of this vulnerability might lead to denial of service. | |||||
| CVE-2026-61455 | 2026-10-25 | N/A | 6.5 MEDIUM | ||
| Grav before 2.0.1 contains a decompression bomb vulnerability in ZipArchiver::extract() that lacks limits on uncompressed size, file count, and nesting depth. Attackers can supply a crafted ZIP archive that expands to fill available disk space, causing denial of service by exhausting storage resources. | |||||
| CVE-2026-59193 | 1 Getgrav | 1 Grav | 2026-10-25 | N/A | 4.9 MEDIUM |
| Grav is a file-based Web platform. Prior to 2.0.0, an authenticated admin.super user can crash Grav or fill the disk by uploading a specially crafted ZIP archive through the Direct Install tool because Installer::unZip calls ZipArchive::extractTo without limits on uncompressed size, entry count, or directory depth. This issue is fixed in version 2.0.0. | |||||