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.
168 vulnerabilities reference this CWE, most recent first.
GHSA-R3XG-RG9J-67FV
Vulnerability from github – Published: 2026-06-03 21:13 – Updated: 2026-07-21 15:04Impact
The METS-GBS backend's XML parsing and the input document format detection lacked security controls, enabling: - XML External Entity (XXE) attacks to read local files or cause denial of service - Decompression bombs (zip bombs) to exhaust memory and disk space - Unbounded archive extraction consuming system resources
An attacker could craft malicious METS-GBS archives that, when processed, could read sensitive files, exhaust system resources, or cause application crashes.
Patches
Fixed in version 2.91.0. The fix implements:
- Secure XML parsing with resolve_entities=False, load_dtd=False, and no_network=True
- Configurable limits: 300 MB total extraction size, 10 MB per file, 1000 member count
- Cumulative size tracking across all extractions
- Early termination when limits are exceeded
- Secure format detection of METS-GBS tar archives with _detect_mets_gbs() method: maximum file size (10 MB per file), maximum member count (1000 members), and exception handling to gracefully fail when limits are exceeded
Workarounds
Avoid processing METS-GBS archives from untrusted sources. If necessary, pre-validate archives in an isolated environment with resource limits.
References
- Fix release: v2.91.0
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "docling"
},
"ranges": [
{
"events": [
{
"introduced": "2.45.0"
},
{
"fixed": "2.91.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44018"
],
"database_specific": {
"cwe_ids": [
"CWE-409",
"CWE-611",
"CWE-776"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-03T21:13:32Z",
"nvd_published_at": "2026-06-26T16:16:30Z",
"severity": "MODERATE"
},
"details": "### Impact\nThe METS-GBS backend\u0027s XML parsing and the input document format detection lacked security controls, enabling:\n- XML External Entity (XXE) attacks to read local files or cause denial of service\n- Decompression bombs (zip bombs) to exhaust memory and disk space\n- Unbounded archive extraction consuming system resources\n\nAn attacker could craft malicious METS-GBS archives that, when processed, could read sensitive files, exhaust system resources, or cause application crashes.\n\n### Patches\nFixed in version 2.91.0. The fix implements:\n- Secure XML parsing with `resolve_entities=False`, `load_dtd=False`, and `no_network=True`\n- Configurable limits: 300 MB total extraction size, 10 MB per file, 1000 member count\n- Cumulative size tracking across all extractions\n- Early termination when limits are exceeded\n- Secure format detection of METS-GBS tar archives with `_detect_mets_gbs()` method: maximum file size (10 MB per file), maximum member count (1000 members), and exception handling to gracefully fail when limits are exceeded\n\n### Workarounds\nAvoid processing METS-GBS archives from untrusted sources. If necessary, pre-validate archives in an isolated environment with resource limits.\n\n### References\n- Fix release: [v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0)",
"id": "GHSA-r3xg-rg9j-67fv",
"modified": "2026-07-21T15:04:20Z",
"published": "2026-06-03T21:13:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/docling-project/docling/security/advisories/GHSA-r3xg-rg9j-67fv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44018"
},
{
"type": "PACKAGE",
"url": "https://github.com/docling-project/docling"
},
{
"type": "WEB",
"url": "https://github.com/docling-project/docling/releases/tag/v2.91.0"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/docling/PYSEC-2026-2144.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Docling: Unsafe Archive Extraction and XML Parsing in METS-GBS Backend"
}
GHSA-R44J-6VWC-M7HX
Vulnerability from github – Published: 2026-03-21 03:31 – Updated: 2026-03-21 03:31OpenClaw versions prior to 2026.3.2 contain an archive extraction vulnerability in the tar.bz2 installer path that bypasses safety checks enforced on other archive formats. Attackers can craft malicious tar.bz2 skill archives to bypass special-entry blocking and extracted-size guardrails, causing local denial of service during skill installation.
{
"affected": [],
"aliases": [
"CVE-2026-32044"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-21T01:17:06Z",
"severity": "MODERATE"
},
"details": "OpenClaw versions prior to 2026.3.2 contain an archive extraction vulnerability in the tar.bz2 installer path that bypasses safety checks enforced on other archive formats. Attackers can craft malicious tar.bz2 skill archives to bypass special-entry blocking and extracted-size guardrails, causing local denial of service during skill installation.",
"id": "GHSA-r44j-6vwc-m7hx",
"modified": "2026-03-21T03:31:13Z",
"published": "2026-03-21T03:31:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-77hf-7fqf-f227"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32044"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/0dbb92dd2bcf9a32379d11c0f11ed016669dae3e"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-tar-archive-safety-bypass-in-skills-installation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/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"
}
]
}
GHSA-R7FM-3PQM-WW5W
Vulnerability from github – Published: 2025-07-10 17:50 – Updated: 2025-07-10 23:21Impact
When decoding a scenario (i.e. a zip archive), the size of the decoded content is not checked, potentially leading to zip bombs decompression. Exploitation does not require authentication nor authorization, so anyone can exploit it. It should nonetheless not be exploitable as it is highly recommended to bury Chall-Manager deep within the infrastructure due to its large capabilities, so no users could reach the system.
Patches
Patch has been implemented by commit 14042aa and shipped in v0.1.4.
Workarounds
No workaround exist.
References
N/A.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/ctfer-io/chall-manager"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-53633"
],
"database_specific": {
"cwe_ids": [
"CWE-405",
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-10T17:50:25Z",
"nvd_published_at": "2025-07-10T20:15:27Z",
"severity": "HIGH"
},
"details": "### Impact\n\nWhen decoding a scenario (i.e. a zip archive), the size of the decoded content is not checked, potentially leading to zip bombs decompression.\nExploitation does not require authentication nor authorization, so anyone can exploit it. It should nonetheless not be exploitable as it is highly recommended to bury Chall-Manager deep within the infrastructure due to its large capabilities, so no users could reach the system.\n\n### Patches\n\nPatch has been implemented by [commit `14042aa`](https://github.com/ctfer-io/chall-manager/commit/14042aa66a577caee777e10fe09adcf2587d20dd) and shipped in [`v0.1.4`](https://github.com/ctfer-io/chall-manager/releases/tag/v0.1.4).\n\n### Workarounds\n\nNo workaround exist.\n\n### References\n\nN/A.",
"id": "GHSA-r7fm-3pqm-ww5w",
"modified": "2025-07-10T23:21:54Z",
"published": "2025-07-10T17:50:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ctfer-io/chall-manager/security/advisories/GHSA-r7fm-3pqm-ww5w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53633"
},
{
"type": "WEB",
"url": "https://github.com/ctfer-io/chall-manager/commit/14042aa66a577caee777e10fe09adcf2587d20dd"
},
{
"type": "PACKAGE",
"url": "https://github.com/ctfer-io/chall-manager"
},
{
"type": "WEB",
"url": "https://github.com/ctfer-io/chall-manager/releases/tag/v0.1.4"
}
],
"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",
"type": "CVSS_V4"
}
],
"summary": "Chall-Manager\u0027s scenario decoding process does not check for zip bombs"
}
GHSA-RMQV-7V3J-MR7P
Vulnerability from github – Published: 2024-04-16 00:30 – Updated: 2024-04-16 14:04Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-7j7m-v7m3-jqm7. This link is maintained to preserve external references.
Original Description
The scrapy/scrapy project is vulnerable to XML External Entity (XXE) attacks due to the use of lxml.etree.fromstring for parsing untrusted XML data without proper validation. This vulnerability allows attackers to perform denial of service attacks, access local files, generate network connections, or circumvent firewalls by submitting specially crafted XML data.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "scrapy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-16T12:42:26Z",
"nvd_published_at": "2024-04-16T00:15:12Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-7j7m-v7m3-jqm7. This link is maintained to preserve external references.\n\n## Original Description\nThe scrapy/scrapy project is vulnerable to XML External Entity (XXE) attacks due to the use of lxml.etree.fromstring for parsing untrusted XML data without proper validation. This vulnerability allows attackers to perform denial of service attacks, access local files, generate network connections, or circumvent firewalls by submitting specially crafted XML data. ",
"id": "GHSA-rmqv-7v3j-mr7p",
"modified": "2024-04-16T14:04:36Z",
"published": "2024-04-16T00:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3572"
},
{
"type": "WEB",
"url": "https://github.com/scrapy/scrapy/commit/809bfac4890f75fc73607318a04d2ccba71b3d9f"
},
{
"type": "PACKAGE",
"url": "https://github.com/scrapy/scrapy"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/c4a0fac9-0c5a-4718-9ee4-2d06d58adabb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Duplicate Advisory: Scrapy decompression bomb vulnerability",
"withdrawn": "2024-04-16T14:04:36Z"
}
GHSA-RR89-W3H9-M66J
Vulnerability from github – Published: 2026-05-29 17:52 – Updated: 2026-07-17 16:52Impact
Versions of ExifReader from 4.20.0 through 4.38.1 do not bound the size of decompressed metadata blocks. When a caller invokes the asynchronous API (e.g. ExifReader.load(file) or ExifReader.load(buffer, {async: true})) on an attacker-supplied image, a small compressed chunk in the file can expand to hundreds of megabytes of memory, consuming heap and CPU until the process slows down or runs out of memory.
The affected paths share a single decompression utility, so the issue is reachable through any compressed metadata block the library handles asynchronously, including:
- PNG
zTXt, compressediTXt, andiCCPchunks (deflate) - JPEG XL Brotli-compressed Exif and XMP blocks
A typical proof of concept produced roughly 1000× expansion (for example, ~32 KB of compressed input expanded to ~32 MB of output, ~130 KB to ~128 MB).
Both the npm package and the dist/ bundle published from this repository (consumed by Bower and other users of the prebuilt artifact) are affected.
Patches
Fixed in 4.39.0. The decompression utility now reads the decompressed stream incrementally and aborts as soon as the running total would exceed a configurable limit. The default cap is 128 MiB per metadata block, which is well above any realistic legitimate value. When a block exceeds the cap, that block is skipped (a warning is emitted via console.warn) and the remaining tags are returned as usual.
The cap is configurable via the new maxDecompressedSize field on the decompress option, in bytes:
const tags = await ExifReader.load(file, {
async: true,
decompress: {
maxDecompressedSize: 16 * 1024 * 1024 // 16 MiB
}
});
The same cap applies to results returned by user-supplied custom brotli/deflate functions.
Workarounds
- If upgrading is not possible, avoid invoking the asynchronous API on untrusted inputs. The synchronous code path skips compressed metadata blocks entirely and is not affected. Alternatively, pre-validate input files by source or size before passing them to ExifReader.
Resources
- Patch: https://github.com/mattiasw/ExifReader/commit/5f116128adc19f674902f8bf582bfe7dd0a36375
- README — "Limiting decompressed metadata size": https://github.com/mattiasw/ExifReader/blob/main/README.md#limiting-decompressed-metadata-size
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "exifreader"
},
"ranges": [
{
"events": [
{
"introduced": "4.20.0"
},
{
"fixed": "4.39.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-8814"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T17:52:26Z",
"nvd_published_at": "2026-05-19T07:16:30Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nVersions of ExifReader from 4.20.0 through 4.38.1 do not bound the size of decompressed metadata blocks. When a caller invokes the asynchronous API (e.g. `ExifReader.load(file)` or `ExifReader.load(buffer, {async: true})`) on an attacker-supplied image, a small compressed chunk in the file can expand to hundreds of megabytes of memory, consuming heap and CPU until the process slows down or runs out of memory.\n\nThe affected paths share a single decompression utility, so the issue is reachable through any compressed metadata block the library handles asynchronously, including:\n\n- PNG `zTXt`, compressed `iTXt`, and `iCCP` chunks (deflate)\n- JPEG XL Brotli-compressed Exif and XMP blocks\n\nA typical proof of concept produced roughly 1000\u00d7 expansion (for example, ~32 KB of compressed input expanded to ~32 MB of output, ~130 KB to ~128 MB).\n\nBoth the npm package and the `dist/` bundle published from this repository (consumed by Bower and other users of the prebuilt artifact) are affected.\n\n### Patches\n\nFixed in **4.39.0**. The decompression utility now reads the decompressed stream incrementally and aborts as soon as the running total would exceed a configurable limit. The default cap is **128 MiB** per metadata block, which is well above any realistic legitimate value. When a block exceeds the cap, that block is skipped (a warning is emitted via `console.warn`) and the remaining tags are returned as usual.\n\nThe cap is configurable via the new `maxDecompressedSize` field on the `decompress` option, in bytes:\n\n```javascript\nconst tags = await ExifReader.load(file, {\n async: true,\n decompress: {\n maxDecompressedSize: 16 * 1024 * 1024 // 16 MiB\n }\n});\n```\n\nThe same cap applies to results returned by user-supplied custom `brotli`/`deflate` functions.\n\n### Workarounds\n\n- If upgrading is not possible, avoid invoking the asynchronous API on untrusted inputs. The synchronous code path skips compressed metadata blocks entirely and is not affected. Alternatively, pre-validate input files by source or size before passing them to ExifReader.\n\n### Resources\n\n- Patch: https://github.com/mattiasw/ExifReader/commit/5f116128adc19f674902f8bf582bfe7dd0a36375\n- README \u2014 \"Limiting decompressed metadata size\": https://github.com/mattiasw/ExifReader/blob/main/README.md#limiting-decompressed-metadata-size",
"id": "GHSA-rr89-w3h9-m66j",
"modified": "2026-07-17T16:52:29Z",
"published": "2026-05-29T17:52:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-rr89-w3h9-m66j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8814"
},
{
"type": "WEB",
"url": "https://github.com/mattiasw/ExifReader/commit/5f116128adc19f674902f8bf582bfe7dd0a36375"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattiasw/ExifReader"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JS-EXIFREADER-16689340"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "ExifReader is vulnerable to denial of service via unbounded decompression of image metadata"
}
GHSA-V464-R2R9-WWW7
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-21 17:25An Out-Of-Memory (OOM) vulnerability exists in the ollama server version 0.3.14. This vulnerability can be triggered when a malicious API server responds with a gzip bomb HTTP response, leading to the ollama server crashing. The vulnerability is present in the makeRequestWithRetry and getAuthorizationToken functions, which use io.ReadAll to read the response body. This can result in excessive memory usage and a Denial of Service (DoS) condition.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/ollama/ollama"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.3.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-12886"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-21T17:25:07Z",
"nvd_published_at": "2025-03-20T10:15:31Z",
"severity": "HIGH"
},
"details": "An Out-Of-Memory (OOM) vulnerability exists in the `ollama` server version 0.3.14. This vulnerability can be triggered when a malicious API server responds with a gzip bomb HTTP response, leading to the `ollama` server crashing. The vulnerability is present in the `makeRequestWithRetry` and `getAuthorizationToken` functions, which use `io.ReadAll` to read the response body. This can result in excessive memory usage and a Denial of Service (DoS) condition.",
"id": "GHSA-v464-r2r9-www7",
"modified": "2025-03-21T17:25:07Z",
"published": "2025-03-20T12:32:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12886"
},
{
"type": "PACKAGE",
"url": "https://github.com/ollama/ollama"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/f115fe52-58af-4844-ad29-b1c25f7245df"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Ollama Vulnerable to Denial of Service (DoS) via Crafted GZIP"
}
GHSA-V626-428R-43P8
Vulnerability from github – Published: 2026-07-15 12:32 – Updated: 2026-07-15 12:32Grav 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.
{
"affected": [],
"aliases": [
"CVE-2026-61449"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-15T12:18:19Z",
"severity": "HIGH"
},
"details": "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\u0027s ZIP central-directory header (ZipArchive::statIndex()[\u0027size\u0027]) 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.",
"id": "GHSA-v626-428r-43p8",
"modified": "2026-07-15T12:32:04Z",
"published": "2026-07-15T12:32:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getgrav/grav/security/advisories/GHSA-8h9x-89f2-m7x3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61449"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/grav-before-decompression-bomb-via-forged-zip-size"
}
],
"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"
},
{
"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/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"
}
]
}
GHSA-V647-H8JJ-FW5R
Vulnerability from github – Published: 2024-12-16 09:31 – Updated: 2024-12-16 19:27Mattermost versions 10.1.x <= 10.1.2, 10.0.x <= 10.0.2, 9.11.x <= 9.11.4, 9.5.x <= 9.5.12 fail to limit the file size for slack import file uploads which allows a user to cause a DoS via zip bomb by importing data in a team they are a team admin.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0"
},
{
"fixed": "10.1.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "9.11.0"
},
{
"fixed": "9.11.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "9.5.0"
},
{
"fixed": "9.5.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-54682"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-16T19:27:16Z",
"nvd_published_at": "2024-12-16T08:15:05Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 10.1.x \u003c= 10.1.2, 10.0.x \u003c= 10.0.2, 9.11.x \u003c= 9.11.4, 9.5.x \u003c= 9.5.12 fail to limit the file size for slack import file uploads which allows a user to\u00a0cause a DoS via zip bomb by importing data in a team they are a team admin.",
"id": "GHSA-v647-h8jj-fw5r",
"modified": "2024-12-16T19:27:16Z",
"published": "2024-12-16T09:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54682"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Mattermost Data Amplification vulnerability"
}
GHSA-V72X-2H86-7F8M
Vulnerability from github – Published: 2026-06-25 18:53 – Updated: 2026-06-25 18:53Summary
When MessagePack-CSharp decompresses Lz4Block or Lz4BlockArray payloads, it reads declared uncompressed lengths from the wire and allocates output buffers based on those lengths before validating that the compressed data is valid or that the declared expansion is reasonable.
A small payload can claim a very large uncompressed length and force a large allocation before LZ4 decoding begins.
Impact
Applications are affected when they deserialize attacker-controlled MessagePack payloads with MessagePackCompression.Lz4Block or MessagePackCompression.Lz4BlockArray enabled.
In the Lz4Block case, an attacker-controlled integer is used to request the destination span. In the Lz4BlockArray case, per-block uncompressed lengths and their aggregate can be attacker-controlled. Without a cap, the declared output size can be disproportionate to the input size, producing out-of-memory exceptions, process termination on constrained hosts, or severe memory pressure.
This advisory is about unbounded allocation from declared decompressed sizes. It is separate from the LZ4 source-buffer over-read issue, which concerns unsafe decoder reads beyond the compressed input buffer.
Affected components
- Package:
MessagePack - Feature: LZ4 compressed MessagePack payloads
- APIs:
MessagePackSerializerwithWithCompression(MessagePackCompression.Lz4Block)orWithCompression(MessagePackCompression.Lz4BlockArray) - Internal routine:
MessagePackSerializer.TryDecompress - Finding ID:
MESSAGEPACKCSHARP-OPEN-004
Patches
Fixes are prepared and will be released in coordinated patch versions.
Upgrade guidance:
- Upgrade
MessagePackto the patched version for your release line. - Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.
The fix should reject negative and excessive uncompressed lengths before allocation. It should also cap aggregate decompressed size for block arrays and expose or honor an appropriate maximum decompressed length policy.
Workarounds
Patching is recommended.
Until a patched version is available, do not enable MessagePack-CSharp's built-in LZ4 compression modes for untrusted inputs. If compression is required, enforce strict compressed and decompressed size limits outside MessagePack-CSharp before deserialization.
Resources
MESSAGEPACKCSHARP-OPEN-004: LZ4 decompression allocation from unbounded uncompressed lengthMESSAGEPACKCSHARP-011: duplicate decompression-bomb finding- CWE-409: Improper Handling of Highly Compressed Data
- CWE-770: Allocation of Resources Without Limits or Throttling
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "MessagePack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.5.301"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "MessagePack"
},
"ranges": [
{
"events": [
{
"introduced": "3.0"
},
{
"fixed": "3.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48510"
],
"database_specific": {
"cwe_ids": [
"CWE-409",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T18:53:44Z",
"nvd_published_at": "2026-06-22T22:16:47Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nWhen MessagePack-CSharp decompresses `Lz4Block` or `Lz4BlockArray` payloads, it reads declared uncompressed lengths from the wire and allocates output buffers based on those lengths before validating that the compressed data is valid or that the declared expansion is reasonable.\n\nA small payload can claim a very large uncompressed length and force a large allocation before LZ4 decoding begins.\n\n## Impact\n\nApplications are affected when they deserialize attacker-controlled MessagePack payloads with `MessagePackCompression.Lz4Block` or `MessagePackCompression.Lz4BlockArray` enabled.\n\nIn the `Lz4Block` case, an attacker-controlled integer is used to request the destination span. In the `Lz4BlockArray` case, per-block uncompressed lengths and their aggregate can be attacker-controlled. Without a cap, the declared output size can be disproportionate to the input size, producing out-of-memory exceptions, process termination on constrained hosts, or severe memory pressure.\n\nThis advisory is about unbounded allocation from declared decompressed sizes. It is separate from the LZ4 source-buffer over-read issue, which concerns unsafe decoder reads beyond the compressed input buffer.\n\n## Affected components\n\n- Package: `MessagePack`\n- Feature: LZ4 compressed MessagePack payloads\n- APIs: `MessagePackSerializer` with `WithCompression(MessagePackCompression.Lz4Block)` or `WithCompression(MessagePackCompression.Lz4BlockArray)`\n- Internal routine: `MessagePackSerializer.TryDecompress`\n- Finding ID: `MESSAGEPACKCSHARP-OPEN-004`\n\n## Patches\n\nFixes are prepared and will be released in coordinated patch versions.\n\nUpgrade guidance:\n\n1. Upgrade `MessagePack` to the patched version for your release line.\n2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.\n\nThe fix should reject negative and excessive uncompressed lengths before allocation. It should also cap aggregate decompressed size for block arrays and expose or honor an appropriate maximum decompressed length policy.\n\n## Workarounds\n\nPatching is recommended.\n\nUntil a patched version is available, do not enable MessagePack-CSharp\u0027s built-in LZ4 compression modes for untrusted inputs. If compression is required, enforce strict compressed and decompressed size limits outside MessagePack-CSharp before deserialization.\n\n## Resources\n\n- `MESSAGEPACKCSHARP-OPEN-004`: LZ4 decompression allocation from unbounded uncompressed length\n- `MESSAGEPACKCSHARP-011`: duplicate decompression-bomb finding\n- CWE-409: Improper Handling of Highly Compressed Data\n- CWE-770: Allocation of Resources Without Limits or Throttling",
"id": "GHSA-v72x-2h86-7f8m",
"modified": "2026-06-25T18:53:44Z",
"published": "2026-06-25T18:53:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-v72x-2h86-7f8m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48510"
},
{
"type": "PACKAGE",
"url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
}
],
"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:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MessagePack-CSharp: LZ4 decompression allocates from unbounded declared output lengths"
}
GHSA-VHGH-G7X8-4RX8
Vulnerability from github – Published: 2026-03-26 18:31 – Updated: 2026-03-31 23:05Mattermost versions 11.4.x <= 11.4.0, 11.3.x <= 11.3.1, 11.2.x <= 11.2.3, 10.11.x <= 10.11.11 fail to validate decompressed archive entry sizes during file extraction which allows authenticated users with file upload permissions to cause a denial of service via crafted zip archives containing highly compressed entries (zip bombs) that exhaust server memory. Mattermost Advisory ID: MMSA-2026-00598.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "11.4.0"
},
{
"fixed": "11.4.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"11.4.0"
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "11.3.0"
},
{
"fixed": "11.3.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "11.2.0"
},
{
"fixed": "11.2.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0"
},
{
"fixed": "10.11.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0-20260105080200-d27a2195068d"
},
{
"fixed": "8.0.0-20260217110922-b7d4a1f1f59b"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-3114"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-31T23:05:48Z",
"nvd_published_at": "2026-03-26T17:16:42Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 11.4.x \u003c= 11.4.0, 11.3.x \u003c= 11.3.1, 11.2.x \u003c= 11.2.3, 10.11.x \u003c= 10.11.11 fail to validate decompressed archive entry sizes during file extraction which allows authenticated users with file upload permissions to cause a denial of service via crafted zip archives containing highly compressed entries (zip bombs) that exhaust server memory. Mattermost Advisory ID: MMSA-2026-00598.",
"id": "GHSA-vhgh-g7x8-4rx8",
"modified": "2026-03-31T23:05:48Z",
"published": "2026-03-26T18:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3114"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Mattermost doesn\u0027t validate decompressed archive entry sizes during file extraction"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.