CWE-409
AllowedImproper Handling of Highly Compressed Data (Data Amplification)
Abstraction: Base · Status: Incomplete
The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
148 vulnerabilities reference this CWE, most recent first.
GHSA-9P44-Q66P-XM6P
Vulnerability from github – Published: 2025-10-21 18:30 – Updated: 2025-10-27 20:01ProcessWire CMS 3.0.246 allows a low-privileged user with lang-edit to upload a crafted ZIP to Language Support that is auto-extracted without limits prior to validation, enabling resource-exhaustion Denial of Service.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "processwire/processwire"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.0.246"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-60790"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-21T21:04:22Z",
"nvd_published_at": "2025-10-21T18:15:36Z",
"severity": "MODERATE"
},
"details": "ProcessWire CMS 3.0.246 allows a low-privileged user with lang-edit to upload a crafted ZIP to Language Support that is auto-extracted without limits prior to validation, enabling resource-exhaustion Denial of Service.",
"id": "GHSA-9p44-q66p-xm6p",
"modified": "2025-10-27T20:01:33Z",
"published": "2025-10-21T18:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60790"
},
{
"type": "WEB",
"url": "https://github.com/processwire/processwire-issues/issues/2120"
},
{
"type": "WEB",
"url": "https://github.com/NomanProdhan/security-vulnerability-research/tree/master/CVE-2025-60790"
},
{
"type": "PACKAGE",
"url": "https://github.com/processwire/processwire"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "ProcessWire CMS vulnerable to resource-exhaustion Denial of Service"
}
GHSA-9QMJ-P674-G42J
Vulnerability from github – Published: 2025-03-28 15:31 – Updated: 2025-03-28 15:31IBM PowerVM Hypervisor FW1050.00 through FW1050.30 and FW1060.00 through FW1060.20 could allow a local user, under certain Linux processor combability mode configurations, to cause undetected data loss or errors when performing gzip compression using HW acceleration.
{
"affected": [],
"aliases": [
"CVE-2025-0986"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-28T14:15:19Z",
"severity": "MODERATE"
},
"details": "IBM PowerVM Hypervisor FW1050.00 through FW1050.30 and FW1060.00 through FW1060.20 could allow a local user, under certain Linux processor combability mode configurations, to cause undetected data loss or errors when performing gzip compression using HW acceleration.",
"id": "GHSA-9qmj-p674-g42j",
"modified": "2025-03-28T15:31:55Z",
"published": "2025-03-28T15:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0986"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7229349"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-C3F2-QG8V-25Q2
Vulnerability from github – Published: 2026-04-09 00:31 – Updated: 2026-04-10 17:18Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-h5qv-qjv4-pc5m. This link is maintained to preserve external references.
Original Description
Unfurl before 2026.04 contains an unbounded zlib decompression vulnerability in parse_compressed.py that allows remote attackers to cause denial of service. Attackers can submit highly compressed payloads via URL parameters to the /json/visjs endpoint that expand to gigabytes, exhausting server memory and crashing the service.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "dfir-unfurl"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.04"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T17:18:31Z",
"nvd_published_at": "2026-04-08T22:16:24Z",
"severity": "HIGH"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-h5qv-qjv4-pc5m. This link is maintained to preserve external references.\n\n### Original Description\nUnfurl before\u00a02026.04 contains an unbounded zlib decompression vulnerability in parse_compressed.py that allows remote attackers to cause denial of service. Attackers can submit highly compressed payloads via URL parameters to the /json/visjs endpoint that expand to gigabytes, exhausting server memory and crashing the service.",
"id": "GHSA-c3f2-qg8v-25q2",
"modified": "2026-04-10T17:18:31Z",
"published": "2026-04-09T00:31:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/obsidianforensics/unfurl/security/advisories/GHSA-h5qv-qjv4-pc5m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40036"
},
{
"type": "WEB",
"url": "https://github.com/RyanDFIR/unfurl/pull/243"
},
{
"type": "PACKAGE",
"url": "https://github.com/RyanDFIR/unfurl"
},
{
"type": "WEB",
"url": "https://github.com/RyanDFIR/unfurl/releases/tag/v2026.04"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/dfir-unfurl-denial-of-service-via-unbounded-zlib-decompression"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: Unfurl\u0027s unbounded zlib decompression allows decompression bomb DoS",
"withdrawn": "2026-04-10T17:18:31Z"
}
GHSA-C5Q2-7R4C-MV6G
Vulnerability from github – Published: 2024-03-07 22:54 – Updated: 2025-02-13 19:07Impact
An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.
Patches
The problem is fixed in the following packages and versions: - github.com/go-jose/go-jose/v4 version 4.0.1 - github.com/go-jose/go-jose/v3 version 3.0.3 - gopkg.in/go-jose/go-jose.v2 version 2.6.3
The problem will not be fixed in the following package because the package is archived: - gopkg.in/square/go-jose.v2
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "gopkg.in/go-jose/go-jose.v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "gopkg.in/square/go-jose.v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-28180"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-07T22:54:44Z",
"nvd_published_at": "2024-03-09T01:15:07Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.\n\n### Patches\nThe problem is fixed in the following packages and versions:\n- github.com/go-jose/go-jose/v4 version 4.0.1\n- github.com/go-jose/go-jose/v3 version 3.0.3\n- gopkg.in/go-jose/go-jose.v2 version 2.6.3\n\nThe problem will not be fixed in the following package because the package is archived:\n- gopkg.in/square/go-jose.v2",
"id": "GHSA-c5q2-7r4c-mv6g",
"modified": "2025-02-13T19:07:25Z",
"published": "2024-03-07T22:54:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/security/advisories/GHSA-c5q2-7r4c-mv6g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28180"
},
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/commit/0dd4dd541c665fb292d664f77604ba694726f298"
},
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/commit/add6a284ea0f844fd6628cba637be5451fe4b28a"
},
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/commit/f4c051a0653d78199a053892f7619ebf96339502"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-jose/go-jose"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GD2GSBQTBLYADASUBHHZV2CZPTSLIPQJ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I6MMWFBOXJA6ZCXNVPDFJ4XMK5PVG5RG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IJ6LAJJ2FTA2JVVOACCV5RZTOIZLXUNJ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JNPMXL36YGS3GQEVI3Q5HKHJ7YAAQXL5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KXKGNCRU7OTM5AHC7YIYBNOWI742PRMY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MSOMHDKRPU3A2JEMRODT2IREDFBLVPGS"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UG5FSEYJ3GP27FZXC5YAAMMEC5XWKJHG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UJO2U5ACZVACNQXJ5EBRFLFW6DP5BROY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XJDO5VSIAOGT2WP63AXAAWNRSVJCNCRH"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Go JOSE vulnerable to Improper Handling of Highly Compressed Data (Data Amplification)"
}
GHSA-C5VG-26P8-Q8CR
Vulnerability from github – Published: 2025-05-05 19:32 – Updated: 2025-05-05 22:07Vulnerable MobSF Versions: <= v4.3.2
Details: MobSF is a widely adopted mobile application security testing tool used by security teams across numerous organizations. Typically, MobSF is deployed on centralized internal or cloud-based servers that also host other security tools and web applications. Access to the MobSF web interface is often granted to internal security teams, audit teams, and external vendors.
MobSF provides a feature that allows users to upload ZIP files for static analysis. Upon upload, these ZIP files are automatically extracted and stored within the MobSF directory. However, this functionality lacks a check on the total uncompressed size of the ZIP file, making it vulnerable to a ZIP of Death (zip bomb) attack.
Due to the absence of safeguards against oversized extractions, an attacker can craft a specially prepared ZIP file that is small in compressed form but expands to a massive size upon extraction. Exploiting this, an attacker can exhaust the server's disk space, leading to a complete denial of service (DoS) not just for MobSF, but also for any other applications or websites hosted on the same server.
Attack Scenario: Suppose the server hosting MobSF has 5 GB of free disk space..
A malicious user will first create a genuine hello world application code using android studio and inside this code directory (app//src/main/java/APK_PATH/bomb.txt) he'll place a bomb.txt file.
This bomb.txt file will have billions of zeros to increase the file size on storage and make it to 4.99 GB. Now suppose the resultant hello world code directory including original code and bomb.txt files will be of 5GB, so the attacker will compress the entire hello world code directory to zip and resultant zip will be around 12-15 MBs only.
An attacker will upload this zip bomb using the MobSF web interface or API. So an attacker will spend only 12-15 MB of his bandwidth.
Now the MobSF tool will extract that zip file and it'll be automatically converted into its original size 5GB.
So now a web server will be forced to store 5GB of data and its storage will be exhausted by an attacker's single request.
Web server's storage and resources will not be able to handle other running websites or applications as the storage is exhausted. This way an attacker can achieve complete Web Server Resource Exhaustion.
Impact: 1. This vulnerability can lead to complete server disruption in an organization which can affect other internal portals and tools too (which are hosted on the same server). 2. If some organization has created their customised cloud based mobile security tool using MobSF core then an attacker can exploit this vulnerability to crash their servers.
POC:
1. Screen Recording :
https://drive.google.com/file/d/1x7GEPJr2T04Ij5ZFQQtGWvUWXtM4M4aw/view?usp=sharing
2. POC Zip Bomb File (Upon extraction this file will consume 6GB of storage) : https://drive.google.com/file/d/1N3apL1ySMecnt3HUQcDcuH7hsjPrdwUj/view?usp=sharing
Mitigation: It is recommended to implement a safeguard that checks the total uncompressed size of any uploaded ZIP file before extraction. If the estimated uncompressed size exceeds a safe threshold (e.g., 100 MB), MobSF should reject the file and notify the user.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mobsf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "4.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46730"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-05T19:32:27Z",
"nvd_published_at": "2025-05-05T20:15:21Z",
"severity": "MODERATE"
},
"details": "**Vulnerable MobSF Versions:** \u003c= v4.3.2\n\n**Details:**\nMobSF is a widely adopted mobile application security testing tool used by security teams across numerous organizations. Typically, MobSF is deployed on centralized internal or cloud-based servers that also host other security tools and web applications. Access to the MobSF web interface is often granted to internal security teams, audit teams, and external vendors. \n\nMobSF provides a feature that allows users to upload ZIP files for static analysis. Upon upload, these ZIP files are automatically extracted and stored within the MobSF directory. However, this functionality lacks a check on the total uncompressed size of the ZIP file, making it vulnerable to a ZIP of Death (zip bomb) attack.\n\nDue to the absence of safeguards against oversized extractions, an attacker can craft a specially prepared ZIP file that is small in compressed form but expands to a massive size upon extraction. Exploiting this, an attacker can exhaust the server\u0027s disk space, leading to a complete denial of service (DoS) not just for MobSF, but also for any other applications or websites hosted on the same server.\n\n**Attack Scenario:**\nSuppose the server hosting MobSF has 5 GB of free disk space..\n\nA malicious user will first create a genuine hello world application code using android studio and inside this code directory (app//src/main/java/APK_PATH/bomb.txt) he\u0027ll place a bomb.txt file. \n\nThis bomb.txt file will have billions of zeros to increase the file size on storage and make it to 4.99 GB. Now suppose the resultant hello world code directory including original code and bomb.txt files will be of 5GB, so the attacker will compress the entire hello world code directory to zip and resultant zip will be around 12-15 MBs only.\n\nAn attacker will upload this zip bomb using the MobSF web interface or API. So an attacker will spend only 12-15 MB of his bandwidth. \n\nNow the MobSF tool will extract that zip file and it\u0027ll be automatically converted into its original size 5GB.\n\nSo now a web server will be forced to store 5GB of data and its storage will be exhausted by an attacker\u0027s single request. \n\nWeb server\u0027s storage and resources will not be able to handle other running websites or applications as the storage is exhausted. This way an attacker can achieve complete Web Server Resource Exhaustion. \n \n**Impact:**\n1. This vulnerability can lead to complete server disruption in an organization which can affect other internal portals and tools too (which are hosted on the same server).\n2. If some organization has created their customised cloud based mobile security tool using MobSF core then an attacker can exploit this vulnerability to crash their servers.\n\n**POC:**\n1. Screen Recording : \nhttps://drive.google.com/file/d/1x7GEPJr2T04Ij5ZFQQtGWvUWXtM4M4aw/view?usp=sharing\n2. POC Zip Bomb File (Upon extraction this file will consume 6GB of storage) : https://drive.google.com/file/d/1N3apL1ySMecnt3HUQcDcuH7hsjPrdwUj/view?usp=sharing\n\n**Mitigation:**\nIt is recommended to implement a safeguard that checks the total uncompressed size of any uploaded ZIP file before extraction. If the estimated uncompressed size exceeds a safe threshold (e.g., 100 MB), MobSF should reject the file and notify the user.",
"id": "GHSA-c5vg-26p8-q8cr",
"modified": "2025-05-05T22:07:44Z",
"published": "2025-05-05T19:32:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/security/advisories/GHSA-c5vg-26p8-q8cr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46730"
},
{
"type": "WEB",
"url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/6987a946485a795f4fd38cebdb4860b368a1995d"
},
{
"type": "PACKAGE",
"url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Mobile Security Framework (MobSF) Allows Web Server Resource Exhaustion via ZIP of Death Attack"
}
GHSA-CGQF-3CQ5-WVCJ
Vulnerability from github – Published: 2024-03-06 18:24 – Updated: 2026-02-17 19:37Impact
The Apollo Router is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation. Affected versions are subject to a Denial-of-Service (DoS) type vulnerability. When receiving compressed HTTP payloads, affected versions of the Router evaluate the limits.http_max_request_bytes configuration option after the entirety of the compressed payload is decompressed. If affected versions of the Router receive highly compressed payloads, this could result in significant memory consumption while the compressed payload is expanded.
Patches
Router version 1.40.2 has a fix for the vulnerability.
Workarounds
If you are unable to upgrade, you may be able to implement mitigations at proxies or load balancers positioned in front of your Router fleet (e.g. Nginx, HAProxy, or cloud-native WAF services) by creating limits on HTTP body upload size.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "apollo-router"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.5"
},
{
"fixed": "1.40.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-28101"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-06T18:24:17Z",
"nvd_published_at": "2024-03-21T02:52:23Z",
"severity": "HIGH"
},
"details": "### Impact\nThe Apollo Router is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation. Affected versions are subject to a Denial-of-Service (DoS) type vulnerability. When receiving compressed HTTP payloads, affected versions of the Router evaluate the `limits.http_max_request_bytes` configuration option after the entirety of the compressed payload is decompressed. If affected versions of the Router receive highly compressed payloads, this could result in significant memory consumption while the compressed payload is expanded. \n\n### Patches\nRouter version 1.40.2 has a fix for the vulnerability.\n\n### Workarounds\nIf you are unable to upgrade, you may be able to implement mitigations at proxies or load balancers positioned in front of your Router fleet (e.g. Nginx, HAProxy, or cloud-native WAF services) by creating limits on HTTP body upload size.",
"id": "GHSA-cgqf-3cq5-wvcj",
"modified": "2026-02-17T19:37:19Z",
"published": "2024-03-06T18:24:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apollographql/router/security/advisories/GHSA-cgqf-3cq5-wvcj"
},
{
"type": "WEB",
"url": "https://github.com/apollographql/router/commit/9e9527c73c8f34fc8438b09066163cd42520f413"
},
{
"type": "PACKAGE",
"url": "https://github.com/apollographql/router"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Apollo Router\u0027s Compressed Payloads do not respect HTTP Payload Limits"
}
GHSA-F2H6-7XFR-XM8W
Vulnerability from github – Published: 2026-04-10 19:26 – Updated: 2026-04-10 19:26Summary
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().
Details
The vulnerable function is _safe_extractall() at src/praisonai/praisonai/recipe/registry.py:131-162:
def _safe_extractall(tar: tarfile.TarFile, dest_dir: Path) -> None:
dest_resolved = dest_dir.resolve()
for member in tar.getmembers():
member_path = Path(member.name)
# Reject absolute paths
if member_path.is_absolute():
raise RegistryError(...)
# Reject '..' components
if '..' in member_path.parts:
raise RegistryError(...)
# Reject resolved paths escaping dest_dir
resolved = (dest_resolved / member_path).resolve()
if not str(resolved).startswith(str(dest_resolved) + os.sep) and resolved != dest_resolved:
raise RegistryError(...)
# All members validated — safe to extract
tar.extractall(dest_dir) # <-- No size limit
The function iterates all tar members and checks for path traversal (absolute paths, .. components, resolved path escaping), but never inspects member.size. The TarInfo.size attribute is available on every member and represents the uncompressed size, but it is never read.
This function is called from two locations:
- LocalRegistry.pull() at line 396-397
- HttpRegistry.pull() at line 791-792
The publish() method at line 296-298 only copies the compressed bundle via shutil.copy2(), so the bomb only detonates when a victim calls pull().
No size limits, upload quotas, or decompression guards exist anywhere in the registry module.
PoC
# Step 1: Create a malicious recipe bundle
mkdir bomb && cd bomb
cat > manifest.json << 'EOF'
{"name": "useful-recipe", "version": "1.0.0", "description": "Helpful AI recipe", "tags": ["ai"], "files": ["agent.yaml"]}
EOF
# Create a 10GB file of zeros (compresses to ~10MB with gzip)
dd if=/dev/zero of=agent.yaml bs=1M count=10240
# Bundle it as a .praison file
tar czf ../useful-recipe-1.0.0.praison manifest.json agent.yaml
cd ..
# Step 2: Publish to local registry (~10MB stored)
python -c "
from praisonai.recipe.registry import LocalRegistry
reg = LocalRegistry()
reg.publish('useful-recipe-1.0.0.praison')
"
# Step 3: Victim pulls — extracts 10GB to disk
python -c "
from praisonai.recipe.registry import LocalRegistry
reg = LocalRegistry()
reg.pull('useful-recipe')
"
# Result: 10GB+ written to disk, potential disk exhaustion
Impact
- Disk exhaustion: A small compressed bundle (~10MB) can extract to 10GB+ of data, filling the victim's disk and causing denial of service for PraisonAI and potentially other applications on the same system.
- No authentication required: The local registry has no access controls on
publish(), and HTTP registry bundles are fetched from remote servers that the attacker controls. - Silent detonation: The extraction happens automatically during
pull()with no progress indication or size warning to the user.
Recommended Fix
Add a maximum extraction size limit to _safe_extractall():
MAX_EXTRACT_SIZE = 500 * 1024 * 1024 # 500MB
MAX_MEMBER_COUNT = 1000
def _safe_extractall(tar: tarfile.TarFile, dest_dir: Path) -> None:
dest_resolved = dest_dir.resolve()
members = tar.getmembers()
if len(members) > MAX_MEMBER_COUNT:
raise RegistryError(
f"Archive contains too many members ({len(members)} > {MAX_MEMBER_COUNT})"
)
total_size = 0
for member in members:
member_path = Path(member.name)
if member_path.is_absolute():
raise RegistryError(
f"Refusing to extract absolute path in archive: {member.name}"
)
if '..' in member_path.parts:
raise RegistryError(
f"Refusing to extract path traversal in archive: {member.name}"
)
resolved = (dest_resolved / member_path).resolve()
if not str(resolved).startswith(str(dest_resolved) + os.sep) and resolved != dest_resolved:
raise RegistryError(
f"Refusing to extract path escaping target directory: {member.name}"
)
total_size += member.size
if total_size > MAX_EXTRACT_SIZE:
raise RegistryError(
f"Archive extraction would exceed size limit "
f"({total_size} > {MAX_EXTRACT_SIZE} bytes)"
)
tar.extractall(dest_dir)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "PraisonAI"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.128"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40148"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T19:26:21Z",
"nvd_published_at": "2026-04-09T22:16:35Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `_safe_extractall()` function in PraisonAI\u0027s 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\u0027s disk when pulled via `LocalRegistry.pull()` or `HttpRegistry.pull()`.\n\n## Details\n\nThe vulnerable function is `_safe_extractall()` at `src/praisonai/praisonai/recipe/registry.py:131-162`:\n\n```python\ndef _safe_extractall(tar: tarfile.TarFile, dest_dir: Path) -\u003e None:\n dest_resolved = dest_dir.resolve()\n for member in tar.getmembers():\n member_path = Path(member.name)\n # Reject absolute paths\n if member_path.is_absolute():\n raise RegistryError(...)\n # Reject \u0027..\u0027 components\n if \u0027..\u0027 in member_path.parts:\n raise RegistryError(...)\n # Reject resolved paths escaping dest_dir\n resolved = (dest_resolved / member_path).resolve()\n if not str(resolved).startswith(str(dest_resolved) + os.sep) and resolved != dest_resolved:\n raise RegistryError(...)\n # All members validated \u2014 safe to extract\n tar.extractall(dest_dir) # \u003c-- No size limit\n```\n\nThe function iterates all tar members and checks for path traversal (absolute paths, `..` components, resolved path escaping), but never inspects `member.size`. The `TarInfo.size` attribute is available on every member and represents the uncompressed size, but it is never read.\n\nThis function is called from two locations:\n- `LocalRegistry.pull()` at line 396-397\n- `HttpRegistry.pull()` at line 791-792\n\nThe `publish()` method at line 296-298 only copies the compressed bundle via `shutil.copy2()`, so the bomb only detonates when a victim calls `pull()`.\n\nNo size limits, upload quotas, or decompression guards exist anywhere in the registry module.\n\n## PoC\n\n```bash\n# Step 1: Create a malicious recipe bundle\nmkdir bomb \u0026\u0026 cd bomb\n\ncat \u003e manifest.json \u003c\u003c \u0027EOF\u0027\n{\"name\": \"useful-recipe\", \"version\": \"1.0.0\", \"description\": \"Helpful AI recipe\", \"tags\": [\"ai\"], \"files\": [\"agent.yaml\"]}\nEOF\n\n# Create a 10GB file of zeros (compresses to ~10MB with gzip)\ndd if=/dev/zero of=agent.yaml bs=1M count=10240\n\n# Bundle it as a .praison file\ntar czf ../useful-recipe-1.0.0.praison manifest.json agent.yaml\ncd ..\n\n# Step 2: Publish to local registry (~10MB stored)\npython -c \"\nfrom praisonai.recipe.registry import LocalRegistry\nreg = LocalRegistry()\nreg.publish(\u0027useful-recipe-1.0.0.praison\u0027)\n\"\n\n# Step 3: Victim pulls \u2014 extracts 10GB to disk\npython -c \"\nfrom praisonai.recipe.registry import LocalRegistry\nreg = LocalRegistry()\nreg.pull(\u0027useful-recipe\u0027)\n\"\n# Result: 10GB+ written to disk, potential disk exhaustion\n```\n\n## Impact\n\n- **Disk exhaustion:** A small compressed bundle (~10MB) can extract to 10GB+ of data, filling the victim\u0027s disk and causing denial of service for PraisonAI and potentially other applications on the same system.\n- **No authentication required:** The local registry has no access controls on `publish()`, and HTTP registry bundles are fetched from remote servers that the attacker controls.\n- **Silent detonation:** The extraction happens automatically during `pull()` with no progress indication or size warning to the user.\n\n## Recommended Fix\n\nAdd a maximum extraction size limit to `_safe_extractall()`:\n\n```python\nMAX_EXTRACT_SIZE = 500 * 1024 * 1024 # 500MB\nMAX_MEMBER_COUNT = 1000\n\ndef _safe_extractall(tar: tarfile.TarFile, dest_dir: Path) -\u003e None:\n dest_resolved = dest_dir.resolve()\n members = tar.getmembers()\n \n if len(members) \u003e MAX_MEMBER_COUNT:\n raise RegistryError(\n f\"Archive contains too many members ({len(members)} \u003e {MAX_MEMBER_COUNT})\"\n )\n \n total_size = 0\n for member in members:\n member_path = Path(member.name)\n if member_path.is_absolute():\n raise RegistryError(\n f\"Refusing to extract absolute path in archive: {member.name}\"\n )\n if \u0027..\u0027 in member_path.parts:\n raise RegistryError(\n f\"Refusing to extract path traversal in archive: {member.name}\"\n )\n resolved = (dest_resolved / member_path).resolve()\n if not str(resolved).startswith(str(dest_resolved) + os.sep) and resolved != dest_resolved:\n raise RegistryError(\n f\"Refusing to extract path escaping target directory: {member.name}\"\n )\n total_size += member.size\n if total_size \u003e MAX_EXTRACT_SIZE:\n raise RegistryError(\n f\"Archive extraction would exceed size limit \"\n f\"({total_size} \u003e {MAX_EXTRACT_SIZE} bytes)\"\n )\n tar.extractall(dest_dir)\n```",
"id": "GHSA-f2h6-7xfr-xm8w",
"modified": "2026-04-10T19:26:21Z",
"published": "2026-04-10T19:26:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-f2h6-7xfr-xm8w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40148"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
},
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/releases/tag/v4.5.128"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "PraisonAI Vulnerable to Decompression Bomb DoS via Recipe Bundle Extraction Without Size Limits"
}
GHSA-FFJ4-JQ7M-9G6V
Vulnerability from github – Published: 2026-01-13 21:54 – Updated: 2026-01-13 21:54Summary
GuardDog's safe_extract() function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.
Vulnerability Details
Affected Component: guarddog/utils/archives.py - safe_extract() function
Vulnerability Type: CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)
Severity: HIGH (CVSS ~8)
Attack Vector: Network (malicious package uploaded to PyPI/npm) or local
Root Cause
The safe_extract() function handles TAR files securely using the tarsafe library, but ZIP file extraction has no size validation:
elif zipfile.is_zipfile(source_archive):
with zipfile.ZipFile(source_archive, "r") as zip:
for file in zip.namelist():
zip.extract(file, path=os.path.join(target_directory, file))
Missing protections:
- ❌ No decompressed size limit
- ❌ No compression ratio validation
- ❌ No file count limits
- ❌ No total extracted size validation
Impact
Denial of Service Scenarios
1. CI/CD Pipeline Disruption - Attacker publishes malicious package to PyPI - Developer adds package to requirements.txt - CI/CD runs GuardDog scan - Disk fills (GitHub Actions: standard 14GB limit) - All deployments blocked
2. Resource Exhaustion
- Local development environments
- Security scanning infrastructure
- Automated scanning systems
- Docker containers with limited disk
3. Supply Chain Attack Amplification - Single malicious package blocks security scanning - Prevents detection of other malicious packages - Forces manual intervention - Increases security team workload
Recommended Fix
Add size validation for ZIP files similar to what tarsafe provides for TAR files
Configuration Options
Make limits configurable via environment variables or config file
Additional Improvements
- Add warning logs when archives approach limits
- Provide clear error messages for users
- Document limits in user-facing documentation
- Add tests for zip bomb detection
- Consider using a safe ZIP library (similar to tarsafe)
Credit
Reported by: Charbel (dwbruijn)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "guarddog"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22870"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T21:54:41Z",
"nvd_published_at": "2026-01-13T21:15:55Z",
"severity": "HIGH"
},
"details": "## Summary\n\nGuardDog\u0027s `safe_extract()` function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.\n\n## Vulnerability Details\n\n**Affected Component:** `guarddog/utils/archives.py` - `safe_extract()` function \n**Vulnerability Type:** CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb) \n**Severity:** HIGH (CVSS ~8) \n**Attack Vector:** Network (malicious package uploaded to PyPI/npm) or local\n\n### Root Cause\n\nThe `safe_extract()` function handles TAR files securely using the `tarsafe` library, but ZIP file extraction has no size validation:\n```python\nelif zipfile.is_zipfile(source_archive):\n with zipfile.ZipFile(source_archive, \"r\") as zip:\n for file in zip.namelist():\n zip.extract(file, path=os.path.join(target_directory, file))\n```\n\n**Missing protections:**\n- \u274c No decompressed size limit\n- \u274c No compression ratio validation \n- \u274c No file count limits\n- \u274c No total extracted size validation\n\n## Impact\n\n### Denial of Service Scenarios\n\n**1. CI/CD Pipeline Disruption**\n- Attacker publishes malicious package to PyPI\n- Developer adds package to requirements.txt\n- CI/CD runs GuardDog scan\n- Disk fills (GitHub Actions: standard 14GB limit)\n- All deployments blocked\n\n**2. Resource Exhaustion**\n- Local development environments\n- Security scanning infrastructure \n- Automated scanning systems\n- Docker containers with limited disk\n\n**3. Supply Chain Attack Amplification**\n- Single malicious package blocks security scanning\n- Prevents detection of other malicious packages\n- Forces manual intervention\n- Increases security team workload\n\n## Recommended Fix\n\nAdd size validation for ZIP files similar to what `tarsafe` provides for TAR files\n\n### Configuration Options\n\nMake limits configurable via environment variables or config file\n\n## Additional Improvements\n\n1. **Add warning logs** when archives approach limits\n2. **Provide clear error messages** for users\n3. **Document limits** in user-facing documentation\n4. **Add tests** for zip bomb detection\n5. **Consider using a safe ZIP library** (similar to tarsafe)\n\n## Credit\n\nReported by: Charbel (dwbruijn)",
"id": "GHSA-ffj4-jq7m-9g6v",
"modified": "2026-01-13T21:54:42Z",
"published": "2026-01-13T21:54:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/DataDog/guarddog/security/advisories/GHSA-ffj4-jq7m-9g6v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22870"
},
{
"type": "WEB",
"url": "https://github.com/DataDog/guarddog/commit/c3fb07b4838945f42497e78b7a02bcfb1e63969b"
},
{
"type": "PACKAGE",
"url": "https://github.com/DataDog/guarddog"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "GuardDog Zip Bomb Vulnerability in safe_extract() Allows DoS"
}
GHSA-FJRM-76X2-C4Q4
Vulnerability from github – Published: 2026-04-08 00:16 – Updated: 2026-06-06 00:25Summary
The fix for GHSA-j857-7rvv-vj97 in v1.5.6 is weak in that it does not allow to fully control the amount of plaintext the receiver is willing to deal with and provides just a weak upper bound. The patch limits input token size to 250KB but does not validate the decompressed output size. An unauthenticated attacker can craft a JWE token under the 250KB input limit that decompresses to very large data that may exceed small devices memory availability, causing Denial of Service via memory exhaustion.
Although this is technically not unbounded I do recognize that it may be too much for devices and is something that could be surprising to developers, and we can do better than that.
NOTE: the original report was sloppy (probably AI slop) and claimed arbitrary memory consumption, but simple testing showed that while 100MB could be decompressed a 1GB output was denied because the token exceeded the 250K compressed serialization.
NOTE WELL: The proposed solution was also sloppy, proposing to first decompress the data completely in memory (therefore causing the memory exhaustion) and then checking how much memory was already used to deny the operation. I intentionally left the "details" section untouched to show how bad AI slop is and how uncritical the submitter was, even as it was obvious the "suggested fix" is actually no solution at all, as it was using the very call that he claimed was causing "arbitrary" memory exhaustion and wrapping it around an "if" ... the actual solution is in the resolving commit in version 1.5.7
Details
The vulnerable code in jwcrypto/jwe.py:
if len(data) > default_max_compressed_size:
raise InvalidJWEData('Compressed data exceeds maximum allowed size')
self.plaintext = zlib.decompress(data, -zlib.MAX_WBITS)
The check validates data which is the compressed bytes, not the decompressed output. A 132KB token (under the 250KB limit) can decompress to approximately 100MB with no error raised.
PoC
Tested on jwcrypto 1.5.6 (patched version):
import zlib
from jwcrypto import jwe
from jwcrypto.jwk import JWK
import time
key = JWK.generate(kty='oct', size=128)
bomb_data = b"A" * 1024 * 1024 * 100 # 100MB uncompressed
token = jwe.JWE(
plaintext=bomb_data,
protected={"alg": "A128KW", "enc": "A128GCM", "zip": "DEF"}
)
token.add_recipient(key)
serialized = token.serialize(compact=True)
print(f"Token size: {len(serialized)/1024:.1f} KB") # 132.8 KB — under 250KB limit
tok2 = jwe.JWE()
tok2.deserialize(serialized, key)
print(f"Decompressed: {len(tok2.plaintext)/1024/1024:.0f} MB") # 100 MB
Output:
Token size: 132.8 KB
Decompressed: 100 MB
Impact
An unauthenticated attacker can exhaust server memory by sending crafted JWE tokens with ZIP compression. The existing patch (v1.5.6) does not prevent this attack. An unauthenticated attacker can cause memory exhaustion on memory-constrained systems. A token under the 250KB input limit can decompress to approximately 100MB.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.5.6"
},
"package": {
"ecosystem": "PyPI",
"name": "jwcrypto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39373"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T00:16:14Z",
"nvd_published_at": "2026-04-07T20:16:32Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe fix for GHSA-j857-7rvv-vj97 in v1.5.6 is weak in that it does not allow to fully control the amount of plaintext the receiver is willing to deal with and provides just a weak upper bound. The patch limits input token size to 250KB but does not validate the decompressed output size. An unauthenticated attacker can craft a JWE token under the 250KB input limit that decompresses to very large data that may exceed small devices memory availability, causing Denial of Service via memory exhaustion.\n\nAlthough this is technically not unbounded I do recognize that it may be too much for devices and is something that could be surprising to developers, and we can do better than that.\n\nNOTE: the original report was sloppy (probably AI slop) and claimed arbitrary memory consumption, but simple testing showed that while 100MB could be decompressed a 1GB output was denied because the token exceeded the 250K compressed serialization.\n\nNOTE WELL: The proposed solution was also sloppy, proposing to first decompress the data completely in memory (therefore causing the memory exhaustion) and then checking how much memory was already used to deny the operation. I _intentionally_ left the \"details\" section untouched to show how bad AI slop is and how _uncritical_ the submitter was, even as it was obvious the \"suggested fix\" is actually no solution at all, as it was using the very call that he claimed was causing \"arbitrary\" memory exhaustion and wrapping it around an \"if\" ... the actual solution is in the resolving commit in version 1.5.7\n\n### Details\nThe vulnerable code in `jwcrypto/jwe.py`:\n```python\nif len(data) \u003e default_max_compressed_size:\n raise InvalidJWEData(\u0027Compressed data exceeds maximum allowed size\u0027)\nself.plaintext = zlib.decompress(data, -zlib.MAX_WBITS)\n```\n\nThe check validates `data` which is the **compressed** bytes, not the decompressed output. A 132KB token (under the 250KB limit) can decompress to approximately 100MB with no error raised.\n\n### PoC\nTested on jwcrypto 1.5.6 (patched version):\n```python\nimport zlib\nfrom jwcrypto import jwe\nfrom jwcrypto.jwk import JWK\nimport time\n\nkey = JWK.generate(kty=\u0027oct\u0027, size=128)\nbomb_data = b\"A\" * 1024 * 1024 * 100 # 100MB uncompressed\n\ntoken = jwe.JWE(\n plaintext=bomb_data,\n protected={\"alg\": \"A128KW\", \"enc\": \"A128GCM\", \"zip\": \"DEF\"}\n)\ntoken.add_recipient(key)\nserialized = token.serialize(compact=True)\nprint(f\"Token size: {len(serialized)/1024:.1f} KB\") # 132.8 KB \u2014 under 250KB limit\n\ntok2 = jwe.JWE()\ntok2.deserialize(serialized, key)\nprint(f\"Decompressed: {len(tok2.plaintext)/1024/1024:.0f} MB\") # 100 MB\n```\n\nOutput:\n```\nToken size: 132.8 KB\nDecompressed: 100 MB\n```\n\n### Impact\nAn unauthenticated attacker can exhaust server memory by sending crafted JWE tokens with ZIP compression. The existing patch (v1.5.6) does not prevent this attack. An unauthenticated attacker can cause memory exhaustion on memory-constrained systems. A token under the 250KB input limit can decompress to approximately 100MB.",
"id": "GHSA-fjrm-76x2-c4q4",
"modified": "2026-06-06T00:25:45Z",
"published": "2026-04-08T00:16:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/latchset/jwcrypto/security/advisories/GHSA-fjrm-76x2-c4q4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39373"
},
{
"type": "WEB",
"url": "https://github.com/latchset/jwcrypto/commit/25db861d8b29434838669a94a843af03d29ea6ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/latchset/jwcrypto"
},
{
"type": "WEB",
"url": "https://github.com/latchset/jwcrypto/releases/tag/v1.5.7"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/jwcrypto/PYSEC-2026-70.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "JWCrypto: JWE ZIP decompression bomb"
}
GHSA-G3CQ-J2XW-WF74
Vulnerability from github – Published: 2026-06-15 20:09 – Updated: 2026-06-15 20:09Summary
During cleanup it is possible for a compressed request body to be decompressed into memory in one chunk.
Impact
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).
Workaround
Disable compression if unable to upgrade.
Patch: https://github.com/aio-libs/aiohttp/commit/4f7480e474cccc6a8cc2c92ad3f17a31dedf8232
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.14.0"
},
"package": {
"ecosystem": "PyPI",
"name": "aiohttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.14.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54278"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T20:09:51Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nDuring cleanup it is possible for a compressed request body to be decompressed into memory in one chunk.\n\n### Impact\n\nAn 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).\n\n### Workaround\n\nDisable compression if unable to upgrade.\n\n-----\n\nPatch: https://github.com/aio-libs/aiohttp/commit/4f7480e474cccc6a8cc2c92ad3f17a31dedf8232",
"id": "GHSA-g3cq-j2xw-wf74",
"modified": "2026-06-15T20:09:51Z",
"published": "2026-06-15T20:09:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-g3cq-j2xw-wf74"
},
{
"type": "PACKAGE",
"url": "https://github.com/aio-libs/aiohttp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "aiohttp: Unread Compressed Request Bodies Bypass client_max_size During Cleanup"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.