Common Weakness Enumeration
CWE-409
Weakness 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.
Mapping guidance
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
Modes of introduction
Architecture and Design
Implementation
Content history
Submission: PLOVER
· 2006-07-19
· CWE Draft 3
Modification: Eric Dalci
· Cigital
· 2008-07-01
· CWE 1.0
updated Time_of_Introduction
Modification: CWE Content Team
· MITRE
· 2008-09-08
· CWE 1.0
updated Relationships, Taxonomy_Mappings
Modification: CWE Content Team
· MITRE
· 2008-10-14
· CWE 1.0.1
updated Description
Modification: CWE Content Team
· MITRE
· 2009-05-27
· CWE 1.4
updated Description, Name
Modification: CWE Content Team
· MITRE
· 2009-07-27
· CWE 1.5
updated Relationships
Modification: CWE Content Team
· MITRE
· 2011-06-01
· CWE 1.13
updated Common_Consequences, Relationships, Taxonomy_Mappings
Modification: CWE Content Team
· MITRE
· 2012-05-11
· CWE 2.2
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships, Taxonomy_Mappings
Modification: CWE Content Team
· MITRE
· 2014-07-30
· CWE 2.8
updated Relationships
Modification: CWE Content Team
· MITRE
· 2017-11-08
· CWE 3.0
updated Applicable_Platforms
Modification: CWE Content Team
· MITRE
· 2019-01-03
· CWE 3.2
updated Relationships, Taxonomy_Mappings
Modification: CWE Content Team
· MITRE
· 2020-02-24
· CWE 4.0
updated Relationships
Modification: CWE Content Team
· MITRE
· 2023-01-31
· CWE 4.10
updated Description
Modification: CWE Content Team
· MITRE
· 2023-04-27
· CWE 4.11
updated Relationships
Modification: CWE Content Team
· MITRE
· 2023-06-29
· CWE 4.12
updated Mapping_Notes
Modification: CWE Content Team
· MITRE
· 2025-12-11
· CWE 4.19
updated Applicable_Platforms, Weakness_Ordinalities
Modification: CWE Content Team
· MITRE
· 2026-10-28
· CWE 5.0
updated Applicable_Platforms, Demonstrative_Examples, Description, References, Relationships, Taxonomy_Mappings
356 vulnerabilities reference this CWE, most recent first.
CVE-2026-128242 (GCVE-0-2026-128242)
Vulnerability from cvelistv5 – Published: 2026-11-13 09:33 – Updated: 2026-11-13 22:31
VLAI
EPSS
VEX
Title
actix-http before 3.20.1 and actix-web before 4.18.2 Decompression Bomb DoS via encoding::Decoder
Summary
actix-http before 3.20.1 and actix-web before 4.18.2 contain an unbounded decompression vulnerability in encoding::Decoder that lets remote attackers exhaust memory and CPU via compressed bodies. Attackers can send small highly compressed gzip, deflate, Brotli or zstd request bodies to Json, Form, Bytes or String extractors, or serve them to awc clients, causing denial of service.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-13 16:34 UTC
CWE
- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
Assigner
References
9 references
| URL | Tags |
|---|---|
| https://github.com/actix/actix-web/security/advis… | vendor-advisory |
| https://rustsec.org/advisories/RUSTSEC-2026-0448.html | third-party-advisory |
| https://github.com/actix/actix-web/commit/41b54d2… | patch |
| https://github.com/actix/actix-web/commit/0d0be61… | patch |
| https://github.com/actix/actix-web/blob/actix-htt… | technical-description |
| https://github.com/actix/actix-web/releases/tag/a… | release-notes |
| https://github.com/actix/actix-web/releases/tag/a… | release-notes |
| https://github.com/actix/actix-web | product |
| https://www.vulncheck.com/advisories/actix-http-b… | third-party-advisory |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| actix | actix-http |
Affected:
0 , < 3.20.1
(semver)
|
|
| actix | actix-web |
Affected:
0 , < 4.18.2
(semver)
|
Date Public
2026-11-06 12:17
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-128242",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-13T16:34:20.372519Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-13T22:31:21.483Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageURL": "pkg:cargo/actix-http",
"product": "actix-http",
"vendor": "actix",
"versions": [
{
"lessThan": "3.20.1",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
},
{
"defaultStatus": "unaffected",
"packageURL": "pkg:cargo/actix-web",
"product": "actix-web",
"vendor": "actix",
"versions": [
{
"lessThan": "4.18.2",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:actix:actix-http:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.20.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:actix:actix-web:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.18.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Stapat"
},
{
"lang": "en",
"type": "finder",
"value": "diandiandia"
},
{
"lang": "en",
"type": "finder",
"value": "lboynton"
},
{
"lang": "en",
"type": "finder",
"value": "calbebop"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Rob Ede"
}
],
"datePublic": "2026-11-06T12:17:07.000Z",
"descriptions": [
{
"lang": "en",
"value": "actix-http before 3.20.1 and actix-web before 4.18.2 contain an unbounded decompression vulnerability in encoding::Decoder that lets remote attackers exhaust memory and CPU via compressed bodies. Attackers can send small highly compressed gzip, deflate, Brotli or zstd request bodies to Json, Form, Bytes or String extractors, or serve them to awc clients, causing denial of service."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
},
"format": "CVSS"
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-13T09:33:45.553Z",
"orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"shortName": "VulnCheck"
},
"references": [
{
"name": "GitHub Security Advisory (GHSA-qph8-7859-gq2f)",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/actix/actix-web/security/advisories/GHSA-qph8-7859-gq2f"
},
{
"tags": [
"third-party-advisory"
],
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0448.html"
},
{
"tags": [
"patch"
],
"url": "https://github.com/actix/actix-web/commit/41b54d23ea04f66758c15de7e4ab18325cd25280"
},
{
"tags": [
"patch"
],
"url": "https://github.com/actix/actix-web/commit/0d0be61bd757027bfcecbc53df1b7a600f21ecd0"
},
{
"tags": [
"technical-description"
],
"url": "https://github.com/actix/actix-web/blob/actix-http-v3.20.0/actix-http/src/encoding/decoder.rs#L239-L301"
},
{
"name": "actix-web actix-http-v3.20.1 Release Notes",
"tags": [
"release-notes"
],
"url": "https://github.com/actix/actix-web/releases/tag/actix-http-v3.20.1"
},
{
"name": "actix-web actix-web-v4.18.2 Release Notes",
"tags": [
"release-notes"
],
"url": "https://github.com/actix/actix-web/releases/tag/actix-web-v4.18.2"
},
{
"tags": [
"product"
],
"url": "https://github.com/actix/actix-web"
},
{
"name": "VulnCheck Advisory: actix-http before 3.20.1 and actix-web before 4.18.2 Decompression Bomb DoS via encoding::Decoder",
"tags": [
"third-party-advisory"
],
"url": "https://www.vulncheck.com/advisories/actix-http-before-3.20.1-and-actix-web-before-4.18.2-decompression-bomb-dos-via-encoding-decoder"
}
],
"title": "actix-http before 3.20.1 and actix-web before 4.18.2 Decompression Bomb DoS via encoding::Decoder",
"x_generator": {
"engine": "vulncheck-endgame"
}
}
},
"cveMetadata": {
"assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"assignerShortName": "VulnCheck",
"cveId": "CVE-2026-128242",
"datePublished": "2026-11-13T09:33:45.553Z",
"dateReserved": "2026-11-12T23:11:45.421Z",
"dateUpdated": "2026-11-13T22:31:21.483Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-126423 (GCVE-0-2026-126423)
Vulnerability from cvelistv5 – Published: 2026-11-13 09:35 – Updated: 2026-11-13 15:55
VLAI
EPSS
VEX
Title
OpenEMR before 8.5.0 Denial of Service via ZIP Upload Decompression
Summary
OpenEMR before 8.5.0 contains a denial of service vulnerability in four ZIP upload paths that read uncompressed entries into memory without size or ratio checks. Authenticated billing or Carecoordination users can upload highly compressed ZIP archives to exhaust PHP memory and worker pools, making OpenEMR unavailable.
Severity
4.3 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-13 15:30 UTC
CWE
- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/openemr/openemr/security/advis… | vendor-advisory |
| https://www.vulncheck.com/advisories/openemr-befo… | third-party-advisory |
Impacted products
Date Public
2026-10-28 00:00
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-126423",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-13T15:30:13.820205Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-13T15:55:59.971Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "openemr",
"vendor": "openemr",
"versions": [
{
"lessThan": "8.5.0",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "8.5.0",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:open-emr:openemr:*:*:*:*:*:*:*:*",
"versionEndExcluding": "8.5.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "farisv"
}
],
"datePublic": "2026-10-28T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "OpenEMR before 8.5.0 contains a denial of service vulnerability in four ZIP upload paths that read uncompressed entries into memory without size or ratio checks. Authenticated billing or Carecoordination users can upload highly compressed ZIP archives to exhaust PHP memory and worker pools, making OpenEMR unavailable."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "LOW",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
},
"format": "CVSS"
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 4.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-13T09:35:31.761Z",
"orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"shortName": "VulnCheck"
},
"references": [
{
"name": "GitHub Security Advisory (GHSA-pqmf-m4h6-wjh4)",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/openemr/openemr/security/advisories/GHSA-pqmf-m4h6-wjh4"
},
{
"name": "VulnCheck Advisory: OpenEMR before 8.5.0 Denial of Service via ZIP Upload Decompression",
"tags": [
"third-party-advisory"
],
"url": "https://www.vulncheck.com/advisories/openemr-before-8.5.0-denial-of-service-via-zip-upload-decompression"
}
],
"title": "OpenEMR before 8.5.0 Denial of Service via ZIP Upload Decompression",
"x_generator": {
"engine": "vulncheck-endgame"
}
}
},
"cveMetadata": {
"assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"assignerShortName": "VulnCheck",
"cveId": "CVE-2026-126423",
"datePublished": "2026-11-13T09:35:31.761Z",
"dateReserved": "2026-11-10T21:36:07.090Z",
"dateUpdated": "2026-11-13T15:55:59.971Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-122323 (GCVE-0-2026-122323)
Vulnerability from cvelistv5 – Published: 2026-11-05 02:25 – Updated: 2026-11-09 16:52
VLAI
EPSS
VEX
Title
Kyverno 1.11.0 before 1.19.2 Memory Exhaustion via Notary Signature Decompression
Summary
Kyverno from 1.11.0 before 1.19.2 contains an unbounded decompression vulnerability in FetchSignatureBlob that allows attackers to exhaust memory by supplying highly compressed notary signature layers. Attackers who control registry referrers or signatures can publish small gzip layers that decompress beyond maxPayloadSize, causing admission controller OOM kills and denial of service.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-09 16:34 UTC
CWE
- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/kyverno/kyverno/security/advis… | vendor-advisory |
| https://www.vulncheck.com/advisories/kyverno-1.11… | third-party-advisory |
Impacted products
Date Public
2026-10-21 00:00
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-122323",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-09T16:34:09.565125Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-09T16:52:18.927Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageURL": "pkg:golang/kyverno",
"product": "kyverno",
"vendor": "kyverno",
"versions": [
{
"lessThan": "1.19.2",
"status": "affected",
"version": "1.11.0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "1.19.2",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:kyverno:kyverno:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.19.2",
"versionStartIncluding": "1.11.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "1seal"
}
],
"datePublic": "2026-10-21T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "Kyverno from 1.11.0 before 1.19.2 contains an unbounded decompression vulnerability in FetchSignatureBlob that allows attackers to exhaust memory by supplying highly compressed notary signature layers. Attackers who control registry referrers or signatures can publish small gzip layers that decompress beyond maxPayloadSize, causing admission controller OOM kills and denial of service."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
},
"format": "CVSS"
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-05T02:25:21.376Z",
"orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"shortName": "VulnCheck"
},
"references": [
{
"name": "GitHub Security Advisory (GHSA-fr24-3hvf-393q)",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-fr24-3hvf-393q"
},
{
"name": "VulnCheck Advisory: Kyverno 1.11.0 before 1.19.2 Memory Exhaustion via Notary Signature Decompression",
"tags": [
"third-party-advisory"
],
"url": "https://www.vulncheck.com/advisories/kyverno-1.11.0-before-1.19.2-memory-exhaustion-via-notary-signature-decompression"
}
],
"title": "Kyverno 1.11.0 before 1.19.2 Memory Exhaustion via Notary Signature Decompression",
"x_generator": {
"engine": "vulncheck-endgame"
}
}
},
"cveMetadata": {
"assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"assignerShortName": "VulnCheck",
"cveId": "CVE-2026-122323",
"datePublished": "2026-11-05T02:25:21.376Z",
"dateReserved": "2026-11-04T23:26:08.934Z",
"dateUpdated": "2026-11-09T16:52:18.927Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-122322 (GCVE-0-2026-122322)
Vulnerability from cvelistv5 – Published: 2026-11-05 02:25 – Updated: 2026-11-09 16:52
VLAI
EPSS
VEX
Title
Kyverno from 1.11.0 before 1.19.2 Memory Exhaustion via Notary Attestation Decompression
Summary
Kyverno from 1.11.0 before 1.19.2 contains an unbounded decompression vulnerability in extractStatement that allows remote attackers to exhaust memory by supplying highly compressed attestation layers. Attackers controlling registry referrer artifacts can push gzip predicate layers exceeding maxPayloadSize when decompressed, causing admission controller OOM kills and denial of service.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-09 16:34 UTC
CWE
- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/kyverno/kyverno/security/advis… | vendor-advisory |
| https://www.vulncheck.com/advisories/kyverno-from… | third-party-advisory |
Impacted products
Date Public
2026-10-21 00:00
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-122322",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-09T16:34:06.534430Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-09T16:52:27.681Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "kyverno",
"vendor": "kyverno",
"versions": [
{
"lessThan": "1.19.2",
"status": "affected",
"version": "1.11.0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "1.19.2",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:kyverno:kyverno:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.19.2",
"versionStartIncluding": "1.11.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "1seal"
}
],
"datePublic": "2026-10-21T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "Kyverno from 1.11.0 before 1.19.2 contains an unbounded decompression vulnerability in extractStatement that allows remote attackers to exhaust memory by supplying highly compressed attestation layers. Attackers controlling registry referrer artifacts can push gzip predicate layers exceeding maxPayloadSize when decompressed, causing admission controller OOM kills and denial of service."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
},
"format": "CVSS"
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-05T02:25:20.692Z",
"orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"shortName": "VulnCheck"
},
"references": [
{
"name": "GitHub Security Advisory (GHSA-3f2c-hfj8-542w)",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-3f2c-hfj8-542w"
},
{
"name": "VulnCheck Advisory: Kyverno from 1.11.0 before 1.19.2 Memory Exhaustion via Notary Attestation Decompression",
"tags": [
"third-party-advisory"
],
"url": "https://www.vulncheck.com/advisories/kyverno-from-1.11.0-before-1.19.2-memory-exhaustion-via-notary-attestation-decompression"
}
],
"title": "Kyverno from 1.11.0 before 1.19.2 Memory Exhaustion via Notary Attestation Decompression",
"x_generator": {
"engine": "vulncheck-endgame"
}
}
},
"cveMetadata": {
"assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"assignerShortName": "VulnCheck",
"cveId": "CVE-2026-122322",
"datePublished": "2026-11-05T02:25:20.692Z",
"dateReserved": "2026-11-04T23:26:08.934Z",
"dateUpdated": "2026-11-09T16:52:27.681Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-121808 (GCVE-0-2026-121808)
Vulnerability from cvelistv5 – Published: 2026-11-13 15:48 – Updated: 2026-11-13 15:48
VLAI
EPSS
VEX
Title
Memory exhaustion via compressed Erlang terms in the elixir-grpc Erlpack codec
Summary
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc_core and grpc allows unauthenticated attackers to exhaust server memory via a compressed Erlang external term in a gRPC message body.
GRPC.Codec.Erlpack.decode/2 (grpc_core/lib/grpc/codec/erlpack.ex, and lib/grpc/codec/erlpack.ex before the package split) passes the message body to :erlang.binary_to_term/2. That function inflates a compressed term in full before it returns. The codec sets no limit on the decoded size, and its type checks run only on the decoded term. The server's max_body_size limit counts the compressed bytes of the request. A request with Content-Type: application/grpc+erlpack can therefore make the server allocate a term much larger than the request body.
This issue affects grpc: from 0.4.0 before 1.0.0; grpc_core: from 1.0.0 before 1.1.0.
Severity
CWE
- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
Assigner
References
6 references
Impacted products
4 products
| Vendor | Product | Version | |
|---|---|---|---|
| elixir-grpc | grpc |
Affected:
0.4.0 , < 1.0.0
(semver)
cpe:2.3:a:elixir-grpc:grpc:*:*:*:*:*:*:*:* |
|
| elixir-grpc | grpc |
Affected:
25bcc569fe2cc4478531a6c546c923205fc751c9 , < 0332faae5f5e132314794dbfdae5edecbccea292
(git)
cpe:2.3:a:elixir-grpc:grpc:*:*:*:*:*:*:*:* |
|
| elixir-grpc | grpc_core |
Affected:
1.0.0 , < 1.1.0
(semver)
cpe:2.3:a:elixir-grpc:grpc_core:*:*:*:*:*:*:*:* |
|
| elixir-grpc | grpc_core |
Affected:
0332faae5f5e132314794dbfdae5edecbccea292 , < d6bc56ac75dfb6c02db2099909210a37c9be8db6
(git)
cpe:2.3:a:elixir-grpc:grpc_core:*:*:*:*:*:*:*:* |
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:elixir-grpc:grpc:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.GRPC.Codec.Erlpack\u0027"
],
"packageName": "grpc",
"packageURL": "pkg:hex/grpc",
"product": "grpc",
"programFiles": [
"lib/grpc/codec/erlpack.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.GRPC.Codec.Erlpack\u0027:decode/2"
}
],
"repo": "https://github.com/elixir-grpc/grpc",
"vendor": "elixir-grpc",
"versions": [
{
"lessThan": "1.0.0",
"status": "affected",
"version": "0.4.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:elixir-grpc:grpc:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.GRPC.Codec.Erlpack\u0027"
],
"packageName": "elixir-grpc/grpc",
"packageURL": "pkg:github/elixir-grpc/grpc",
"product": "grpc",
"programFiles": [
"lib/grpc/codec/erlpack.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.GRPC.Codec.Erlpack\u0027:decode/2"
}
],
"repo": "https://github.com/elixir-grpc/grpc",
"vendor": "elixir-grpc",
"versions": [
{
"lessThan": "0332faae5f5e132314794dbfdae5edecbccea292",
"status": "affected",
"version": "25bcc569fe2cc4478531a6c546c923205fc751c9",
"versionType": "git"
}
]
},
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:elixir-grpc:grpc_core:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.GRPC.Codec.Erlpack\u0027"
],
"packageName": "grpc_core",
"packageURL": "pkg:hex/grpc_core",
"product": "grpc_core",
"programFiles": [
"lib/grpc/codec/erlpack.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.GRPC.Codec.Erlpack\u0027:decode/2"
}
],
"repo": "https://github.com/elixir-grpc/grpc",
"vendor": "elixir-grpc",
"versions": [
{
"lessThan": "1.1.0",
"status": "affected",
"version": "1.0.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:elixir-grpc:grpc_core:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.GRPC.Codec.Erlpack\u0027"
],
"packageName": "elixir-grpc/grpc",
"packageURL": "pkg:github/elixir-grpc/grpc",
"product": "grpc_core",
"programFiles": [
"grpc_core/lib/grpc/codec/erlpack.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.GRPC.Codec.Erlpack\u0027:decode/2"
}
],
"repo": "https://github.com/elixir-grpc/grpc",
"vendor": "elixir-grpc",
"versions": [
{
"lessThan": "d6bc56ac75dfb6c02db2099909210a37c9be8db6",
"status": "affected",
"version": "0332faae5f5e132314794dbfdae5edecbccea292",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003ccode\u003eGRPC.Codec.Erlpack\u003c/code\u003e must be explicitly registered as a codec on the gRPC server.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "`GRPC.Codec.Erlpack` must be explicitly registered as a codec on the gRPC server."
}
],
"value": "GRPC.Codec.Erlpack must be explicitly registered as a codec on the gRPC server."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:elixir-grpc:grpc:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.0.0",
"versionStartIncluding": "0.4.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:elixir-grpc:grpc_core:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.1.0",
"versionStartIncluding": "1.0.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Jace"
},
{
"lang": "en",
"type": "finder",
"value": "zx"
},
{
"lang": "en",
"type": "reporter",
"value": "zx"
},
{
"lang": "en",
"type": "finder",
"value": "Jiacheng Zhong"
},
{
"lang": "en",
"type": "finder",
"value": "Zhun Wang"
},
{
"lang": "en",
"type": "finder",
"value": "Junmin Zhu"
},
{
"lang": "en",
"type": "finder",
"value": "Hongwei Li"
},
{
"lang": "en",
"type": "finder",
"value": "Han Dai"
},
{
"lang": "en",
"type": "finder",
"value": "Suyue Guo"
},
{
"lang": "en",
"type": "finder",
"value": "Songyang Peng"
},
{
"lang": "en",
"type": "finder",
"value": "Ziyue Pan"
},
{
"lang": "en",
"type": "reporter",
"value": "Hongwei Li"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Paulo Valente"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "coordinator",
"value": "Peter Ullrich"
}
],
"dateAssigned": "2026-11-12T20:11:46.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc_core and grpc allows unauthenticated attackers to exhaust server memory via a compressed Erlang external term in a gRPC message body.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eGRPC.Codec.Erlpack.decode/2\u003c/code\u003e (\u003ccode\u003egrpc_core/lib/grpc/codec/erlpack.ex\u003c/code\u003e, and \u003ccode\u003elib/grpc/codec/erlpack.ex\u003c/code\u003e before the package split) passes the message body to \u003ccode\u003e:erlang.binary_to_term/2\u003c/code\u003e. That function inflates a compressed term in full before it returns. The codec sets no limit on the decoded size, and its type checks run only on the decoded term. The server\u0027s \u003ccode\u003emax_body_size\u003c/code\u003e limit counts the compressed bytes of the request. A request with \u003ccode\u003eContent-Type: application/grpc+erlpack\u003c/code\u003e can therefore make the server allocate a term much larger than the request body.\u003c/p\u003e\n\u003cp\u003eThis issue affects grpc: from 0.4.0 before 1.0.0; grpc_core: from 1.0.0 before 1.1.0.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc_core and grpc allows unauthenticated attackers to exhaust server memory via a compressed Erlang external term in a gRPC message body.\n\n`GRPC.Codec.Erlpack.decode/2` (`grpc_core/lib/grpc/codec/erlpack.ex`, and `lib/grpc/codec/erlpack.ex` before the package split) passes the message body to `:erlang.binary_to_term/2`. That function inflates a compressed term in full before it returns. The codec sets no limit on the decoded size, and its type checks run only on the decoded term. The server\u0027s `max_body_size` limit counts the compressed bytes of the request. A request with `Content-Type: application/grpc+erlpack` can therefore make the server allocate a term much larger than the request body.\n\nThis issue affects grpc: from 0.4.0 before 1.0.0; grpc_core: from 1.0.0 before 1.1.0."
}
],
"value": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc_core and grpc allows unauthenticated attackers to exhaust server memory via a compressed Erlang external term in a gRPC message body.\n\nGRPC.Codec.Erlpack.decode/2 (grpc_core/lib/grpc/codec/erlpack.ex, and lib/grpc/codec/erlpack.ex before the package split) passes the message body to :erlang.binary_to_term/2. That function inflates a compressed term in full before it returns. The codec sets no limit on the decoded size, and its type checks run only on the decoded term. The server\u0027s max_body_size limit counts the compressed bytes of the request. A request with Content-Type: application/grpc+erlpack can therefore make the server allocate a term much larger than the request body.\n\nThis issue affects grpc: from 0.4.0 before 1.0.0; grpc_core: from 1.0.0 before 1.1.0."
}
],
"impacts": [
{
"capecId": "CAPEC-130",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn unauthenticated client can make a server that registers the Erlpack codec allocate memory far beyond the size of the request with one request. Memory exhaustion affects every service on that node.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An unauthenticated client can make a server that registers the Erlpack codec allocate memory far beyond the size of the request with one request. Memory exhaustion affects every service on that node."
}
],
"value": "An unauthenticated client can make a server that registers the Erlpack codec allocate memory far beyond the size of the request with one request. Memory exhaustion affects every service on that node."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-13T15:48:49.871Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "Memory exhaustion via compressed Erlang terms in the elixir-grpc Erlpack codec",
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/elixir-grpc/grpc/security/advisories/GHSA-xxp9-7hp4-rqwp"
},
{
"name": "EEF CNA record for CVE-2026-121808",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-121808.html"
},
{
"name": "OSV record EEF-CVE-2026-121808",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-121808"
},
{
"name": "Introducing commit 25bcc56 in elixir-grpc/grpc",
"tags": [
"related"
],
"url": "https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9"
},
{
"name": "Fix commit 0332faa in elixir-grpc/grpc",
"tags": [
"patch"
],
"url": "https://github.com/elixir-grpc/grpc/commit/0332faae5f5e132314794dbfdae5edecbccea292"
},
{
"name": "Fix commit d6bc56a in elixir-grpc/grpc",
"tags": [
"patch"
],
"url": "https://github.com/elixir-grpc/grpc/commit/d6bc56ac75dfb6c02db2099909210a37c9be8db6"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Memory exhaustion via compressed Erlang terms in the elixir-grpc Erlpack codec",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRemove \u003ccode\u003eGRPC.Codec.Erlpack\u003c/code\u003e from the server\u0027s \u003ccode\u003ecodecs\u003c/code\u003e list if the codec is not needed.\u003c/p\u003e\n\u003cp\u003eIf the codec is needed, register a wrapper codec in its place. The wrapper implements the \u003ccode\u003eGRPC.Codec\u003c/code\u003e behaviour, returns \u003ccode\u003e\"erlpack\"\u003c/code\u003e from \u003ccode\u003ename/0\u003c/code\u003e, raises in \u003ccode\u003edecode/2\u003c/code\u003e when the body starts with the bytes \u003ccode\u003e131, 80\u003c/code\u003e (the compressed term tag), and delegates all other calls to \u003ccode\u003eGRPC.Codec.Erlpack\u003c/code\u003e.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Remove `GRPC.Codec.Erlpack` from the server\u0027s `codecs` list if the codec is not needed.\n\nIf the codec is needed, register a wrapper codec in its place. The wrapper implements the `GRPC.Codec` behaviour, returns `\"erlpack\"` from `name/0`, raises in `decode/2` when the body starts with the bytes `131, 80` (the compressed term tag), and delegates all other calls to `GRPC.Codec.Erlpack`."
}
],
"value": "Remove GRPC.Codec.Erlpack from the server\u0027s codecs list if the codec is not needed.\n\nIf the codec is needed, register a wrapper codec in its place. The wrapper implements the GRPC.Codec behaviour, returns \"erlpack\" from name/0, raises in decode/2 when the body starts with the bytes 131, 80 (the compressed term tag), and delegates all other calls to GRPC.Codec.Erlpack."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eStart a gRPC server that registers \u003ccode\u003eGRPC.Codec.Erlpack\u003c/code\u003e in its \u003ccode\u003ecodecs\u003c/code\u003e list.\u003c/li\u003e\n\u003cli\u003eBuild the payload with \u003ccode\u003e:erlang.term_to_binary(:binary.copy(\u0026lt;\u0026lt;0\u0026gt;\u0026gt;, 268_435_456), [:compressed])\u003c/code\u003e. The result is 260,932 bytes.\u003c/li\u003e\n\u003cli\u003eSend the payload as one uncompressed gRPC message (compressed flag 0) to any method of the server, with \u003ccode\u003eContent-Type: application/grpc+erlpack\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eObserve that the server allocates the 268,435,456-byte binary and passes it to the application callback.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Start a gRPC server that registers `GRPC.Codec.Erlpack` in its `codecs` list.\n2. Build the payload with `:erlang.term_to_binary(:binary.copy(\u003c\u003c0\u003e\u003e, 268_435_456), [:compressed])`. The result is 260,932 bytes.\n3. Send the payload as one uncompressed gRPC message (compressed flag 0) to any method of the server, with `Content-Type: application/grpc+erlpack`.\n4. Observe that the server allocates the 268,435,456-byte binary and passes it to the application callback."
}
],
"value": "* Start a gRPC server that registers GRPC.Codec.Erlpack in its codecs list.\n* Build the payload with :erlang.term_to_binary(:binary.copy(\u003c\u003c0\u003e\u003e, 268_435_456), [:compressed]). The result is 260,932 bytes.\n* Send the payload as one uncompressed gRPC message (compressed flag 0) to any method of the server, with Content-Type: application/grpc+erlpack.\n* Observe that the server allocates the 268,435,456-byte binary and passes it to the application callback."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Codec selection\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe server selects the codec from the request \u003ccode\u003eContent-Type\u003c/code\u003e. \u003ccode\u003eapplication/grpc+erlpack\u003c/code\u003e selects \u003ccode\u003eGRPC.Codec.Erlpack\u003c/code\u003e when the server registers it. No authentication step comes before this.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Size limit on compressed bytes only\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe server limits the request body with \u003ccode\u003emax_body_size\u003c/code\u003e, which counts the bytes received. With the gRPC compressed flag set to 0, the transport decompression limit does not apply, and the message reaches the codec unchanged.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Expansion inside \u003ccode\u003ebinary_to_term/2\u003c/code\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eGRPC.Codec.Erlpack.decode/2\u003c/code\u003e calls \u003ccode\u003e:erlang.binary_to_term(binary, [:safe])\u003c/code\u003e. The Erlang external term format has a compressed form (version byte 131, tag 80, a 32-bit uncompressed size, then a zlib stream). \u003ccode\u003ebinary_to_term/2\u003c/code\u003e inflates it in full, and the \u003ccode\u003e:safe\u003c/code\u003e option does not limit the size. \u003ccode\u003eensure_safe_term!/1\u003c/code\u003e runs after the call returns and accepts a large binary.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e4. Result\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIn a test against grpc_server 1.0.6, a 260,932-byte request body decoded to a 268,435,456-byte binary, which the server passed to the application callback.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Codec selection**\n\nThe server selects the codec from the request `Content-Type`. `application/grpc+erlpack` selects `GRPC.Codec.Erlpack` when the server registers it. No authentication step comes before this.\n\n**2. Size limit on compressed bytes only**\n\nThe server limits the request body with `max_body_size`, which counts the bytes received. With the gRPC compressed flag set to 0, the transport decompression limit does not apply, and the message reaches the codec unchanged.\n\n**3. Expansion inside `binary_to_term/2`**\n\n`GRPC.Codec.Erlpack.decode/2` calls `:erlang.binary_to_term(binary, [:safe])`. The Erlang external term format has a compressed form (version byte 131, tag 80, a 32-bit uncompressed size, then a zlib stream). `binary_to_term/2` inflates it in full, and the `:safe` option does not limit the size. `ensure_safe_term!/1` runs after the call returns and accepts a large binary.\n\n**4. Result**\n\nIn a test against grpc_server 1.0.6, a 260,932-byte request body decoded to a 268,435,456-byte binary, which the server passed to the application callback."
}
],
"value": "1. Codec selection\n\nThe server selects the codec from the request Content-Type. application/grpc+erlpack selects GRPC.Codec.Erlpack when the server registers it. No authentication step comes before this.\n\n2. Size limit on compressed bytes only\n\nThe server limits the request body with max_body_size, which counts the bytes received. With the gRPC compressed flag set to 0, the transport decompression limit does not apply, and the message reaches the codec unchanged.\n\n3. Expansion inside binary_to_term/2\n\nGRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term(binary, [:safe]). The Erlang external term format has a compressed form (version byte 131, tag 80, a 32-bit uncompressed size, then a zlib stream). binary_to_term/2 inflates it in full, and the :safe option does not limit the size. ensure_safe_term!/1 runs after the call returns and accepts a large binary.\n\n4. Result\n\nIn a test against grpc_server 1.0.6, a 260,932-byte request body decoded to a 268,435,456-byte binary, which the server passed to the application callback."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-121808",
"datePublished": "2026-11-13T15:48:49.871Z",
"dateReserved": "2026-11-09T22:35:50.462Z",
"dateUpdated": "2026-11-13T15:48:49.871Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-121691 (GCVE-0-2026-121691)
Vulnerability from cvelistv5 – Published: 2026-11-10 17:29 – Updated: 2026-11-10 17:29 X_Open Source
VLAI
EPSS
VEX
Title
Unbounded decompression in the whatstk ZIP loader exhausts memory and disk
Summary
Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because _str_from_file() (whatstk/whatsapp/parser.py) calls zip_ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. _clean_text() then passes the whole text through unicodedata.normalize("NFKD", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from_source() and df_from_whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available.
Severity
CWE
- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://github.com/lucasrodes/whatstk/pull/182 | patch |
| https://github.com/lucasrodes/whatstk/commit/01d66d8 | patch |
| https://github.com/lucasrodes/whatstk/releases/ta… | release-notes |
| https://secur0.com/en/cna/cve-list/cve-2026-12169… | third-party-advisorytechnical-description |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| lucasrodes | whatstk |
Affected:
0.7.0 , < 0.9.0
(semver)
cpe:2.3:a:lucasrodes:whatstk:*:*:*:*:*:python:*:* |
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://pypi.org",
"defaultStatus": "unaffected",
"packageName": "whatstk",
"product": "whatstk",
"programFiles": [
"whatstk/whatsapp/parser.py"
],
"repo": "https://github.com/lucasrodes/whatstk",
"vendor": "lucasrodes",
"versions": [
{
"lessThan": "0.9.0",
"status": "affected",
"version": "0.7.0",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:lucasrodes:whatstk:*:*:*:*:*:python:*:*",
"versionEndExcluding": "0.9.0",
"versionStartIncluding": "0.7.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "OR"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Jorge Rey Cotallo (reddev)"
},
{
"lang": "en",
"type": "analyst",
"value": "Xo\u00e1n M. Otero Jorge"
},
{
"lang": "en",
"type": "analyst",
"value": "Dar\u00edo Rivas"
},
{
"lang": "en",
"type": "coordinator",
"value": "Secur0 CNA"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Lucas Rod\u00e9s-Guirao"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because \u003ccode\u003e_str_from_file()\u003c/code\u003e (\u003ccode\u003ewhatstk/whatsapp/parser.py\u003c/code\u003e) calls \u003ccode\u003ezip_ref.extractall()\u003c/code\u003e with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with \u003ccode\u003ef.read()\u003c/code\u003e. The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after \u003ccode\u003eextractall()\u003c/code\u003e has already written them, so it does not prevent the cost. \u003ccode\u003e_clean_text()\u003c/code\u003e then passes the whole text through \u003ccode\u003eunicodedata.normalize(\"NFKD\", text)\u003c/code\u003e, which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of \u003ccode\u003eWhatsAppChat.from_source()\u003c/code\u003e and \u003ccode\u003edf_from_whatsapp()\u003c/code\u003e, and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available."
}
],
"value": "Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because _str_from_file() (whatstk/whatsapp/parser.py) calls zip_ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. _clean_text() then passes the whole text through unicodedata.normalize(\"NFKD\", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from_source() and df_from_whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 6.7,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-10T17:29:34.562Z",
"orgId": "4daa8cea-433a-44bd-9456-53b127fc289a",
"shortName": "Secur0"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/lucasrodes/whatstk/pull/182"
},
{
"tags": [
"patch"
],
"url": "https://github.com/lucasrodes/whatstk/commit/01d66d8"
},
{
"tags": [
"release-notes"
],
"url": "https://github.com/lucasrodes/whatstk/releases/tag/v0.9.0"
},
{
"tags": [
"third-party-advisory",
"technical-description"
],
"url": "https://secur0.com/en/cna/cve-list/cve-2026-121691-whatstk-zip-decompression-bomb"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Upgrade to whatstk 0.9.0 or later, which rejects a source larger than 50 MB by default and accepts a \u003ccode\u003emax_size\u003c/code\u003e argument to lower that bound."
}
],
"value": "Upgrade to whatstk 0.9.0 or later, which rejects a source larger than 50 MB by default and accepts a max_size argument to lower that bound."
}
],
"source": {
"discovery": "EXTERNAL"
},
"tags": [
"x_open-source"
],
"title": "Unbounded decompression in the whatstk ZIP loader exhausts memory and disk",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "4daa8cea-433a-44bd-9456-53b127fc289a",
"assignerShortName": "Secur0",
"cveId": "CVE-2026-121691",
"datePublished": "2026-11-10T17:29:34.562Z",
"dateReserved": "2026-11-03T20:07:54.134Z",
"dateUpdated": "2026-11-10T17:29:34.562Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-119434 (GCVE-0-2026-119434)
Vulnerability from cvelistv5 – Published: 2026-11-05 20:15 – Updated: 2026-11-05 20:45
VLAI
EPSS
VEX
Title
Decompression bomb in ezstd:decompress_using_ddict/2 allows BEAM memory exhaustion via unbounded output buffer
Summary
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in silviucpp ezstd allows an attacker who supplies a zstd frame to ezstd:decompress_using_ddict/2 to exhaust memory and terminate the Erlang VM via a small frame that declares a very large content size.
zstd_nif_decompress_using_ddict in c_src/ezstd_nif.cc reads the frame's declared content size with ZSTD_getFrameContentSize and passes it directly to enif_make_new_binary, without the 1 GiB MAX_BUFFER_SIZE check that ezstd:decompress/1 applies before allocating. A valid 65,550-byte frame of RLE blocks declaring 2 GiB is rejected by ezstd:decompress/1 but is fully allocated and decompressed by the dictionary path. The allocation happens inside a NIF, so when it exceeds the memory available to the VM the operating system kills the whole node rather than the calling process.
This issue affects ezstd: from 1.0.5 before 1.2.5.
Severity
6.2 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-05 20:45 UTC
CWE
- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/silviucpp/ezstd/releases/tag/v1.2.5 | release-notesrelated |
| https://cna.erlef.org/cves/CVE-2026-119434.html | relatedthird-party-advisory |
| https://osv.dev/vulnerability/EEF-CVE-2026-119434 | related |
| https://github.com/silviucpp/ezstd/commit/6730128… | related |
| https://github.com/silviucpp/ezstd/commit/e34f4a4… | patch |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 6.2,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2026-119434",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-05T20:45:27.204341Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-05T20:45:33.490Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"ezstd_nif",
"ezstd"
],
"packageName": "ezstd",
"packageURL": "pkg:hex/ezstd",
"product": "ezstd",
"programFiles": [
"c_src/ezstd_nif.cc",
"src/ezstd_nif.erl",
"src/ezstd.erl"
],
"programRoutines": [
{
"name": "zstd_nif_decompress_using_ddict"
},
{
"name": "ezstd_nif:decompress_using_ddict/2"
},
{
"name": "ezstd:decompress_using_ddict/2"
}
],
"repo": "https://github.com/silviucpp/ezstd",
"vendor": "silviucpp",
"versions": [
{
"lessThan": "1.2.5",
"status": "affected",
"version": "1.0.5",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"ezstd_nif",
"ezstd"
],
"packageName": "silviucpp/ezstd",
"packageURL": "pkg:github/silviucpp/ezstd",
"product": "ezstd",
"programFiles": [
"c_src/ezstd_nif.cc",
"src/ezstd_nif.erl",
"src/ezstd.erl"
],
"programRoutines": [
{
"name": "zstd_nif_decompress_using_ddict"
},
{
"name": "ezstd_nif:decompress_using_ddict/2"
},
{
"name": "ezstd:decompress_using_ddict/2"
}
],
"repo": "https://github.com/silviucpp/ezstd",
"vendor": "silviucpp",
"versions": [
{
"lessThan": "e34f4a4f6dc18d990d1cece2d5fceef8e934a195",
"status": "affected",
"version": "6730128b1d35eca02a2028671421471ff651f423",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.2.5",
"versionStartIncluding": "1.0.5",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Oz Kaiser"
},
{
"lang": "en",
"type": "reporter",
"value": "Oz Kaiser"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Silviu Caragea"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-11-04T17:02:50.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Handling of Highly Compressed Data (Data Amplification) vulnerability in silviucpp ezstd allows an attacker who supplies a zstd frame to \u003ccode\u003eezstd:decompress_using_ddict/2\u003c/code\u003e to exhaust memory and terminate the Erlang VM via a small frame that declares a very large content size.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ezstd_nif_decompress_using_ddict\u003c/code\u003e in \u003ccode\u003ec_src/ezstd_nif.cc\u003c/code\u003e reads the frame\u0027s declared content size with \u003ccode\u003eZSTD_getFrameContentSize\u003c/code\u003e and passes it directly to \u003ccode\u003eenif_make_new_binary\u003c/code\u003e, without the 1 GiB \u003ccode\u003eMAX_BUFFER_SIZE\u003c/code\u003e check that \u003ccode\u003eezstd:decompress/1\u003c/code\u003e applies before allocating. A valid 65,550-byte frame of RLE blocks declaring 2 GiB is rejected by \u003ccode\u003eezstd:decompress/1\u003c/code\u003e but is fully allocated and decompressed by the dictionary path. The allocation happens inside a NIF, so when it exceeds the memory available to the VM the operating system kills the whole node rather than the calling process.\u003c/p\u003e\n\u003cp\u003eThis issue affects ezstd: from 1.0.5 before 1.2.5.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in silviucpp ezstd allows an attacker who supplies a zstd frame to `ezstd:decompress_using_ddict/2` to exhaust memory and terminate the Erlang VM via a small frame that declares a very large content size.\n\n`zstd_nif_decompress_using_ddict` in `c_src/ezstd_nif.cc` reads the frame\u0027s declared content size with `ZSTD_getFrameContentSize` and passes it directly to `enif_make_new_binary`, without the 1 GiB `MAX_BUFFER_SIZE` check that `ezstd:decompress/1` applies before allocating. A valid 65,550-byte frame of RLE blocks declaring 2 GiB is rejected by `ezstd:decompress/1` but is fully allocated and decompressed by the dictionary path. The allocation happens inside a NIF, so when it exceeds the memory available to the VM the operating system kills the whole node rather than the calling process.\n\nThis issue affects ezstd: from 1.0.5 before 1.2.5."
}
],
"value": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in silviucpp ezstd allows an attacker who supplies a zstd frame to ezstd:decompress_using_ddict/2 to exhaust memory and terminate the Erlang VM via a small frame that declares a very large content size.\n\nzstd_nif_decompress_using_ddict in c_src/ezstd_nif.cc reads the frame\u0027s declared content size with ZSTD_getFrameContentSize and passes it directly to enif_make_new_binary, without the 1 GiB MAX_BUFFER_SIZE check that ezstd:decompress/1 applies before allocating. A valid 65,550-byte frame of RLE blocks declaring 2 GiB is rejected by ezstd:decompress/1 but is fully allocated and decompressed by the dictionary path. The allocation happens inside a NIF, so when it exceeds the memory available to the VM the operating system kills the whole node rather than the calling process.\n\nThis issue affects ezstd: from 1.0.5 before 1.2.5."
}
],
"impacts": [
{
"capecId": "CAPEC-130",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker who can submit a zstd frame to a service that decompresses it with a fixed dictionary can crash the entire Erlang VM with a single request of about 65 KiB. Every application and process hosted in that VM is taken down, not only the one that called the decompressor.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker who can submit a zstd frame to a service that decompresses it with a fixed dictionary can crash the entire Erlang VM with a single request of about 65 KiB. Every application and process hosted in that VM is taken down, not only the one that called the decompressor."
}
],
"value": "An attacker who can submit a zstd frame to a service that decompresses it with a fixed dictionary can crash the entire Erlang VM with a single request of about 65 KiB. Every application and process hosted in that VM is taken down, not only the one that called the decompressor."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-05T20:15:56.311Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "ezstd v1.2.5 release notes",
"tags": [
"release-notes",
"related"
],
"url": "https://github.com/silviucpp/ezstd/releases/tag/v1.2.5"
},
{
"name": "EEF CNA record for CVE-2026-119434",
"tags": [
"related",
"third-party-advisory"
],
"url": "https://cna.erlef.org/cves/CVE-2026-119434.html"
},
{
"name": "OSV record EEF-CVE-2026-119434",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-119434"
},
{
"name": "Introducing commit 6730128 in silviucpp/ezstd",
"tags": [
"related"
],
"url": "https://github.com/silviucpp/ezstd/commit/6730128b1d35eca02a2028671421471ff651f423"
},
{
"name": "Fix commit e34f4a4 in silviucpp/ezstd",
"tags": [
"patch"
],
"url": "https://github.com/silviucpp/ezstd/commit/e34f4a4f6dc18d990d1cece2d5fceef8e934a195"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Decompression bomb in ezstd:decompress_using_ddict/2 allows BEAM memory exhaustion via unbounded output buffer",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReplace calls to \u003ccode\u003eezstd:decompress_using_ddict/2\u003c/code\u003e with the streaming API: create a context with \u003ccode\u003eezstd:create_decompression_context/1\u003c/code\u003e using a small output buffer, attach the dictionary with \u003ccode\u003eezstd:select_ddict/2\u003c/code\u003e, and decompress with \u003ccode\u003eezstd:decompress_streaming/2\u003c/code\u003e. The streaming path decompresses into the caller-sized buffer and gives up with \u003ccode\u003e{error, decompressor_stuck}\u003c/code\u003e after 1000 chunks, so a 64 KiB buffer caps a single call at 64 MiB of output. Treat that error as a rejected input. Legitimate frames whose output exceeds 1000 times the buffer size fail the same way, so size the buffer for the largest expected payload.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Replace calls to `ezstd:decompress_using_ddict/2` with the streaming API: create a context with `ezstd:create_decompression_context/1` using a small output buffer, attach the dictionary with `ezstd:select_ddict/2`, and decompress with `ezstd:decompress_streaming/2`. The streaming path decompresses into the caller-sized buffer and gives up with `{error, decompressor_stuck}` after 1000 chunks, so a 64 KiB buffer caps a single call at 64 MiB of output. Treat that error as a rejected input. Legitimate frames whose output exceeds 1000 times the buffer size fail the same way, so size the buffer for the largest expected payload."
}
],
"value": "Replace calls to ezstd:decompress_using_ddict/2 with the streaming API: create a context with ezstd:create_decompression_context/1 using a small output buffer, attach the dictionary with ezstd:select_ddict/2, and decompress with ezstd:decompress_streaming/2. The streaming path decompresses into the caller-sized buffer and gives up with {error, decompressor_stuck} after 1000 chunks, so a 64 KiB buffer caps a single call at 64 MiB of output. Treat that error as a rejected input. Legitimate frames whose output exceeds 1000 times the buffer size fail the same way, so size the buffer for the largest expected payload."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eBuild ezstd 1.2.4 and start a VM under an external memory limit, for example a container limited to 256 MiB.\u003c/li\u003e\n\u003cli\u003eCreate any decompression dictionary with \u003ccode\u003eezstd:create_ddict/1\u003c/code\u003e; its content does not matter because the frame carries no dictionary ID.\u003c/li\u003e\n\u003cli\u003eConstruct a zstd frame: the magic number, a frame header descriptor selecting an 8-byte content size, a window descriptor, a little-endian content size of 2 GiB, then 16,383 RLE blocks of 128 KiB each (block header \u003ccode\u003e0x02 0x00 0x10\u003c/code\u003e followed by one payload byte) and a final RLE block with the last-block bit set. The frame is 65,550 bytes.\u003c/li\u003e\n\u003cli\u003eCall \u003ccode\u003eezstd:decompress/1\u003c/code\u003e on the frame: it returns \u003ccode\u003e{error, \u0026lt;\u0026lt;\"frame too large or invalid\"\u0026gt;\u0026gt;}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eCall \u003ccode\u003eezstd:decompress_using_ddict/2\u003c/code\u003e on the same frame with the dictionary: the VM is killed by the operating system (exit status 137).\u003c/li\u003e\n\u003cli\u003eRepeat on 1.2.5: the call returns \u003ccode\u003e{error, \u0026lt;\u0026lt;\"frame too large or invalid\"\u0026gt;\u0026gt;}\u003c/code\u003e and the VM continues.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Build ezstd 1.2.4 and start a VM under an external memory limit, for example a container limited to 256 MiB.\n2. Create any decompression dictionary with `ezstd:create_ddict/1`; its content does not matter because the frame carries no dictionary ID.\n3. Construct a zstd frame: the magic number, a frame header descriptor selecting an 8-byte content size, a window descriptor, a little-endian content size of 2 GiB, then 16,383 RLE blocks of 128 KiB each (block header `0x02 0x00 0x10` followed by one payload byte) and a final RLE block with the last-block bit set. The frame is 65,550 bytes.\n4. Call `ezstd:decompress/1` on the frame: it returns `{error, \u003c\u003c\"frame too large or invalid\"\u003e\u003e}`.\n5. Call `ezstd:decompress_using_ddict/2` on the same frame with the dictionary: the VM is killed by the operating system (exit status 137).\n6. Repeat on 1.2.5: the call returns `{error, \u003c\u003c\"frame too large or invalid\"\u003e\u003e}` and the VM continues."
}
],
"value": "* Build ezstd 1.2.4 and start a VM under an external memory limit, for example a container limited to 256 MiB.\n* Create any decompression dictionary with ezstd:create_ddict/1; its content does not matter because the frame carries no dictionary ID.\n* Construct a zstd frame: the magic number, a frame header descriptor selecting an 8-byte content size, a window descriptor, a little-endian content size of 2 GiB, then 16,383 RLE blocks of 128 KiB each (block header 0x02 0x00 0x10 followed by one payload byte) and a final RLE block with the last-block bit set. The frame is 65,550 bytes.\n* Call ezstd:decompress/1 on the frame: it returns {error, \u003c\u003c\"frame too large or invalid\"\u003e\u003e}.\n* Call ezstd:decompress_using_ddict/2 on the same frame with the dictionary: the VM is killed by the operating system (exit status 137).\n* Repeat on 1.2.5: the call returns {error, \u003c\u003c\"frame too large or invalid\"\u003e\u003e} and the VM continues."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Declared size is attacker controlled.\u003c/strong\u003e A zstd frame header carries an optional Frame Content Size field. \u003ccode\u003ezstd_nif_decompress_using_ddict\u003c/code\u003e in \u003ccode\u003ec_src/ezstd_nif.cc\u003c/code\u003e reads it with \u003ccode\u003eZSTD_getFrameContentSize\u003c/code\u003e and rejects only the two sentinel values \u003ccode\u003eZSTD_CONTENTSIZE_UNKNOWN\u003c/code\u003e and \u003ccode\u003eZSTD_CONTENTSIZE_ERROR\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Unbounded allocation.\u003c/strong\u003e The size is passed directly to \u003ccode\u003eenif_make_new_binary\u003c/code\u003e, so a frame declaring 2 GiB makes the NIF request a 2 GiB binary. The sibling \u003ccode\u003ezstd_nif_decompress\u003c/code\u003e rejects any declared size above \u003ccode\u003eMAX_BUFFER_SIZE\u003c/code\u003e (1 GiB) before allocating; the dictionary path omitted that check from the commit that introduced it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Amplification.\u003c/strong\u003e A frame built from RLE blocks, each encoding 128 KiB of a repeated byte in four bytes, declares and genuinely decompresses to 2 GiB from 65,550 bytes of input, a ratio of about 32,760:1. \u003ccode\u003eZSTD_decompress_usingDDict\u003c/code\u003e then fills the buffer. Because this happens inside a NIF, exceeding the memory available to the VM results in the operating system killing the whole BEAM process rather than an Erlang-level exception.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Declared size is attacker controlled.** A zstd frame header carries an optional Frame Content Size field. `zstd_nif_decompress_using_ddict` in `c_src/ezstd_nif.cc` reads it with `ZSTD_getFrameContentSize` and rejects only the two sentinel values `ZSTD_CONTENTSIZE_UNKNOWN` and `ZSTD_CONTENTSIZE_ERROR`.\n\n**2. Unbounded allocation.** The size is passed directly to `enif_make_new_binary`, so a frame declaring 2 GiB makes the NIF request a 2 GiB binary. The sibling `zstd_nif_decompress` rejects any declared size above `MAX_BUFFER_SIZE` (1 GiB) before allocating; the dictionary path omitted that check from the commit that introduced it.\n\n**3. Amplification.** A frame built from RLE blocks, each encoding 128 KiB of a repeated byte in four bytes, declares and genuinely decompresses to 2 GiB from 65,550 bytes of input, a ratio of about 32,760:1. `ZSTD_decompress_usingDDict` then fills the buffer. Because this happens inside a NIF, exceeding the memory available to the VM results in the operating system killing the whole BEAM process rather than an Erlang-level exception."
}
],
"value": "1. Declared size is attacker controlled. A zstd frame header carries an optional Frame Content Size field. zstd_nif_decompress_using_ddict in c_src/ezstd_nif.cc reads it with ZSTD_getFrameContentSize and rejects only the two sentinel values ZSTD_CONTENTSIZE_UNKNOWN and ZSTD_CONTENTSIZE_ERROR.\n\n2. Unbounded allocation. The size is passed directly to enif_make_new_binary, so a frame declaring 2 GiB makes the NIF request a 2 GiB binary. The sibling zstd_nif_decompress rejects any declared size above MAX_BUFFER_SIZE (1 GiB) before allocating; the dictionary path omitted that check from the commit that introduced it.\n\n3. Amplification. A frame built from RLE blocks, each encoding 128 KiB of a repeated byte in four bytes, declares and genuinely decompresses to 2 GiB from 65,550 bytes of input, a ratio of about 32,760:1. ZSTD_decompress_usingDDict then fills the buffer. Because this happens inside a NIF, exceeding the memory available to the VM results in the operating system killing the whole BEAM process rather than an Erlang-level exception."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-119434",
"datePublished": "2026-11-05T20:15:56.311Z",
"dateReserved": "2026-10-30T10:30:01.015Z",
"dateUpdated": "2026-11-05T20:45:33.490Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-118761 (GCVE-0-2026-118761)
Vulnerability from cvelistv5 – Published: 2026-10-29 16:37 – Updated: 2026-10-29 20:18
VLAI
EPSS
VEX
Title
Kubeflow Pipelines: Pipeline archive upload allows decompression bomb to exhaust server memory
Summary
Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the API server decompressed uploaded pipeline archives without adequately bounding expanded data while locating or reading the pipeline file. A small ZIP or gzip-compressed tar archive can consume disproportionately large memory and exhaust API-server resources. Multipart pipeline and pipeline-version upload processing performs decompression before namespace authorization, so a reachable caller does not need a successful pipeline-create authorization decision. URL-import handlers authorize before fetching and decompressing a remote archive. The amount of expansion required to interrupt service depends on deployment resource limits and concurrent activity, and no specific archive is guaranteed to crash every deployment. This issue is fixed in version 2.18.0.
Severity
7.5 (High)
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-29 20:18 UTC
CWE
- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
Assigner
References
6 references
| URL | Tags |
|---|---|
| https://github.com/kubeflow/pipelines/security/ad… | x_refsource_CONFIRM |
| https://github.com/kubeflow/pipelines/pull/14171 | x_refsource_MISC |
| https://github.com/kubeflow/pipelines/pull/14186 | x_refsource_MISC |
| https://github.com/kubeflow/pipelines/commit/1121… | x_refsource_MISC |
| https://github.com/kubeflow/pipelines/commit/ba9a… | x_refsource_MISC |
| https://github.com/kubeflow/pipelines/releases/ta… | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-118761",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-29T20:18:49.737846Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-29T20:18:59.625Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "pipelines",
"vendor": "kubeflow",
"versions": [
{
"status": "affected",
"version": "\u003c 2.18.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the API server decompressed uploaded pipeline archives without adequately bounding expanded data while locating or reading the pipeline file. A small ZIP or gzip-compressed tar archive can consume disproportionately large memory and exhaust API-server resources. Multipart pipeline and pipeline-version upload processing performs decompression before namespace authorization, so a reachable caller does not need a successful pipeline-create authorization decision. URL-import handlers authorize before fetching and decompressing a remote archive. The amount of expansion required to interrupt service depends on deployment resource limits and concurrent activity, and no specific archive is guaranteed to crash every deployment. This issue is fixed in version 2.18.0."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-29T16:37:44.333Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/kubeflow/pipelines/security/advisories/GHSA-8fmv-6rg5-5924",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/kubeflow/pipelines/security/advisories/GHSA-8fmv-6rg5-5924"
},
{
"name": "https://github.com/kubeflow/pipelines/pull/14171",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/kubeflow/pipelines/pull/14171"
},
{
"name": "https://github.com/kubeflow/pipelines/pull/14186",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/kubeflow/pipelines/pull/14186"
},
{
"name": "https://github.com/kubeflow/pipelines/commit/1121d9a081fdf9e2107c39abb2cd8947727c6953",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/kubeflow/pipelines/commit/1121d9a081fdf9e2107c39abb2cd8947727c6953"
},
{
"name": "https://github.com/kubeflow/pipelines/commit/ba9ae72cc860e3afbea232185e4132fc2896cac5",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/kubeflow/pipelines/commit/ba9ae72cc860e3afbea232185e4132fc2896cac5"
},
{
"name": "https://github.com/kubeflow/pipelines/releases/tag/2.18.0",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/kubeflow/pipelines/releases/tag/2.18.0"
}
],
"source": {
"advisory": "GHSA-8fmv-6rg5-5924",
"discovery": "UNKNOWN"
},
"title": "Kubeflow Pipelines: Pipeline archive upload allows decompression bomb to exhaust server memory"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-118761",
"datePublished": "2026-10-29T16:37:44.333Z",
"dateReserved": "2026-10-28T19:20:05.017Z",
"dateUpdated": "2026-10-29T20:18:59.625Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-118261 (GCVE-0-2026-118261)
Vulnerability from cvelistv5 – Published: 2026-10-28 18:58 – Updated: 2026-10-29 20:54
VLAI
EPSS
VEX
Title
Echo: Decompress permits unbounded gzip expansion in v4
Summary
Echo is a Go web framework. From 4.0.0 until 4.16.1, Echo v4's opt-in Decompress middleware exposes a gzip-decoded request stream without limiting its expanded size. A small compressed request can expand into a very large body when a handler reads or binds it, consuming excessive memory or CPU and allowing repeated or concurrent requests to cause denial of service. The middleware is not enabled by default, and limiting only the compressed request size does not bound the decoded size. This issue is fixed in 4.16.1.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-29 15:28 UTC
CWE
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/labstack/echo/security/advisor… | x_refsource_CONFIRM |
| https://github.com/labstack/echo/commit/3fb0ba7e1… | x_refsource_MISC |
| https://github.com/labstack/echo/releases/tag/v4.16.1 | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-118261",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-29T15:28:34.378293Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-29T20:54:55.973Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "echo",
"vendor": "labstack",
"versions": [
{
"status": "affected",
"version": "\u003e= 4.0.0, \u003c 4.16.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Echo is a Go web framework. From 4.0.0 until 4.16.1, Echo v4\u0027s opt-in Decompress middleware exposes a gzip-decoded request stream without limiting its expanded size. A small compressed request can expand into a very large body when a handler reads or binds it, consuming excessive memory or CPU and allowing repeated or concurrent requests to cause denial of service. The middleware is not enabled by default, and limiting only the compressed request size does not bound the decoded size. This issue is fixed in 4.16.1."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400: Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-28T18:58:43.504Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/labstack/echo/security/advisories/GHSA-h7wr-284f-5qvc",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/labstack/echo/security/advisories/GHSA-h7wr-284f-5qvc"
},
{
"name": "https://github.com/labstack/echo/commit/3fb0ba7e17645bb65611e2a08875d0a2f65c421f",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/labstack/echo/commit/3fb0ba7e17645bb65611e2a08875d0a2f65c421f"
},
{
"name": "https://github.com/labstack/echo/releases/tag/v4.16.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/labstack/echo/releases/tag/v4.16.1"
}
],
"source": {
"advisory": "GHSA-h7wr-284f-5qvc",
"discovery": "UNKNOWN"
},
"title": "Echo: Decompress permits unbounded gzip expansion in v4"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-118261",
"datePublished": "2026-10-28T18:58:43.504Z",
"dateReserved": "2026-10-27T20:13:55.314Z",
"dateUpdated": "2026-10-29T20:54:55.973Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-117677 (GCVE-0-2026-117677)
Vulnerability from cvelistv5 – Published: 2026-11-01 09:48 – Updated: 2026-11-09 17:03
VLAI
EPSS
VEX
Title
Gitea Helm chart upload decompression denial of service
Summary
When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry while looking for `Chart.yaml` without limiting the decompressed size, and did so before the package size quota was checked; the quota only considers the compressed upload size. A user with package write access to an owner, for example their own account on an instance with open registration, could repeatedly upload small, highly compressed archives that make the server spend CPU time proportional to the decompressed size, degrading the availability of the Gitea instance. The issue does not allow code execution or data access.
Severity
6.5 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-09 17:03 UTC
CWE
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/go-gitea/gitea/security/adviso… | vendor-advisory |
| https://github.com/go-gitea/gitea/pull/39942 | patch |
| https://github.com/go-gitea/gitea/pull/40085 | patch |
| https://blog.gitea.com/release-of-28.3.0/ | release-notes |
| https://github.com/go-gitea/gitea/releases/tag/v28.3.0 | release-notes |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2026-117677",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-09T17:03:24.732025Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-09T17:03:42.235Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageName": "gitea.dev",
"product": "Gitea",
"vendor": "Gitea",
"versions": [
{
"lessThan": "28.3.0",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "https://github.com/skeletonsec"
},
{
"lang": "en",
"type": "reporter",
"value": "https://github.com/jisung-02"
},
{
"lang": "en",
"type": "reporter",
"value": "https://github.com/kewmine"
},
{
"lang": "en",
"type": "remediation developer",
"value": "https://github.com/bircni"
}
],
"descriptions": [
{
"lang": "en",
"value": "When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry while looking for `Chart.yaml` without limiting the decompressed size, and did so before the package size quota was checked; the quota only considers the compressed upload size. A user with package write access to an owner, for example their own account on an instance with open registration, could repeatedly upload small, highly compressed archives that make the server spend CPU time proportional to the decompressed size, degrading the availability of the Gitea instance. The issue does not allow code execution or data access."
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400: Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-409",
"description": "CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-01T09:48:45.233Z",
"orgId": "88ee5874-cf24-4952-aea0-31affedb7ff2",
"shortName": "Gitea"
},
"references": [
{
"name": "GitHub Security Advisory GHSA-r6mh-qg79-rqj2",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-r6mh-qg79-rqj2"
},
{
"name": "Fix: go-gitea/gitea pull request #39942",
"tags": [
"patch"
],
"url": "https://github.com/go-gitea/gitea/pull/39942"
},
{
"name": "Fix backport to release/v28: go-gitea/gitea pull request #40085",
"tags": [
"patch"
],
"url": "https://github.com/go-gitea/gitea/pull/40085"
},
{
"name": "Gitea 28.3.0 release announcement",
"tags": [
"release-notes"
],
"url": "https://blog.gitea.com/release-of-28.3.0/"
},
{
"name": "go-gitea/gitea v28.3.0 release",
"tags": [
"release-notes"
],
"url": "https://github.com/go-gitea/gitea/releases/tag/v28.3.0"
}
],
"title": "Gitea Helm chart upload decompression denial of service"
}
},
"cveMetadata": {
"assignerOrgId": "88ee5874-cf24-4952-aea0-31affedb7ff2",
"assignerShortName": "Gitea",
"cveId": "CVE-2026-117677",
"datePublished": "2026-11-01T09:48:45.233Z",
"dateReserved": "2026-11-01T08:50:49.241Z",
"dateUpdated": "2026-11-09T17:03:42.235Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.