Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2026-103262 (GCVE-0-2026-103262)
Vulnerability from cvelistv5 – Published: 2026-10-01 10:42 – Updated: 2026-10-06 00:08- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
| URL | Tags |
|---|---|
| https://github.com/tornadoweb/tornado/security/ad… | vendor-advisory |
| https://github.com/tornadoweb/tornado/commit/e412… | patch |
| https://www.vulncheck.com/advisories/tornado-befo… | third-party-advisory |
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| tornadoweb | tornado |
Affected:
0 , < 6.5.9
(semver)
Unaffected: 6.5.9 (semver) cpe:2.3:a:tornadoweb:tornado:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-103262",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-06T00:08:34.189311Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-06T00:08:58.078Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageURL": "pkg:pypi/tornado",
"product": "tornado",
"vendor": "tornadoweb",
"versions": [
{
"lessThan": "6.5.9",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.9",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:tornadoweb:tornado:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.9",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "iaohkut-from-NightWolf-Team"
},
{
"lang": "en",
"type": "reporter",
"value": "aoto-tech"
}
],
"datePublic": "2026-09-14T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "Tornado versions before 6.5.9 contain an unbounded memory accumulation vulnerability in CurlAsyncHTTPClient that allows remote attackers to cause denial of service by sending a compressed response. Attackers can send a gzip-encoded decompression bomb that accumulates in memory without size limits, causing the application process to be killed by out-of-memory conditions."
}
],
"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-10-01T10:42:04.913Z",
"orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"shortName": "VulnCheck"
},
"references": [
{
"name": "GitHub Security Advisory (GHSA-chx6-46f5-w4vp)",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
},
{
"tags": [
"patch"
],
"url": "https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9"
},
{
"name": "VulnCheck Advisory: Tornado before 6.5.9 Denial of Service via CurlAsyncHTTPClient",
"tags": [
"third-party-advisory"
],
"url": "https://www.vulncheck.com/advisories/tornado-before-6.5.9-denial-of-service-via-curlasynchttpclient"
}
],
"title": "Tornado before 6.5.9 Denial of Service via CurlAsyncHTTPClient",
"x_generator": {
"engine": "vulncheck-endgame"
}
}
},
"cveMetadata": {
"assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"assignerShortName": "VulnCheck",
"cveId": "CVE-2026-103262",
"datePublished": "2026-10-01T10:42:04.913Z",
"dateReserved": "2026-09-30T10:55:39.869Z",
"dateUpdated": "2026-10-06T00:08:58.078Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-103262",
"date": "2026-11-13",
"epss": "0.00628",
"percentile": "0.50662"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"packageURL": "pkg:pypi/tornado",
"product": "tornado",
"vendor": "tornadoweb",
"versions": [
{
"lessThan": "6.5.9",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.9",
"versionType": "semver"
}
]
}
],
"source": "disclosure@vulncheck.com"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Tornado versions before 6.5.9 contain an unbounded memory accumulation vulnerability in CurlAsyncHTTPClient that allows remote attackers to cause denial of service by sending a compressed response. Attackers can send a gzip-encoded decompression bomb that accumulates in memory without size limits, causing the application process to be killed by out-of-memory conditions."
}
],
"id": "CVE-2026-103262",
"lastModified": "2026-10-06T01:16:32.767",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"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"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6,
"source": "disclosure@vulncheck.com",
"type": "Secondary"
}
],
"cvssMetricV40": [
{
"cvssData": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"availabilityRequirement": "NOT_DEFINED",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"confidentialityRequirement": "NOT_DEFINED",
"exploitMaturity": "NOT_DEFINED",
"integrityRequirement": "NOT_DEFINED",
"modifiedAttackComplexity": "NOT_DEFINED",
"modifiedAttackRequirements": "NOT_DEFINED",
"modifiedAttackVector": "NOT_DEFINED",
"modifiedPrivilegesRequired": "NOT_DEFINED",
"modifiedSubAvailabilityImpact": "NOT_DEFINED",
"modifiedSubConfidentialityImpact": "NOT_DEFINED",
"modifiedSubIntegrityImpact": "NOT_DEFINED",
"modifiedUserInteraction": "NOT_DEFINED",
"modifiedVulnAvailabilityImpact": "NOT_DEFINED",
"modifiedVulnConfidentialityImpact": "NOT_DEFINED",
"modifiedVulnIntegrityImpact": "NOT_DEFINED",
"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:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"source": "disclosure@vulncheck.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-103262",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-06T00:08:34.189311Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-10-01T11:17:21.050",
"references": [
{
"source": "disclosure@vulncheck.com",
"url": "https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9"
},
{
"source": "disclosure@vulncheck.com",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
},
{
"source": "disclosure@vulncheck.com",
"url": "https://www.vulncheck.com/advisories/tornado-before-6.5.9-denial-of-service-via-curlasynchttpclient"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
}
],
"sourceIdentifier": "disclosure@vulncheck.com",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-409"
}
],
"source": "disclosure@vulncheck.com",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Important",
"current_release_date": "2026-11-13T12:19:42+00:00",
"cve": "CVE-2026-103262",
"id": "CVE-2026-103262",
"initial_release_date": "2026-10-01T10:42:04.913000+00:00",
"product_status:fixed": "128",
"product_status:known_affected": "44",
"product_status:known_not_affected": "1074",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "tornado: Tornado: Denial of Service via decompression bomb in CurlAsyncHTTPClient",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-103262.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-11-06T00:45:35Z",
"cve": "CVE-2026-103262",
"id": "CVE-2026-103262",
"initial_release_date": "2026-10-01T15:59:04Z",
"product_status:known_affected": "56",
"product_status:known_not_affected": "92",
"product_status:recommended": "3",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2026-103262",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/2026/cve-2026-103262.json",
"version": "8"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-103262",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-06T00:08:34.189311Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-06T00:08:51.285Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageURL": "pkg:pypi/tornado",
"product": "tornado",
"vendor": "tornadoweb",
"versions": [
{
"lessThan": "6.5.9",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.9",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:tornadoweb:tornado:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.9",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "iaohkut-from-NightWolf-Team"
},
{
"lang": "en",
"type": "reporter",
"value": "aoto-tech"
}
],
"datePublic": "2026-09-14T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "Tornado versions before 6.5.9 contain an unbounded memory accumulation vulnerability in CurlAsyncHTTPClient that allows remote attackers to cause denial of service by sending a compressed response. Attackers can send a gzip-encoded decompression bomb that accumulates in memory without size limits, causing the application process to be killed by out-of-memory conditions."
}
],
"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-10-01T10:42:04.913Z",
"orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"shortName": "VulnCheck"
},
"references": [
{
"name": "GitHub Security Advisory (GHSA-chx6-46f5-w4vp)",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
},
{
"tags": [
"patch"
],
"url": "https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9"
},
{
"name": "VulnCheck Advisory: Tornado before 6.5.9 Denial of Service via CurlAsyncHTTPClient",
"tags": [
"third-party-advisory"
],
"url": "https://www.vulncheck.com/advisories/tornado-before-6.5.9-denial-of-service-via-curlasynchttpclient"
}
],
"title": "Tornado before 6.5.9 Denial of Service via CurlAsyncHTTPClient",
"x_generator": {
"engine": "vulncheck-endgame"
}
}
},
"cveMetadata": {
"assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"assignerShortName": "VulnCheck",
"cveId": "CVE-2026-103262",
"datePublished": "2026-10-01T10:42:04.913Z",
"dateReserved": "2026-09-30T10:55:39.869Z",
"dateUpdated": "2026-10-06T00:08:58.078Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
ALSA-2026:82040 (CVE-2026-103262)
Vulnerability from osv_almalinux – Published: 2026-10-13 00:00 – Updated: 2026-10-14 09:04 – Source websitePython is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems.
Security Fix(es):
- tornado: Tornado: Denial of Service via decompression bomb in CurlAsyncHTTPClient (CVE-2026-103262)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
{
"affected": [
{
"package": {
"ecosystem": "AlmaLinux:9",
"name": "python3-tornado"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.10-1.el9_8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"details": "Python is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems. \n\nSecurity Fix(es): \n\n * tornado: Tornado: Denial of Service via decompression bomb in CurlAsyncHTTPClient (CVE-2026-103262)\n\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.\n",
"id": "ALSA-2026:82040",
"modified": "2026-10-14T09:04:56Z",
"published": "2026-10-13T00:00:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://access.redhat.com/errata/RHSA-2026:82040"
},
{
"type": "REPORT",
"url": "https://access.redhat.com/security/cve/CVE-2026-103262"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/2544534"
},
{
"type": "ADVISORY",
"url": "https://errata.almalinux.org/9/ALSA-2026-82040.html"
}
],
"related": [
"CVE-2026-103262"
],
"schema_version": "1.7.0",
"summary": "Important: python-tornado security update",
"upstream": [
"CVE-2026-103262"
]
}
ALSA-2026:82041 (CVE-2026-103262)
Vulnerability from osv_almalinux – Published: 2026-10-13 00:00 – Updated: 2026-10-14 09:08 – Source websitePython is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems.
Security Fix(es):
- tornado: Tornado: Denial of Service via decompression bomb in CurlAsyncHTTPClient (CVE-2026-103262)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
{
"affected": [
{
"package": {
"ecosystem": "AlmaLinux:10",
"name": "python3-tornado"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.10-1.el10_2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"details": "Python is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems. \n\nSecurity Fix(es): \n\n * tornado: Tornado: Denial of Service via decompression bomb in CurlAsyncHTTPClient (CVE-2026-103262)\n\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.\n",
"id": "ALSA-2026:82041",
"modified": "2026-10-14T09:08:00Z",
"published": "2026-10-13T00:00:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://access.redhat.com/errata/RHSA-2026:82041"
},
{
"type": "REPORT",
"url": "https://access.redhat.com/security/cve/CVE-2026-103262"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/2544534"
},
{
"type": "ADVISORY",
"url": "https://errata.almalinux.org/10/ALSA-2026-82041.html"
}
],
"related": [
"CVE-2026-103262"
],
"schema_version": "1.7.0",
"summary": "Important: python-tornado security update",
"upstream": [
"CVE-2026-103262"
]
}
BELL-CVE-2026-103262 (CVE-2026-103262)
Vulnerability from osv_bellsoft – Published: 2026-10-02 06:05 – Updated: 2026-10-06 12:08 – Source website| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpaquita:25",
"name": "py3-tornado",
"purl": "pkg:apk/alpaquita/py3-tornado?arch=source\u0026distro=25"
},
"ranges": [
{
"events": [
{
"introduced": "6.5.1-r0"
},
{
"fixed": "6.5.10-r0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Alpaquita:stream",
"name": "py3-tornado",
"purl": "pkg:apk/alpaquita/py3-tornado?arch=source\u0026distro=stream"
},
"ranges": [
{
"events": [
{
"introduced": "6.3.3-r0"
},
{
"fixed": "6.5.10-r0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"id": "BELL-CVE-2026-103262",
"modified": "2026-10-06T12:08:42.825038Z",
"published": "2026-10-02T06:05:04.892048Z",
"references": [
{
"type": "ADVISORY",
"url": "https://docs.bell-sw.com/security/cves/CVE-2026-103262"
}
],
"schema_version": "1.7.4",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"upstream": [
"CVE-2026-103262"
]
}
BREW-JUPYTERLAB-CVE-2026… (GHSA-CHX6-46F5-W4VP)
Vulnerability from osv_homebrew – Published: 2026-10-06 10:10 – Updated: 2026-10-29 22:14 – Source websiteAn unbounded memory accumulation (decompression bomb) in tornado.curl_httpclient.CurlAsyncHTTPClient — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (6.6.dev1) and present unchanged in the latest release tag v6.5.8 and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and fetch()es an attacker-chosen or attacker-compromised URL with default decompress_response=True, a malicious server replying Content-Encoding: gzip with a ~2.8 MB wire bomb drove the client's RSS from 30,884 kB to 1,032,100 kB (~1008 MB) in 3.18 s (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup OOMKilled=true) — with the transfer only 67% complete and no client-side size check ever intervening: curl_httpclient.py contains zero occurrences of max_body_size/MAXFILESIZE. The identical bomb against the default SimpleAsyncHTTPClient fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size — http1connection.py:620,676,742) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed _GzipMessageDelegate/SimpleAsyncHTTPClient only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file's full commit history (latest 2026-06-17) shows no response-size work.
Details
tornado/curl_httpclient.py (line numbers identical on master 6.6.dev1, v6.5.8, and the audited snapshot):
"buffer": BytesIO(), # :202 — plain BytesIO, no accounting
...
else:
write_function = buffer.write # :359 — every decompressed byte lands here
curl.setopt(pycurl.WRITEFUNCTION, write_function) # :360
...
if request.decompress_response: # default True (HTTPRequest)
curl.setopt(pycurl.ENCODING, "gzip,deflate") # :373-374 — libcurl advertises + auto-decodes
libcurl decompresses the response before invoking WRITEFUNCTION, so the callback receives decompressed bytes, which are appended to an unbounded BytesIO until the transfer ends or the process dies. The only ceiling is request_timeout (default 20 s) — at zlib's hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no pycurl.MAXFILESIZE, no max_buffer_size/max_body_size plumbing (the constructor accepts no body-size option), and streaming_callback users fare no better (the callback variant at :353-356 also performs zero accounting).
Contrast — SimpleAsyncHTTPClient path (tornado/http1connection.py), all absent from the curl path:
if cast(int, content_length) > self._max_body_size: # :620 Content-Length gate
if total_size > self._max_body_size: # :676 chunked total gate
if self._decompressed_body_size > self._max_body_size: # :742 CVE-2026-49855 decompressed gate
SimpleAsyncHTTPClient.initialize() defaults max_buffer_size = 104857600 (100 MiB) with max_body_size defaulting to it (simple_httpclient.py:117-121); CurlAsyncHTTPClient.initialize() has no corresponding parameter at all.
Attack chain (attacker = malicious HTTP server; victim = any Tornado app doing fetch() on attacker-influenced URLs — URL fetchers, webhook processors, link previewers, RSS/probe pollers):
- App configures
AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")(documented for proxy support; proxies are only supported with the curl client). - App calls
fetch("http://attacker/...")with defaults → request advertisesAccept-Encoding: gzip,deflate. - Attacker replies
200,Content-Encoding: gzip,Transfer-Encoding: chunked, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks). - libcurl auto-decodes at ~350 MB/s into
buffer.writewith no size accounting → process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).
Variant without compression: decompress_response=False plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted buffer.write — this client never enforces any cap on any path.
PoC
Verified end-to-end 2026-08-15 in a single container (cgroup --memory 1g --memory-swap 1g so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on 127.0.0.1:8081: a raw-socket malicious server (evil_server.py, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (victim_curl.py, configures CurlAsyncHTTPClient, fetch(..., request_timeout=300), samples /proc/self/status VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).
Build & run the victim
git clone https://github.com/tornadoweb/tornado
cd tornado
pip install pycurl
python evil_server.py & # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING
python victim_curl.py # victim: CurlAsyncHTTPClient fetch -> expect linear RSS rise -> OOM
python victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb
Verified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot 6.6.dev1 of 2026-08-15 run from the source tree (sys.path), container memory capped at 1 GiB. curl_httpclient.py verified byte-equivalent (still zero size-limit references) in tag v6.5.8 and on master as of 2026-08-17.
Reproduction steps
-
Precondition — the documented curl-client deployment fetching a remote URL. The vulnerability requires the application to use
CurlAsyncHTTPClient(the standard configuration when proxy support or advanced TLS options are needed) with defaultdecompress_response=True, and to fetch a URL whose server the attacker controls or has compromised.victim_curl.pyimplements exactly that (AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")→fetch()), and the server log confirms the ENCODING path engaged — the victim's request arrived withUser-Agent: Mozilla/5.0 (compatible; pycurl)andAccept-Encoding: gzip,deflate. -
Attack: start
evil_server.py, wait forEVIL_LISTENING, then runvictim_curl.py(the fetch itself is the attack; no further interaction). -
Expected:
victim_curl_rss.logshows VmRSS 30,884 → 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (exit 137, dockerOOMKilled=true); the server logsCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525— the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered. -
Variant: with
decompress_response=Falseand an unterminated chunked body (server keeps sending forever), the samebuffer.writepath accumulates unbounded plain bytes — no compression needed;request_timeoutonly extends the ceiling. -
Control:
victim_simple.pyfetches the identical bomb with the defaultSimpleAsyncHTTPClient→ cleanFETCH_FAILED: HTTP 599: Connection closed, RSS peak ~65 MB (24,984 → 66,712 kB), script exit 0 — the CVE-2026-49855 accounting inhttp1connection.pyaborts the transfer, proving the gap is specific to the curl client.
PoC source
Full PoC source (victim_curl.py, stdlib only, no dependencies): victim_curl.py (secret gist, unlisted).
The gist carries evil_server.py (bomb server), victim_curl.py (victim), victim_simple.py (control), and REPRODUCE.md.
Captured output (2026-08-15 run, verbatim excerpts)
evil_server.log:
BOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1
EVIL_LISTENING 127.0.0.1:8081
REQUEST_FROM 127.0.0.1:57544 -> GET /bomb HTTP/1.1
REQUEST_HEADERS:
GET /bomb HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (compatible; pycurl)
Accept: */*
Accept-Encoding: gzip,deflate
WIRE_SENT 65536/4174525
WIRE_SENT 2162688/4174525
CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, 'Connection reset by peer')
victim_curl_rss.log (VmRSS kB, every 0.2 s):
0.00 30884
0.61 231848
1.41 514720
2.22 794480
2.82 1000756
3.18 1032100 <- last sample before kill
driver_f1.log:
timeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed
VICTIM_CURL_EXIT=137 # docker inspect -> OomKilled: true
victim_simple.log (control, same bomb):
FETCH_FAILED: HTTP 599: Connection closed
SCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB
Honest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test's 1 GiB cgroup cap as the observation instrument; the "unbounded" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path — with more memory the transfer would have continued to the full 4 GiB payload.
Impact
Denial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as available_memory / 1000. Because the accumulation happens on the shared event loop's client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim's configured client visits the attacker's origin.
Suggested fix
Enforce a byte budget in the write path of CurlAsyncHTTPClient: wrap the WRITEFUNCTION (both the buffer.write branch and the streaming_callback branch) in a counter that aborts the transfer (curl.setopt(pycurl.FAILONERROR)-style cancellation or raising from the callback) once the received total exceeds max_body_size, plumbed from initialize() with the same 100 MiB default as SimpleAsyncHTTPClient. Because libcurl decompresses before the write callback, the counter naturally measures decompressed bytes — the same semantics as the CVE-2026-49855 fix. (pycurl.MAXFILESIZE alone is insufficient: it applies to the compressed transfer size.)
Affected versions
- <= 6.5.8 (latest tag; the curl client has never had a response-size limit) and master (
6.6.dev1, verified 2026-08-15/17). - 6.5.6's CVE-2026-49855 fix covered
SimpleAsyncHTTPClient/http1connection.pyonly;curl_httpclient.pywas not touched.
Credit
Reported by the diff/ambidiff security research effort (afldl).
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "tornado",
"resource_purl": "pkg:pypi/tornado@6.6",
"upstream_fixed_in": "6.5.9"
},
"package": {
"ecosystem": "Homebrew",
"name": "jupyterlab",
"purl": "pkg:brew/jupyterlab"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "4.6.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/tornado@6.6",
"name": "tornado",
"resource": "tornado",
"strategy": "registry",
"subject_version": "6.6"
}
]
},
"details": "An unbounded memory accumulation (decompression bomb) in `tornado.curl_httpclient.CurlAsyncHTTPClient` \u2014 the client-side sibling gap of CVE-2026-49855 \u2014 verified end-to-end on the 2026-08-15 master snapshot (`6.6.dev1`) and present unchanged in the latest release tag `v6.5.8` and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and `fetch()`es an attacker-chosen or attacker-compromised URL with default `decompress_response=True`, a malicious server replying `Content-Encoding: gzip` with a ~2.8 MB wire bomb drove the client\u0027s RSS from 30,884 kB to **1,032,100 kB (~1008 MB) in 3.18 s** (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup `OOMKilled=true`) \u2014 with the transfer only 67% complete and **no client-side size check ever intervening**: `curl_httpclient.py` contains zero occurrences of `max_body_size`/`MAXFILESIZE`. The identical bomb against the default `SimpleAsyncHTTPClient` fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size \u2014 `http1connection.py:620,676,742`) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed `_GzipMessageDelegate`/`SimpleAsyncHTTPClient` only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file\u0027s full commit history (latest 2026-06-17) shows no response-size work.\n\n## Details\n\n`tornado/curl_httpclient.py` (line numbers identical on master `6.6.dev1`, `v6.5.8`, and the audited snapshot):\n\n```python\n\"buffer\": BytesIO(), # :202 \u2014 plain BytesIO, no accounting\n...\nelse:\n write_function = buffer.write # :359 \u2014 every decompressed byte lands here\ncurl.setopt(pycurl.WRITEFUNCTION, write_function) # :360\n...\nif request.decompress_response: # default True (HTTPRequest)\n curl.setopt(pycurl.ENCODING, \"gzip,deflate\") # :373-374 \u2014 libcurl advertises + auto-decodes\n```\n\nlibcurl decompresses the response **before** invoking `WRITEFUNCTION`, so the callback receives decompressed bytes, which are appended to an unbounded `BytesIO` until the transfer ends or the process dies. The only ceiling is `request_timeout` (default 20 s) \u2014 at zlib\u0027s hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no `pycurl.MAXFILESIZE`, no `max_buffer_size`/`max_body_size` plumbing (the constructor accepts no body-size option), and `streaming_callback` users fare no better (the callback variant at `:353-356` also performs zero accounting).\n\nContrast \u2014 `SimpleAsyncHTTPClient` path (`tornado/http1connection.py`), all absent from the curl path:\n\n```python\nif cast(int, content_length) \u003e self._max_body_size: # :620 Content-Length gate\nif total_size \u003e self._max_body_size: # :676 chunked total gate\nif self._decompressed_body_size \u003e self._max_body_size: # :742 CVE-2026-49855 decompressed gate\n```\n\n`SimpleAsyncHTTPClient.initialize()` defaults `max_buffer_size = 104857600` (100 MiB) with `max_body_size` defaulting to it (`simple_httpclient.py:117-121`); `CurlAsyncHTTPClient.initialize()` has no corresponding parameter at all.\n\nAttack chain (attacker = malicious HTTP server; victim = any Tornado app doing `fetch()` on attacker-influenced URLs \u2014 URL fetchers, webhook processors, link previewers, RSS/probe pollers):\n\n1. App configures `AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` (documented for proxy support; proxies are only supported with the curl client).\n2. App calls `fetch(\"http://attacker/...\")` with defaults \u2192 request advertises `Accept-Encoding: gzip,deflate`.\n3. Attacker replies `200`, `Content-Encoding: gzip`, `Transfer-Encoding: chunked`, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks).\n4. libcurl auto-decodes at ~350 MB/s into `buffer.write` with no size accounting \u2192 process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).\n\nVariant without compression: `decompress_response=False` plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted `buffer.write` \u2014 this client never enforces any cap on any path.\n\n## PoC\n\nVerified end-to-end 2026-08-15 in a single container (cgroup `--memory 1g --memory-swap 1g` so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on `127.0.0.1:8081`: a raw-socket malicious server (`evil_server.py`, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (`victim_curl.py`, configures `CurlAsyncHTTPClient`, `fetch(..., request_timeout=300)`, samples `/proc/self/status` VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).\n\n### Build \u0026 run the victim\n\n```bash\ngit clone https://github.com/tornadoweb/tornado\ncd tornado\npip install pycurl\npython evil_server.py \u0026 # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING\npython victim_curl.py # victim: CurlAsyncHTTPClient fetch -\u003e expect linear RSS rise -\u003e OOM\npython victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb\n```\n\nVerified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot `6.6.dev1` of 2026-08-15 run from the source tree (`sys.path`), container memory capped at 1 GiB. `curl_httpclient.py` verified byte-equivalent (still zero size-limit references) in tag `v6.5.8` and on master as of 2026-08-17.\n\n### Reproduction steps\n\n1. **Precondition \u2014 the documented curl-client deployment fetching a remote URL.** The vulnerability requires the application to use `CurlAsyncHTTPClient` (the standard configuration when proxy support or advanced TLS options are needed) with default `decompress_response=True`, and to fetch a URL whose server the attacker controls or has compromised. `victim_curl.py` implements exactly that (`AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` \u2192 `fetch()`), and the server log confirms the ENCODING path engaged \u2014 the victim\u0027s request arrived with `User-Agent: Mozilla/5.0 (compatible; pycurl)` and `Accept-Encoding: gzip,deflate`.\n\n2. **Attack:** start `evil_server.py`, wait for `EVIL_LISTENING`, then run `victim_curl.py` (the fetch itself is the attack; no further interaction).\n\n3. **Expected:** `victim_curl_rss.log` shows VmRSS 30,884 \u2192 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (`exit 137`, docker `OOMKilled=true`); the server logs `CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525` \u2014 the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered.\n\n4. **Variant:** with `decompress_response=False` and an unterminated chunked body (server keeps sending forever), the same `buffer.write` path accumulates unbounded plain bytes \u2014 no compression needed; `request_timeout` only extends the ceiling.\n\n5. **Control:** `victim_simple.py` fetches the identical bomb with the default `SimpleAsyncHTTPClient` \u2192 clean `FETCH_FAILED: HTTP 599: Connection closed`, RSS peak ~65 MB (24,984 \u2192 66,712 kB), script exit 0 \u2014 the CVE-2026-49855 accounting in `http1connection.py` aborts the transfer, proving the gap is specific to the curl client.\n\n### PoC source\n\nFull PoC source (**victim_curl.py**, stdlib only, no dependencies): [victim_curl.py](https://gist.github.com/afldl/211c0e7af8175c2eabab53ed037c435d) (secret gist, unlisted).\n\n\nThe gist carries `evil_server.py` (bomb server), `victim_curl.py` (victim), `victim_simple.py` (control), and `REPRODUCE.md`.\n\n### Captured output (2026-08-15 run, verbatim excerpts)\n\n```\nevil_server.log:\nBOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1\nEVIL_LISTENING 127.0.0.1:8081\nREQUEST_FROM 127.0.0.1:57544 -\u003e GET /bomb HTTP/1.1\nREQUEST_HEADERS:\nGET /bomb HTTP/1.1\nHost: 127.0.0.1:8081\nUser-Agent: Mozilla/5.0 (compatible; pycurl)\nAccept: */*\nAccept-Encoding: gzip,deflate\nWIRE_SENT 65536/4174525\nWIRE_SENT 2162688/4174525\nCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, \u0027Connection reset by peer\u0027)\n\nvictim_curl_rss.log (VmRSS kB, every 0.2 s):\n0.00 30884\n0.61 231848\n1.41 514720\n2.22 794480\n2.82 1000756\n3.18 1032100 \u003c- last sample before kill\n\ndriver_f1.log:\ntimeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed\nVICTIM_CURL_EXIT=137 # docker inspect -\u003e OomKilled: true\n\nvictim_simple.log (control, same bomb):\nFETCH_FAILED: HTTP 599: Connection closed\nSCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB\n```\n\nHonest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test\u0027s 1 GiB cgroup cap as the observation instrument; the \"unbounded\" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path \u2014 with more memory the transfer would have continued to the full 4 GiB payload.\n\n## Impact\n\nDenial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as `available_memory / 1000`. Because the accumulation happens on the shared event loop\u0027s client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim\u0027s configured client visits the attacker\u0027s origin.\n\n### Suggested fix\n\nEnforce a byte budget in the write path of `CurlAsyncHTTPClient`: wrap the `WRITEFUNCTION` (both the `buffer.write` branch and the `streaming_callback` branch) in a counter that aborts the transfer (`curl.setopt(pycurl.FAILONERROR)`-style cancellation or raising from the callback) once the received total exceeds `max_body_size`, plumbed from `initialize()` with the same 100 MiB default as `SimpleAsyncHTTPClient`. Because libcurl decompresses before the write callback, the counter naturally measures *decompressed* bytes \u2014 the same semantics as the CVE-2026-49855 fix. (`pycurl.MAXFILESIZE` alone is insufficient: it applies to the compressed transfer size.)\n\n### Affected versions\n\n- **\u003c= 6.5.8** (latest tag; the curl client has never had a response-size limit) and master (`6.6.dev1`, verified 2026-08-15/17).\n- 6.5.6\u0027s CVE-2026-49855 fix covered `SimpleAsyncHTTPClient`/`http1connection.py` only; `curl_httpclient.py` was not touched.\n\n## Credit\n\nReported by the diff/ambidiff security research effort (afldl).",
"id": "BREW-jupyterlab-CVE-2026-103262",
"modified": "2026-10-29T22:14:32Z",
"published": "2026-10-06T10:10:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/pull/3719"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/15f056080d8e456f92cca8ad0c33e5a5480414ac"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/6564e0a0922c16f239d3a18adccd04736e380c89"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/aa2eb0d989716ac00fe8d7a9919b81c1eccd6ec4"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9"
},
{
"type": "PACKAGE",
"url": "https://github.com/tornadoweb/tornado"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/releases/tag/v6.5.9"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "tornado: CurlAsyncHTTPClient enforces no response-size limit \u2014 decompression bomb drives unbounded memory accumulation to OOM",
"upstream": [
"GHSA-chx6-46f5-w4vp",
"CVE-2026-103262"
]
}
BREW-LIVERELOAD-GHSA-CHX… (GHSA-CHX6-46F5-W4VP)
Vulnerability from osv_homebrew – Published: 2026-10-01 11:13 – Updated: 2026-10-29 23:27 – Source websiteAn unbounded memory accumulation (decompression bomb) in tornado.curl_httpclient.CurlAsyncHTTPClient — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (6.6.dev1) and present unchanged in the latest release tag v6.5.8 and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and fetch()es an attacker-chosen or attacker-compromised URL with default decompress_response=True, a malicious server replying Content-Encoding: gzip with a ~2.8 MB wire bomb drove the client's RSS from 30,884 kB to 1,032,100 kB (~1008 MB) in 3.18 s (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup OOMKilled=true) — with the transfer only 67% complete and no client-side size check ever intervening: curl_httpclient.py contains zero occurrences of max_body_size/MAXFILESIZE. The identical bomb against the default SimpleAsyncHTTPClient fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size — http1connection.py:620,676,742) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed _GzipMessageDelegate/SimpleAsyncHTTPClient only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file's full commit history (latest 2026-06-17) shows no response-size work.
Details
tornado/curl_httpclient.py (line numbers identical on master 6.6.dev1, v6.5.8, and the audited snapshot):
"buffer": BytesIO(), # :202 — plain BytesIO, no accounting
...
else:
write_function = buffer.write # :359 — every decompressed byte lands here
curl.setopt(pycurl.WRITEFUNCTION, write_function) # :360
...
if request.decompress_response: # default True (HTTPRequest)
curl.setopt(pycurl.ENCODING, "gzip,deflate") # :373-374 — libcurl advertises + auto-decodes
libcurl decompresses the response before invoking WRITEFUNCTION, so the callback receives decompressed bytes, which are appended to an unbounded BytesIO until the transfer ends or the process dies. The only ceiling is request_timeout (default 20 s) — at zlib's hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no pycurl.MAXFILESIZE, no max_buffer_size/max_body_size plumbing (the constructor accepts no body-size option), and streaming_callback users fare no better (the callback variant at :353-356 also performs zero accounting).
Contrast — SimpleAsyncHTTPClient path (tornado/http1connection.py), all absent from the curl path:
if cast(int, content_length) > self._max_body_size: # :620 Content-Length gate
if total_size > self._max_body_size: # :676 chunked total gate
if self._decompressed_body_size > self._max_body_size: # :742 CVE-2026-49855 decompressed gate
SimpleAsyncHTTPClient.initialize() defaults max_buffer_size = 104857600 (100 MiB) with max_body_size defaulting to it (simple_httpclient.py:117-121); CurlAsyncHTTPClient.initialize() has no corresponding parameter at all.
Attack chain (attacker = malicious HTTP server; victim = any Tornado app doing fetch() on attacker-influenced URLs — URL fetchers, webhook processors, link previewers, RSS/probe pollers):
- App configures
AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")(documented for proxy support; proxies are only supported with the curl client). - App calls
fetch("http://attacker/...")with defaults → request advertisesAccept-Encoding: gzip,deflate. - Attacker replies
200,Content-Encoding: gzip,Transfer-Encoding: chunked, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks). - libcurl auto-decodes at ~350 MB/s into
buffer.writewith no size accounting → process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).
Variant without compression: decompress_response=False plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted buffer.write — this client never enforces any cap on any path.
PoC
Verified end-to-end 2026-08-15 in a single container (cgroup --memory 1g --memory-swap 1g so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on 127.0.0.1:8081: a raw-socket malicious server (evil_server.py, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (victim_curl.py, configures CurlAsyncHTTPClient, fetch(..., request_timeout=300), samples /proc/self/status VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).
Build & run the victim
git clone https://github.com/tornadoweb/tornado
cd tornado
pip install pycurl
python evil_server.py & # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING
python victim_curl.py # victim: CurlAsyncHTTPClient fetch -> expect linear RSS rise -> OOM
python victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb
Verified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot 6.6.dev1 of 2026-08-15 run from the source tree (sys.path), container memory capped at 1 GiB. curl_httpclient.py verified byte-equivalent (still zero size-limit references) in tag v6.5.8 and on master as of 2026-08-17.
Reproduction steps
-
Precondition — the documented curl-client deployment fetching a remote URL. The vulnerability requires the application to use
CurlAsyncHTTPClient(the standard configuration when proxy support or advanced TLS options are needed) with defaultdecompress_response=True, and to fetch a URL whose server the attacker controls or has compromised.victim_curl.pyimplements exactly that (AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")→fetch()), and the server log confirms the ENCODING path engaged — the victim's request arrived withUser-Agent: Mozilla/5.0 (compatible; pycurl)andAccept-Encoding: gzip,deflate. -
Attack: start
evil_server.py, wait forEVIL_LISTENING, then runvictim_curl.py(the fetch itself is the attack; no further interaction). -
Expected:
victim_curl_rss.logshows VmRSS 30,884 → 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (exit 137, dockerOOMKilled=true); the server logsCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525— the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered. -
Variant: with
decompress_response=Falseand an unterminated chunked body (server keeps sending forever), the samebuffer.writepath accumulates unbounded plain bytes — no compression needed;request_timeoutonly extends the ceiling. -
Control:
victim_simple.pyfetches the identical bomb with the defaultSimpleAsyncHTTPClient→ cleanFETCH_FAILED: HTTP 599: Connection closed, RSS peak ~65 MB (24,984 → 66,712 kB), script exit 0 — the CVE-2026-49855 accounting inhttp1connection.pyaborts the transfer, proving the gap is specific to the curl client.
PoC source
Full PoC source (victim_curl.py, stdlib only, no dependencies): victim_curl.py (secret gist, unlisted).
The gist carries evil_server.py (bomb server), victim_curl.py (victim), victim_simple.py (control), and REPRODUCE.md.
Captured output (2026-08-15 run, verbatim excerpts)
evil_server.log:
BOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1
EVIL_LISTENING 127.0.0.1:8081
REQUEST_FROM 127.0.0.1:57544 -> GET /bomb HTTP/1.1
REQUEST_HEADERS:
GET /bomb HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (compatible; pycurl)
Accept: */*
Accept-Encoding: gzip,deflate
WIRE_SENT 65536/4174525
WIRE_SENT 2162688/4174525
CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, 'Connection reset by peer')
victim_curl_rss.log (VmRSS kB, every 0.2 s):
0.00 30884
0.61 231848
1.41 514720
2.22 794480
2.82 1000756
3.18 1032100 <- last sample before kill
driver_f1.log:
timeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed
VICTIM_CURL_EXIT=137 # docker inspect -> OomKilled: true
victim_simple.log (control, same bomb):
FETCH_FAILED: HTTP 599: Connection closed
SCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB
Honest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test's 1 GiB cgroup cap as the observation instrument; the "unbounded" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path — with more memory the transfer would have continued to the full 4 GiB payload.
Impact
Denial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as available_memory / 1000. Because the accumulation happens on the shared event loop's client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim's configured client visits the attacker's origin.
Suggested fix
Enforce a byte budget in the write path of CurlAsyncHTTPClient: wrap the WRITEFUNCTION (both the buffer.write branch and the streaming_callback branch) in a counter that aborts the transfer (curl.setopt(pycurl.FAILONERROR)-style cancellation or raising from the callback) once the received total exceeds max_body_size, plumbed from initialize() with the same 100 MiB default as SimpleAsyncHTTPClient. Because libcurl decompresses before the write callback, the counter naturally measures decompressed bytes — the same semantics as the CVE-2026-49855 fix. (pycurl.MAXFILESIZE alone is insufficient: it applies to the compressed transfer size.)
Affected versions
- <= 6.5.8 (latest tag; the curl client has never had a response-size limit) and master (
6.6.dev1, verified 2026-08-15/17). - 6.5.6's CVE-2026-49855 fix covered
SimpleAsyncHTTPClient/http1connection.pyonly;curl_httpclient.pywas not touched.
Credit
Reported by the diff/ambidiff security research effort (afldl).
| URL | Type | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "tornado",
"resource_purl": "pkg:pypi/tornado@6.6",
"upstream_fixed_in": "6.5.9"
},
"package": {
"ecosystem": "Homebrew",
"name": "livereload",
"purl": "pkg:brew/livereload"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.1"
},
{
"fixed": "2.7.1_4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/tornado@6.6",
"name": "tornado",
"resource": "tornado",
"strategy": "registry",
"subject_version": "6.6"
}
]
},
"details": "An unbounded memory accumulation (decompression bomb) in `tornado.curl_httpclient.CurlAsyncHTTPClient` \u2014 the client-side sibling gap of CVE-2026-49855 \u2014 verified end-to-end on the 2026-08-15 master snapshot (`6.6.dev1`) and present unchanged in the latest release tag `v6.5.8` and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and `fetch()`es an attacker-chosen or attacker-compromised URL with default `decompress_response=True`, a malicious server replying `Content-Encoding: gzip` with a ~2.8 MB wire bomb drove the client\u0027s RSS from 30,884 kB to **1,032,100 kB (~1008 MB) in 3.18 s** (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup `OOMKilled=true`) \u2014 with the transfer only 67% complete and **no client-side size check ever intervening**: `curl_httpclient.py` contains zero occurrences of `max_body_size`/`MAXFILESIZE`. The identical bomb against the default `SimpleAsyncHTTPClient` fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size \u2014 `http1connection.py:620,676,742`) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed `_GzipMessageDelegate`/`SimpleAsyncHTTPClient` only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file\u0027s full commit history (latest 2026-06-17) shows no response-size work.\n\n## Details\n\n`tornado/curl_httpclient.py` (line numbers identical on master `6.6.dev1`, `v6.5.8`, and the audited snapshot):\n\n```python\n\"buffer\": BytesIO(), # :202 \u2014 plain BytesIO, no accounting\n...\nelse:\n write_function = buffer.write # :359 \u2014 every decompressed byte lands here\ncurl.setopt(pycurl.WRITEFUNCTION, write_function) # :360\n...\nif request.decompress_response: # default True (HTTPRequest)\n curl.setopt(pycurl.ENCODING, \"gzip,deflate\") # :373-374 \u2014 libcurl advertises + auto-decodes\n```\n\nlibcurl decompresses the response **before** invoking `WRITEFUNCTION`, so the callback receives decompressed bytes, which are appended to an unbounded `BytesIO` until the transfer ends or the process dies. The only ceiling is `request_timeout` (default 20 s) \u2014 at zlib\u0027s hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no `pycurl.MAXFILESIZE`, no `max_buffer_size`/`max_body_size` plumbing (the constructor accepts no body-size option), and `streaming_callback` users fare no better (the callback variant at `:353-356` also performs zero accounting).\n\nContrast \u2014 `SimpleAsyncHTTPClient` path (`tornado/http1connection.py`), all absent from the curl path:\n\n```python\nif cast(int, content_length) \u003e self._max_body_size: # :620 Content-Length gate\nif total_size \u003e self._max_body_size: # :676 chunked total gate\nif self._decompressed_body_size \u003e self._max_body_size: # :742 CVE-2026-49855 decompressed gate\n```\n\n`SimpleAsyncHTTPClient.initialize()` defaults `max_buffer_size = 104857600` (100 MiB) with `max_body_size` defaulting to it (`simple_httpclient.py:117-121`); `CurlAsyncHTTPClient.initialize()` has no corresponding parameter at all.\n\nAttack chain (attacker = malicious HTTP server; victim = any Tornado app doing `fetch()` on attacker-influenced URLs \u2014 URL fetchers, webhook processors, link previewers, RSS/probe pollers):\n\n1. App configures `AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` (documented for proxy support; proxies are only supported with the curl client).\n2. App calls `fetch(\"http://attacker/...\")` with defaults \u2192 request advertises `Accept-Encoding: gzip,deflate`.\n3. Attacker replies `200`, `Content-Encoding: gzip`, `Transfer-Encoding: chunked`, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks).\n4. libcurl auto-decodes at ~350 MB/s into `buffer.write` with no size accounting \u2192 process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).\n\nVariant without compression: `decompress_response=False` plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted `buffer.write` \u2014 this client never enforces any cap on any path.\n\n## PoC\n\nVerified end-to-end 2026-08-15 in a single container (cgroup `--memory 1g --memory-swap 1g` so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on `127.0.0.1:8081`: a raw-socket malicious server (`evil_server.py`, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (`victim_curl.py`, configures `CurlAsyncHTTPClient`, `fetch(..., request_timeout=300)`, samples `/proc/self/status` VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).\n\n### Build \u0026 run the victim\n\n```bash\ngit clone https://github.com/tornadoweb/tornado\ncd tornado\npip install pycurl\npython evil_server.py \u0026 # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING\npython victim_curl.py # victim: CurlAsyncHTTPClient fetch -\u003e expect linear RSS rise -\u003e OOM\npython victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb\n```\n\nVerified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot `6.6.dev1` of 2026-08-15 run from the source tree (`sys.path`), container memory capped at 1 GiB. `curl_httpclient.py` verified byte-equivalent (still zero size-limit references) in tag `v6.5.8` and on master as of 2026-08-17.\n\n### Reproduction steps\n\n1. **Precondition \u2014 the documented curl-client deployment fetching a remote URL.** The vulnerability requires the application to use `CurlAsyncHTTPClient` (the standard configuration when proxy support or advanced TLS options are needed) with default `decompress_response=True`, and to fetch a URL whose server the attacker controls or has compromised. `victim_curl.py` implements exactly that (`AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` \u2192 `fetch()`), and the server log confirms the ENCODING path engaged \u2014 the victim\u0027s request arrived with `User-Agent: Mozilla/5.0 (compatible; pycurl)` and `Accept-Encoding: gzip,deflate`.\n\n2. **Attack:** start `evil_server.py`, wait for `EVIL_LISTENING`, then run `victim_curl.py` (the fetch itself is the attack; no further interaction).\n\n3. **Expected:** `victim_curl_rss.log` shows VmRSS 30,884 \u2192 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (`exit 137`, docker `OOMKilled=true`); the server logs `CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525` \u2014 the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered.\n\n4. **Variant:** with `decompress_response=False` and an unterminated chunked body (server keeps sending forever), the same `buffer.write` path accumulates unbounded plain bytes \u2014 no compression needed; `request_timeout` only extends the ceiling.\n\n5. **Control:** `victim_simple.py` fetches the identical bomb with the default `SimpleAsyncHTTPClient` \u2192 clean `FETCH_FAILED: HTTP 599: Connection closed`, RSS peak ~65 MB (24,984 \u2192 66,712 kB), script exit 0 \u2014 the CVE-2026-49855 accounting in `http1connection.py` aborts the transfer, proving the gap is specific to the curl client.\n\n### PoC source\n\nFull PoC source (**victim_curl.py**, stdlib only, no dependencies): [victim_curl.py](https://gist.github.com/afldl/211c0e7af8175c2eabab53ed037c435d) (secret gist, unlisted).\n\n\nThe gist carries `evil_server.py` (bomb server), `victim_curl.py` (victim), `victim_simple.py` (control), and `REPRODUCE.md`.\n\n### Captured output (2026-08-15 run, verbatim excerpts)\n\n```\nevil_server.log:\nBOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1\nEVIL_LISTENING 127.0.0.1:8081\nREQUEST_FROM 127.0.0.1:57544 -\u003e GET /bomb HTTP/1.1\nREQUEST_HEADERS:\nGET /bomb HTTP/1.1\nHost: 127.0.0.1:8081\nUser-Agent: Mozilla/5.0 (compatible; pycurl)\nAccept: */*\nAccept-Encoding: gzip,deflate\nWIRE_SENT 65536/4174525\nWIRE_SENT 2162688/4174525\nCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, \u0027Connection reset by peer\u0027)\n\nvictim_curl_rss.log (VmRSS kB, every 0.2 s):\n0.00 30884\n0.61 231848\n1.41 514720\n2.22 794480\n2.82 1000756\n3.18 1032100 \u003c- last sample before kill\n\ndriver_f1.log:\ntimeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed\nVICTIM_CURL_EXIT=137 # docker inspect -\u003e OomKilled: true\n\nvictim_simple.log (control, same bomb):\nFETCH_FAILED: HTTP 599: Connection closed\nSCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB\n```\n\nHonest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test\u0027s 1 GiB cgroup cap as the observation instrument; the \"unbounded\" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path \u2014 with more memory the transfer would have continued to the full 4 GiB payload.\n\n## Impact\n\nDenial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as `available_memory / 1000`. Because the accumulation happens on the shared event loop\u0027s client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim\u0027s configured client visits the attacker\u0027s origin.\n\n### Suggested fix\n\nEnforce a byte budget in the write path of `CurlAsyncHTTPClient`: wrap the `WRITEFUNCTION` (both the `buffer.write` branch and the `streaming_callback` branch) in a counter that aborts the transfer (`curl.setopt(pycurl.FAILONERROR)`-style cancellation or raising from the callback) once the received total exceeds `max_body_size`, plumbed from `initialize()` with the same 100 MiB default as `SimpleAsyncHTTPClient`. Because libcurl decompresses before the write callback, the counter naturally measures *decompressed* bytes \u2014 the same semantics as the CVE-2026-49855 fix. (`pycurl.MAXFILESIZE` alone is insufficient: it applies to the compressed transfer size.)\n\n### Affected versions\n\n- **\u003c= 6.5.8** (latest tag; the curl client has never had a response-size limit) and master (`6.6.dev1`, verified 2026-08-15/17).\n- 6.5.6\u0027s CVE-2026-49855 fix covered `SimpleAsyncHTTPClient`/`http1connection.py` only; `curl_httpclient.py` was not touched.\n\n## Credit\n\nReported by the diff/ambidiff security research effort (afldl).",
"id": "BREW-livereload-GHSA-chx6-46f5-w4vp",
"modified": "2026-10-29T23:27:22Z",
"published": "2026-10-01T11:13:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/pull/3719"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/15f056080d8e456f92cca8ad0c33e5a5480414ac"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/6564e0a0922c16f239d3a18adccd04736e380c89"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/aa2eb0d989716ac00fe8d7a9919b81c1eccd6ec4"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9"
},
{
"type": "PACKAGE",
"url": "https://github.com/tornadoweb/tornado"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/releases/tag/v6.5.9"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "tornado: CurlAsyncHTTPClient enforces no response-size limit \u2014 decompression bomb drives unbounded memory accumulation to OOM",
"upstream": [
"GHSA-chx6-46f5-w4vp",
"CVE-2026-103262"
]
}
BREW-NVCHECKER-GHSA-CHX6… (GHSA-CHX6-46F5-W4VP)
Vulnerability from osv_homebrew – Published: 2026-10-01 09:49 – Updated: 2026-10-29 21:41 – Source websiteAn unbounded memory accumulation (decompression bomb) in tornado.curl_httpclient.CurlAsyncHTTPClient — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (6.6.dev1) and present unchanged in the latest release tag v6.5.8 and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and fetch()es an attacker-chosen or attacker-compromised URL with default decompress_response=True, a malicious server replying Content-Encoding: gzip with a ~2.8 MB wire bomb drove the client's RSS from 30,884 kB to 1,032,100 kB (~1008 MB) in 3.18 s (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup OOMKilled=true) — with the transfer only 67% complete and no client-side size check ever intervening: curl_httpclient.py contains zero occurrences of max_body_size/MAXFILESIZE. The identical bomb against the default SimpleAsyncHTTPClient fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size — http1connection.py:620,676,742) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed _GzipMessageDelegate/SimpleAsyncHTTPClient only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file's full commit history (latest 2026-06-17) shows no response-size work.
Details
tornado/curl_httpclient.py (line numbers identical on master 6.6.dev1, v6.5.8, and the audited snapshot):
"buffer": BytesIO(), # :202 — plain BytesIO, no accounting
...
else:
write_function = buffer.write # :359 — every decompressed byte lands here
curl.setopt(pycurl.WRITEFUNCTION, write_function) # :360
...
if request.decompress_response: # default True (HTTPRequest)
curl.setopt(pycurl.ENCODING, "gzip,deflate") # :373-374 — libcurl advertises + auto-decodes
libcurl decompresses the response before invoking WRITEFUNCTION, so the callback receives decompressed bytes, which are appended to an unbounded BytesIO until the transfer ends or the process dies. The only ceiling is request_timeout (default 20 s) — at zlib's hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no pycurl.MAXFILESIZE, no max_buffer_size/max_body_size plumbing (the constructor accepts no body-size option), and streaming_callback users fare no better (the callback variant at :353-356 also performs zero accounting).
Contrast — SimpleAsyncHTTPClient path (tornado/http1connection.py), all absent from the curl path:
if cast(int, content_length) > self._max_body_size: # :620 Content-Length gate
if total_size > self._max_body_size: # :676 chunked total gate
if self._decompressed_body_size > self._max_body_size: # :742 CVE-2026-49855 decompressed gate
SimpleAsyncHTTPClient.initialize() defaults max_buffer_size = 104857600 (100 MiB) with max_body_size defaulting to it (simple_httpclient.py:117-121); CurlAsyncHTTPClient.initialize() has no corresponding parameter at all.
Attack chain (attacker = malicious HTTP server; victim = any Tornado app doing fetch() on attacker-influenced URLs — URL fetchers, webhook processors, link previewers, RSS/probe pollers):
- App configures
AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")(documented for proxy support; proxies are only supported with the curl client). - App calls
fetch("http://attacker/...")with defaults → request advertisesAccept-Encoding: gzip,deflate. - Attacker replies
200,Content-Encoding: gzip,Transfer-Encoding: chunked, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks). - libcurl auto-decodes at ~350 MB/s into
buffer.writewith no size accounting → process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).
Variant without compression: decompress_response=False plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted buffer.write — this client never enforces any cap on any path.
PoC
Verified end-to-end 2026-08-15 in a single container (cgroup --memory 1g --memory-swap 1g so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on 127.0.0.1:8081: a raw-socket malicious server (evil_server.py, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (victim_curl.py, configures CurlAsyncHTTPClient, fetch(..., request_timeout=300), samples /proc/self/status VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).
Build & run the victim
git clone https://github.com/tornadoweb/tornado
cd tornado
pip install pycurl
python evil_server.py & # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING
python victim_curl.py # victim: CurlAsyncHTTPClient fetch -> expect linear RSS rise -> OOM
python victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb
Verified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot 6.6.dev1 of 2026-08-15 run from the source tree (sys.path), container memory capped at 1 GiB. curl_httpclient.py verified byte-equivalent (still zero size-limit references) in tag v6.5.8 and on master as of 2026-08-17.
Reproduction steps
-
Precondition — the documented curl-client deployment fetching a remote URL. The vulnerability requires the application to use
CurlAsyncHTTPClient(the standard configuration when proxy support or advanced TLS options are needed) with defaultdecompress_response=True, and to fetch a URL whose server the attacker controls or has compromised.victim_curl.pyimplements exactly that (AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")→fetch()), and the server log confirms the ENCODING path engaged — the victim's request arrived withUser-Agent: Mozilla/5.0 (compatible; pycurl)andAccept-Encoding: gzip,deflate. -
Attack: start
evil_server.py, wait forEVIL_LISTENING, then runvictim_curl.py(the fetch itself is the attack; no further interaction). -
Expected:
victim_curl_rss.logshows VmRSS 30,884 → 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (exit 137, dockerOOMKilled=true); the server logsCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525— the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered. -
Variant: with
decompress_response=Falseand an unterminated chunked body (server keeps sending forever), the samebuffer.writepath accumulates unbounded plain bytes — no compression needed;request_timeoutonly extends the ceiling. -
Control:
victim_simple.pyfetches the identical bomb with the defaultSimpleAsyncHTTPClient→ cleanFETCH_FAILED: HTTP 599: Connection closed, RSS peak ~65 MB (24,984 → 66,712 kB), script exit 0 — the CVE-2026-49855 accounting inhttp1connection.pyaborts the transfer, proving the gap is specific to the curl client.
PoC source
Full PoC source (victim_curl.py, stdlib only, no dependencies): victim_curl.py (secret gist, unlisted).
The gist carries evil_server.py (bomb server), victim_curl.py (victim), victim_simple.py (control), and REPRODUCE.md.
Captured output (2026-08-15 run, verbatim excerpts)
evil_server.log:
BOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1
EVIL_LISTENING 127.0.0.1:8081
REQUEST_FROM 127.0.0.1:57544 -> GET /bomb HTTP/1.1
REQUEST_HEADERS:
GET /bomb HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (compatible; pycurl)
Accept: */*
Accept-Encoding: gzip,deflate
WIRE_SENT 65536/4174525
WIRE_SENT 2162688/4174525
CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, 'Connection reset by peer')
victim_curl_rss.log (VmRSS kB, every 0.2 s):
0.00 30884
0.61 231848
1.41 514720
2.22 794480
2.82 1000756
3.18 1032100 <- last sample before kill
driver_f1.log:
timeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed
VICTIM_CURL_EXIT=137 # docker inspect -> OomKilled: true
victim_simple.log (control, same bomb):
FETCH_FAILED: HTTP 599: Connection closed
SCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB
Honest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test's 1 GiB cgroup cap as the observation instrument; the "unbounded" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path — with more memory the transfer would have continued to the full 4 GiB payload.
Impact
Denial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as available_memory / 1000. Because the accumulation happens on the shared event loop's client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim's configured client visits the attacker's origin.
Suggested fix
Enforce a byte budget in the write path of CurlAsyncHTTPClient: wrap the WRITEFUNCTION (both the buffer.write branch and the streaming_callback branch) in a counter that aborts the transfer (curl.setopt(pycurl.FAILONERROR)-style cancellation or raising from the callback) once the received total exceeds max_body_size, plumbed from initialize() with the same 100 MiB default as SimpleAsyncHTTPClient. Because libcurl decompresses before the write callback, the counter naturally measures decompressed bytes — the same semantics as the CVE-2026-49855 fix. (pycurl.MAXFILESIZE alone is insufficient: it applies to the compressed transfer size.)
Affected versions
- <= 6.5.8 (latest tag; the curl client has never had a response-size limit) and master (
6.6.dev1, verified 2026-08-15/17). - 6.5.6's CVE-2026-49855 fix covered
SimpleAsyncHTTPClient/http1connection.pyonly;curl_httpclient.pywas not touched.
Credit
Reported by the diff/ambidiff security research effort (afldl).
| URL | Type | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "tornado",
"resource_purl": "pkg:pypi/tornado@6.6",
"upstream_fixed_in": "6.5.9"
},
"package": {
"ecosystem": "Homebrew",
"name": "nvchecker",
"purl": "pkg:brew/nvchecker"
},
"ranges": [
{
"events": [
{
"introduced": "2.7"
},
{
"fixed": "2.22_1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/tornado@6.6",
"name": "tornado",
"resource": "tornado",
"strategy": "registry",
"subject_version": "6.6"
}
]
},
"details": "An unbounded memory accumulation (decompression bomb) in `tornado.curl_httpclient.CurlAsyncHTTPClient` \u2014 the client-side sibling gap of CVE-2026-49855 \u2014 verified end-to-end on the 2026-08-15 master snapshot (`6.6.dev1`) and present unchanged in the latest release tag `v6.5.8` and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and `fetch()`es an attacker-chosen or attacker-compromised URL with default `decompress_response=True`, a malicious server replying `Content-Encoding: gzip` with a ~2.8 MB wire bomb drove the client\u0027s RSS from 30,884 kB to **1,032,100 kB (~1008 MB) in 3.18 s** (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup `OOMKilled=true`) \u2014 with the transfer only 67% complete and **no client-side size check ever intervening**: `curl_httpclient.py` contains zero occurrences of `max_body_size`/`MAXFILESIZE`. The identical bomb against the default `SimpleAsyncHTTPClient` fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size \u2014 `http1connection.py:620,676,742`) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed `_GzipMessageDelegate`/`SimpleAsyncHTTPClient` only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file\u0027s full commit history (latest 2026-06-17) shows no response-size work.\n\n## Details\n\n`tornado/curl_httpclient.py` (line numbers identical on master `6.6.dev1`, `v6.5.8`, and the audited snapshot):\n\n```python\n\"buffer\": BytesIO(), # :202 \u2014 plain BytesIO, no accounting\n...\nelse:\n write_function = buffer.write # :359 \u2014 every decompressed byte lands here\ncurl.setopt(pycurl.WRITEFUNCTION, write_function) # :360\n...\nif request.decompress_response: # default True (HTTPRequest)\n curl.setopt(pycurl.ENCODING, \"gzip,deflate\") # :373-374 \u2014 libcurl advertises + auto-decodes\n```\n\nlibcurl decompresses the response **before** invoking `WRITEFUNCTION`, so the callback receives decompressed bytes, which are appended to an unbounded `BytesIO` until the transfer ends or the process dies. The only ceiling is `request_timeout` (default 20 s) \u2014 at zlib\u0027s hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no `pycurl.MAXFILESIZE`, no `max_buffer_size`/`max_body_size` plumbing (the constructor accepts no body-size option), and `streaming_callback` users fare no better (the callback variant at `:353-356` also performs zero accounting).\n\nContrast \u2014 `SimpleAsyncHTTPClient` path (`tornado/http1connection.py`), all absent from the curl path:\n\n```python\nif cast(int, content_length) \u003e self._max_body_size: # :620 Content-Length gate\nif total_size \u003e self._max_body_size: # :676 chunked total gate\nif self._decompressed_body_size \u003e self._max_body_size: # :742 CVE-2026-49855 decompressed gate\n```\n\n`SimpleAsyncHTTPClient.initialize()` defaults `max_buffer_size = 104857600` (100 MiB) with `max_body_size` defaulting to it (`simple_httpclient.py:117-121`); `CurlAsyncHTTPClient.initialize()` has no corresponding parameter at all.\n\nAttack chain (attacker = malicious HTTP server; victim = any Tornado app doing `fetch()` on attacker-influenced URLs \u2014 URL fetchers, webhook processors, link previewers, RSS/probe pollers):\n\n1. App configures `AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` (documented for proxy support; proxies are only supported with the curl client).\n2. App calls `fetch(\"http://attacker/...\")` with defaults \u2192 request advertises `Accept-Encoding: gzip,deflate`.\n3. Attacker replies `200`, `Content-Encoding: gzip`, `Transfer-Encoding: chunked`, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks).\n4. libcurl auto-decodes at ~350 MB/s into `buffer.write` with no size accounting \u2192 process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).\n\nVariant without compression: `decompress_response=False` plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted `buffer.write` \u2014 this client never enforces any cap on any path.\n\n## PoC\n\nVerified end-to-end 2026-08-15 in a single container (cgroup `--memory 1g --memory-swap 1g` so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on `127.0.0.1:8081`: a raw-socket malicious server (`evil_server.py`, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (`victim_curl.py`, configures `CurlAsyncHTTPClient`, `fetch(..., request_timeout=300)`, samples `/proc/self/status` VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).\n\n### Build \u0026 run the victim\n\n```bash\ngit clone https://github.com/tornadoweb/tornado\ncd tornado\npip install pycurl\npython evil_server.py \u0026 # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING\npython victim_curl.py # victim: CurlAsyncHTTPClient fetch -\u003e expect linear RSS rise -\u003e OOM\npython victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb\n```\n\nVerified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot `6.6.dev1` of 2026-08-15 run from the source tree (`sys.path`), container memory capped at 1 GiB. `curl_httpclient.py` verified byte-equivalent (still zero size-limit references) in tag `v6.5.8` and on master as of 2026-08-17.\n\n### Reproduction steps\n\n1. **Precondition \u2014 the documented curl-client deployment fetching a remote URL.** The vulnerability requires the application to use `CurlAsyncHTTPClient` (the standard configuration when proxy support or advanced TLS options are needed) with default `decompress_response=True`, and to fetch a URL whose server the attacker controls or has compromised. `victim_curl.py` implements exactly that (`AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` \u2192 `fetch()`), and the server log confirms the ENCODING path engaged \u2014 the victim\u0027s request arrived with `User-Agent: Mozilla/5.0 (compatible; pycurl)` and `Accept-Encoding: gzip,deflate`.\n\n2. **Attack:** start `evil_server.py`, wait for `EVIL_LISTENING`, then run `victim_curl.py` (the fetch itself is the attack; no further interaction).\n\n3. **Expected:** `victim_curl_rss.log` shows VmRSS 30,884 \u2192 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (`exit 137`, docker `OOMKilled=true`); the server logs `CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525` \u2014 the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered.\n\n4. **Variant:** with `decompress_response=False` and an unterminated chunked body (server keeps sending forever), the same `buffer.write` path accumulates unbounded plain bytes \u2014 no compression needed; `request_timeout` only extends the ceiling.\n\n5. **Control:** `victim_simple.py` fetches the identical bomb with the default `SimpleAsyncHTTPClient` \u2192 clean `FETCH_FAILED: HTTP 599: Connection closed`, RSS peak ~65 MB (24,984 \u2192 66,712 kB), script exit 0 \u2014 the CVE-2026-49855 accounting in `http1connection.py` aborts the transfer, proving the gap is specific to the curl client.\n\n### PoC source\n\nFull PoC source (**victim_curl.py**, stdlib only, no dependencies): [victim_curl.py](https://gist.github.com/afldl/211c0e7af8175c2eabab53ed037c435d) (secret gist, unlisted).\n\n\nThe gist carries `evil_server.py` (bomb server), `victim_curl.py` (victim), `victim_simple.py` (control), and `REPRODUCE.md`.\n\n### Captured output (2026-08-15 run, verbatim excerpts)\n\n```\nevil_server.log:\nBOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1\nEVIL_LISTENING 127.0.0.1:8081\nREQUEST_FROM 127.0.0.1:57544 -\u003e GET /bomb HTTP/1.1\nREQUEST_HEADERS:\nGET /bomb HTTP/1.1\nHost: 127.0.0.1:8081\nUser-Agent: Mozilla/5.0 (compatible; pycurl)\nAccept: */*\nAccept-Encoding: gzip,deflate\nWIRE_SENT 65536/4174525\nWIRE_SENT 2162688/4174525\nCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, \u0027Connection reset by peer\u0027)\n\nvictim_curl_rss.log (VmRSS kB, every 0.2 s):\n0.00 30884\n0.61 231848\n1.41 514720\n2.22 794480\n2.82 1000756\n3.18 1032100 \u003c- last sample before kill\n\ndriver_f1.log:\ntimeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed\nVICTIM_CURL_EXIT=137 # docker inspect -\u003e OomKilled: true\n\nvictim_simple.log (control, same bomb):\nFETCH_FAILED: HTTP 599: Connection closed\nSCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB\n```\n\nHonest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test\u0027s 1 GiB cgroup cap as the observation instrument; the \"unbounded\" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path \u2014 with more memory the transfer would have continued to the full 4 GiB payload.\n\n## Impact\n\nDenial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as `available_memory / 1000`. Because the accumulation happens on the shared event loop\u0027s client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim\u0027s configured client visits the attacker\u0027s origin.\n\n### Suggested fix\n\nEnforce a byte budget in the write path of `CurlAsyncHTTPClient`: wrap the `WRITEFUNCTION` (both the `buffer.write` branch and the `streaming_callback` branch) in a counter that aborts the transfer (`curl.setopt(pycurl.FAILONERROR)`-style cancellation or raising from the callback) once the received total exceeds `max_body_size`, plumbed from `initialize()` with the same 100 MiB default as `SimpleAsyncHTTPClient`. Because libcurl decompresses before the write callback, the counter naturally measures *decompressed* bytes \u2014 the same semantics as the CVE-2026-49855 fix. (`pycurl.MAXFILESIZE` alone is insufficient: it applies to the compressed transfer size.)\n\n### Affected versions\n\n- **\u003c= 6.5.8** (latest tag; the curl client has never had a response-size limit) and master (`6.6.dev1`, verified 2026-08-15/17).\n- 6.5.6\u0027s CVE-2026-49855 fix covered `SimpleAsyncHTTPClient`/`http1connection.py` only; `curl_httpclient.py` was not touched.\n\n## Credit\n\nReported by the diff/ambidiff security research effort (afldl).",
"id": "BREW-nvchecker-GHSA-chx6-46f5-w4vp",
"modified": "2026-10-29T21:41:23Z",
"published": "2026-10-01T09:49:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/pull/3719"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/15f056080d8e456f92cca8ad0c33e5a5480414ac"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/6564e0a0922c16f239d3a18adccd04736e380c89"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/aa2eb0d989716ac00fe8d7a9919b81c1eccd6ec4"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9"
},
{
"type": "PACKAGE",
"url": "https://github.com/tornadoweb/tornado"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/releases/tag/v6.5.9"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "tornado: CurlAsyncHTTPClient enforces no response-size limit \u2014 decompression bomb drives unbounded memory accumulation to OOM",
"upstream": [
"GHSA-chx6-46f5-w4vp",
"CVE-2026-103262"
]
}
BREW-SICKCHILL-GHSA-CHX6… (GHSA-CHX6-46F5-W4VP)
Vulnerability from osv_homebrew – Published: 2026-10-01 09:53 – Updated: 2026-11-13 09:11 – Source websiteAn unbounded memory accumulation (decompression bomb) in tornado.curl_httpclient.CurlAsyncHTTPClient — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (6.6.dev1) and present unchanged in the latest release tag v6.5.8 and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and fetch()es an attacker-chosen or attacker-compromised URL with default decompress_response=True, a malicious server replying Content-Encoding: gzip with a ~2.8 MB wire bomb drove the client's RSS from 30,884 kB to 1,032,100 kB (~1008 MB) in 3.18 s (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup OOMKilled=true) — with the transfer only 67% complete and no client-side size check ever intervening: curl_httpclient.py contains zero occurrences of max_body_size/MAXFILESIZE. The identical bomb against the default SimpleAsyncHTTPClient fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size — http1connection.py:620,676,742) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed _GzipMessageDelegate/SimpleAsyncHTTPClient only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file's full commit history (latest 2026-06-17) shows no response-size work.
Details
tornado/curl_httpclient.py (line numbers identical on master 6.6.dev1, v6.5.8, and the audited snapshot):
"buffer": BytesIO(), # :202 — plain BytesIO, no accounting
...
else:
write_function = buffer.write # :359 — every decompressed byte lands here
curl.setopt(pycurl.WRITEFUNCTION, write_function) # :360
...
if request.decompress_response: # default True (HTTPRequest)
curl.setopt(pycurl.ENCODING, "gzip,deflate") # :373-374 — libcurl advertises + auto-decodes
libcurl decompresses the response before invoking WRITEFUNCTION, so the callback receives decompressed bytes, which are appended to an unbounded BytesIO until the transfer ends or the process dies. The only ceiling is request_timeout (default 20 s) — at zlib's hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no pycurl.MAXFILESIZE, no max_buffer_size/max_body_size plumbing (the constructor accepts no body-size option), and streaming_callback users fare no better (the callback variant at :353-356 also performs zero accounting).
Contrast — SimpleAsyncHTTPClient path (tornado/http1connection.py), all absent from the curl path:
if cast(int, content_length) > self._max_body_size: # :620 Content-Length gate
if total_size > self._max_body_size: # :676 chunked total gate
if self._decompressed_body_size > self._max_body_size: # :742 CVE-2026-49855 decompressed gate
SimpleAsyncHTTPClient.initialize() defaults max_buffer_size = 104857600 (100 MiB) with max_body_size defaulting to it (simple_httpclient.py:117-121); CurlAsyncHTTPClient.initialize() has no corresponding parameter at all.
Attack chain (attacker = malicious HTTP server; victim = any Tornado app doing fetch() on attacker-influenced URLs — URL fetchers, webhook processors, link previewers, RSS/probe pollers):
- App configures
AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")(documented for proxy support; proxies are only supported with the curl client). - App calls
fetch("http://attacker/...")with defaults → request advertisesAccept-Encoding: gzip,deflate. - Attacker replies
200,Content-Encoding: gzip,Transfer-Encoding: chunked, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks). - libcurl auto-decodes at ~350 MB/s into
buffer.writewith no size accounting → process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).
Variant without compression: decompress_response=False plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted buffer.write — this client never enforces any cap on any path.
PoC
Verified end-to-end 2026-08-15 in a single container (cgroup --memory 1g --memory-swap 1g so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on 127.0.0.1:8081: a raw-socket malicious server (evil_server.py, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (victim_curl.py, configures CurlAsyncHTTPClient, fetch(..., request_timeout=300), samples /proc/self/status VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).
Build & run the victim
git clone https://github.com/tornadoweb/tornado
cd tornado
pip install pycurl
python evil_server.py & # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING
python victim_curl.py # victim: CurlAsyncHTTPClient fetch -> expect linear RSS rise -> OOM
python victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb
Verified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot 6.6.dev1 of 2026-08-15 run from the source tree (sys.path), container memory capped at 1 GiB. curl_httpclient.py verified byte-equivalent (still zero size-limit references) in tag v6.5.8 and on master as of 2026-08-17.
Reproduction steps
-
Precondition — the documented curl-client deployment fetching a remote URL. The vulnerability requires the application to use
CurlAsyncHTTPClient(the standard configuration when proxy support or advanced TLS options are needed) with defaultdecompress_response=True, and to fetch a URL whose server the attacker controls or has compromised.victim_curl.pyimplements exactly that (AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")→fetch()), and the server log confirms the ENCODING path engaged — the victim's request arrived withUser-Agent: Mozilla/5.0 (compatible; pycurl)andAccept-Encoding: gzip,deflate. -
Attack: start
evil_server.py, wait forEVIL_LISTENING, then runvictim_curl.py(the fetch itself is the attack; no further interaction). -
Expected:
victim_curl_rss.logshows VmRSS 30,884 → 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (exit 137, dockerOOMKilled=true); the server logsCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525— the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered. -
Variant: with
decompress_response=Falseand an unterminated chunked body (server keeps sending forever), the samebuffer.writepath accumulates unbounded plain bytes — no compression needed;request_timeoutonly extends the ceiling. -
Control:
victim_simple.pyfetches the identical bomb with the defaultSimpleAsyncHTTPClient→ cleanFETCH_FAILED: HTTP 599: Connection closed, RSS peak ~65 MB (24,984 → 66,712 kB), script exit 0 — the CVE-2026-49855 accounting inhttp1connection.pyaborts the transfer, proving the gap is specific to the curl client.
PoC source
Full PoC source (victim_curl.py, stdlib only, no dependencies): victim_curl.py (secret gist, unlisted).
The gist carries evil_server.py (bomb server), victim_curl.py (victim), victim_simple.py (control), and REPRODUCE.md.
Captured output (2026-08-15 run, verbatim excerpts)
evil_server.log:
BOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1
EVIL_LISTENING 127.0.0.1:8081
REQUEST_FROM 127.0.0.1:57544 -> GET /bomb HTTP/1.1
REQUEST_HEADERS:
GET /bomb HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (compatible; pycurl)
Accept: */*
Accept-Encoding: gzip,deflate
WIRE_SENT 65536/4174525
WIRE_SENT 2162688/4174525
CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, 'Connection reset by peer')
victim_curl_rss.log (VmRSS kB, every 0.2 s):
0.00 30884
0.61 231848
1.41 514720
2.22 794480
2.82 1000756
3.18 1032100 <- last sample before kill
driver_f1.log:
timeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed
VICTIM_CURL_EXIT=137 # docker inspect -> OomKilled: true
victim_simple.log (control, same bomb):
FETCH_FAILED: HTTP 599: Connection closed
SCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB
Honest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test's 1 GiB cgroup cap as the observation instrument; the "unbounded" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path — with more memory the transfer would have continued to the full 4 GiB payload.
Impact
Denial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as available_memory / 1000. Because the accumulation happens on the shared event loop's client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim's configured client visits the attacker's origin.
Suggested fix
Enforce a byte budget in the write path of CurlAsyncHTTPClient: wrap the WRITEFUNCTION (both the buffer.write branch and the streaming_callback branch) in a counter that aborts the transfer (curl.setopt(pycurl.FAILONERROR)-style cancellation or raising from the callback) once the received total exceeds max_body_size, plumbed from initialize() with the same 100 MiB default as SimpleAsyncHTTPClient. Because libcurl decompresses before the write callback, the counter naturally measures decompressed bytes — the same semantics as the CVE-2026-49855 fix. (pycurl.MAXFILESIZE alone is insufficient: it applies to the compressed transfer size.)
Affected versions
- <= 6.5.8 (latest tag; the curl client has never had a response-size limit) and master (
6.6.dev1, verified 2026-08-15/17). - 6.5.6's CVE-2026-49855 fix covered
SimpleAsyncHTTPClient/http1connection.pyonly;curl_httpclient.pywas not touched.
Credit
Reported by the diff/ambidiff security research effort (afldl).
| URL | Type | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "tornado",
"resource_purl": "pkg:pypi/tornado@6.6.1",
"upstream_fixed_in": "6.5.9"
},
"package": {
"ecosystem": "Homebrew",
"name": "sickchill",
"purl": "pkg:brew/sickchill"
},
"ranges": [
{
"events": [
{
"introduced": "2023.5.30"
},
{
"fixed": "2024.3.1_9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/tornado@6.6.1",
"name": "tornado",
"resource": "tornado",
"strategy": "registry",
"subject_version": "6.6.1"
}
]
},
"details": "An unbounded memory accumulation (decompression bomb) in `tornado.curl_httpclient.CurlAsyncHTTPClient` \u2014 the client-side sibling gap of CVE-2026-49855 \u2014 verified end-to-end on the 2026-08-15 master snapshot (`6.6.dev1`) and present unchanged in the latest release tag `v6.5.8` and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and `fetch()`es an attacker-chosen or attacker-compromised URL with default `decompress_response=True`, a malicious server replying `Content-Encoding: gzip` with a ~2.8 MB wire bomb drove the client\u0027s RSS from 30,884 kB to **1,032,100 kB (~1008 MB) in 3.18 s** (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup `OOMKilled=true`) \u2014 with the transfer only 67% complete and **no client-side size check ever intervening**: `curl_httpclient.py` contains zero occurrences of `max_body_size`/`MAXFILESIZE`. The identical bomb against the default `SimpleAsyncHTTPClient` fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size \u2014 `http1connection.py:620,676,742`) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed `_GzipMessageDelegate`/`SimpleAsyncHTTPClient` only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file\u0027s full commit history (latest 2026-06-17) shows no response-size work.\n\n## Details\n\n`tornado/curl_httpclient.py` (line numbers identical on master `6.6.dev1`, `v6.5.8`, and the audited snapshot):\n\n```python\n\"buffer\": BytesIO(), # :202 \u2014 plain BytesIO, no accounting\n...\nelse:\n write_function = buffer.write # :359 \u2014 every decompressed byte lands here\ncurl.setopt(pycurl.WRITEFUNCTION, write_function) # :360\n...\nif request.decompress_response: # default True (HTTPRequest)\n curl.setopt(pycurl.ENCODING, \"gzip,deflate\") # :373-374 \u2014 libcurl advertises + auto-decodes\n```\n\nlibcurl decompresses the response **before** invoking `WRITEFUNCTION`, so the callback receives decompressed bytes, which are appended to an unbounded `BytesIO` until the transfer ends or the process dies. The only ceiling is `request_timeout` (default 20 s) \u2014 at zlib\u0027s hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no `pycurl.MAXFILESIZE`, no `max_buffer_size`/`max_body_size` plumbing (the constructor accepts no body-size option), and `streaming_callback` users fare no better (the callback variant at `:353-356` also performs zero accounting).\n\nContrast \u2014 `SimpleAsyncHTTPClient` path (`tornado/http1connection.py`), all absent from the curl path:\n\n```python\nif cast(int, content_length) \u003e self._max_body_size: # :620 Content-Length gate\nif total_size \u003e self._max_body_size: # :676 chunked total gate\nif self._decompressed_body_size \u003e self._max_body_size: # :742 CVE-2026-49855 decompressed gate\n```\n\n`SimpleAsyncHTTPClient.initialize()` defaults `max_buffer_size = 104857600` (100 MiB) with `max_body_size` defaulting to it (`simple_httpclient.py:117-121`); `CurlAsyncHTTPClient.initialize()` has no corresponding parameter at all.\n\nAttack chain (attacker = malicious HTTP server; victim = any Tornado app doing `fetch()` on attacker-influenced URLs \u2014 URL fetchers, webhook processors, link previewers, RSS/probe pollers):\n\n1. App configures `AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` (documented for proxy support; proxies are only supported with the curl client).\n2. App calls `fetch(\"http://attacker/...\")` with defaults \u2192 request advertises `Accept-Encoding: gzip,deflate`.\n3. Attacker replies `200`, `Content-Encoding: gzip`, `Transfer-Encoding: chunked`, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks).\n4. libcurl auto-decodes at ~350 MB/s into `buffer.write` with no size accounting \u2192 process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).\n\nVariant without compression: `decompress_response=False` plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted `buffer.write` \u2014 this client never enforces any cap on any path.\n\n## PoC\n\nVerified end-to-end 2026-08-15 in a single container (cgroup `--memory 1g --memory-swap 1g` so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on `127.0.0.1:8081`: a raw-socket malicious server (`evil_server.py`, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (`victim_curl.py`, configures `CurlAsyncHTTPClient`, `fetch(..., request_timeout=300)`, samples `/proc/self/status` VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).\n\n### Build \u0026 run the victim\n\n```bash\ngit clone https://github.com/tornadoweb/tornado\ncd tornado\npip install pycurl\npython evil_server.py \u0026 # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING\npython victim_curl.py # victim: CurlAsyncHTTPClient fetch -\u003e expect linear RSS rise -\u003e OOM\npython victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb\n```\n\nVerified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot `6.6.dev1` of 2026-08-15 run from the source tree (`sys.path`), container memory capped at 1 GiB. `curl_httpclient.py` verified byte-equivalent (still zero size-limit references) in tag `v6.5.8` and on master as of 2026-08-17.\n\n### Reproduction steps\n\n1. **Precondition \u2014 the documented curl-client deployment fetching a remote URL.** The vulnerability requires the application to use `CurlAsyncHTTPClient` (the standard configuration when proxy support or advanced TLS options are needed) with default `decompress_response=True`, and to fetch a URL whose server the attacker controls or has compromised. `victim_curl.py` implements exactly that (`AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` \u2192 `fetch()`), and the server log confirms the ENCODING path engaged \u2014 the victim\u0027s request arrived with `User-Agent: Mozilla/5.0 (compatible; pycurl)` and `Accept-Encoding: gzip,deflate`.\n\n2. **Attack:** start `evil_server.py`, wait for `EVIL_LISTENING`, then run `victim_curl.py` (the fetch itself is the attack; no further interaction).\n\n3. **Expected:** `victim_curl_rss.log` shows VmRSS 30,884 \u2192 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (`exit 137`, docker `OOMKilled=true`); the server logs `CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525` \u2014 the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered.\n\n4. **Variant:** with `decompress_response=False` and an unterminated chunked body (server keeps sending forever), the same `buffer.write` path accumulates unbounded plain bytes \u2014 no compression needed; `request_timeout` only extends the ceiling.\n\n5. **Control:** `victim_simple.py` fetches the identical bomb with the default `SimpleAsyncHTTPClient` \u2192 clean `FETCH_FAILED: HTTP 599: Connection closed`, RSS peak ~65 MB (24,984 \u2192 66,712 kB), script exit 0 \u2014 the CVE-2026-49855 accounting in `http1connection.py` aborts the transfer, proving the gap is specific to the curl client.\n\n### PoC source\n\nFull PoC source (**victim_curl.py**, stdlib only, no dependencies): [victim_curl.py](https://gist.github.com/afldl/211c0e7af8175c2eabab53ed037c435d) (secret gist, unlisted).\n\n\nThe gist carries `evil_server.py` (bomb server), `victim_curl.py` (victim), `victim_simple.py` (control), and `REPRODUCE.md`.\n\n### Captured output (2026-08-15 run, verbatim excerpts)\n\n```\nevil_server.log:\nBOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1\nEVIL_LISTENING 127.0.0.1:8081\nREQUEST_FROM 127.0.0.1:57544 -\u003e GET /bomb HTTP/1.1\nREQUEST_HEADERS:\nGET /bomb HTTP/1.1\nHost: 127.0.0.1:8081\nUser-Agent: Mozilla/5.0 (compatible; pycurl)\nAccept: */*\nAccept-Encoding: gzip,deflate\nWIRE_SENT 65536/4174525\nWIRE_SENT 2162688/4174525\nCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, \u0027Connection reset by peer\u0027)\n\nvictim_curl_rss.log (VmRSS kB, every 0.2 s):\n0.00 30884\n0.61 231848\n1.41 514720\n2.22 794480\n2.82 1000756\n3.18 1032100 \u003c- last sample before kill\n\ndriver_f1.log:\ntimeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed\nVICTIM_CURL_EXIT=137 # docker inspect -\u003e OomKilled: true\n\nvictim_simple.log (control, same bomb):\nFETCH_FAILED: HTTP 599: Connection closed\nSCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB\n```\n\nHonest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test\u0027s 1 GiB cgroup cap as the observation instrument; the \"unbounded\" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path \u2014 with more memory the transfer would have continued to the full 4 GiB payload.\n\n## Impact\n\nDenial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as `available_memory / 1000`. Because the accumulation happens on the shared event loop\u0027s client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim\u0027s configured client visits the attacker\u0027s origin.\n\n### Suggested fix\n\nEnforce a byte budget in the write path of `CurlAsyncHTTPClient`: wrap the `WRITEFUNCTION` (both the `buffer.write` branch and the `streaming_callback` branch) in a counter that aborts the transfer (`curl.setopt(pycurl.FAILONERROR)`-style cancellation or raising from the callback) once the received total exceeds `max_body_size`, plumbed from `initialize()` with the same 100 MiB default as `SimpleAsyncHTTPClient`. Because libcurl decompresses before the write callback, the counter naturally measures *decompressed* bytes \u2014 the same semantics as the CVE-2026-49855 fix. (`pycurl.MAXFILESIZE` alone is insufficient: it applies to the compressed transfer size.)\n\n### Affected versions\n\n- **\u003c= 6.5.8** (latest tag; the curl client has never had a response-size limit) and master (`6.6.dev1`, verified 2026-08-15/17).\n- 6.5.6\u0027s CVE-2026-49855 fix covered `SimpleAsyncHTTPClient`/`http1connection.py` only; `curl_httpclient.py` was not touched.\n\n## Credit\n\nReported by the diff/ambidiff security research effort (afldl).",
"id": "BREW-sickchill-GHSA-chx6-46f5-w4vp",
"modified": "2026-11-13T09:11:22Z",
"published": "2026-10-01T09:53:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/pull/3719"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/15f056080d8e456f92cca8ad0c33e5a5480414ac"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/6564e0a0922c16f239d3a18adccd04736e380c89"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/aa2eb0d989716ac00fe8d7a9919b81c1eccd6ec4"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9"
},
{
"type": "PACKAGE",
"url": "https://github.com/tornadoweb/tornado"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/releases/tag/v6.5.9"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "tornado: CurlAsyncHTTPClient enforces no response-size limit \u2014 decompression bomb drives unbounded memory accumulation to OOM",
"upstream": [
"GHSA-chx6-46f5-w4vp",
"CVE-2026-103262"
]
}
BREW-SNAKEVIZ-GHSA-CHX6-… (GHSA-CHX6-46F5-W4VP)
Vulnerability from osv_homebrew – Published: 2026-10-01 11:45 – Updated: 2026-10-30 00:29 – Source websiteAn unbounded memory accumulation (decompression bomb) in tornado.curl_httpclient.CurlAsyncHTTPClient — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (6.6.dev1) and present unchanged in the latest release tag v6.5.8 and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and fetch()es an attacker-chosen or attacker-compromised URL with default decompress_response=True, a malicious server replying Content-Encoding: gzip with a ~2.8 MB wire bomb drove the client's RSS from 30,884 kB to 1,032,100 kB (~1008 MB) in 3.18 s (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup OOMKilled=true) — with the transfer only 67% complete and no client-side size check ever intervening: curl_httpclient.py contains zero occurrences of max_body_size/MAXFILESIZE. The identical bomb against the default SimpleAsyncHTTPClient fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size — http1connection.py:620,676,742) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed _GzipMessageDelegate/SimpleAsyncHTTPClient only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file's full commit history (latest 2026-06-17) shows no response-size work.
Details
tornado/curl_httpclient.py (line numbers identical on master 6.6.dev1, v6.5.8, and the audited snapshot):
"buffer": BytesIO(), # :202 — plain BytesIO, no accounting
...
else:
write_function = buffer.write # :359 — every decompressed byte lands here
curl.setopt(pycurl.WRITEFUNCTION, write_function) # :360
...
if request.decompress_response: # default True (HTTPRequest)
curl.setopt(pycurl.ENCODING, "gzip,deflate") # :373-374 — libcurl advertises + auto-decodes
libcurl decompresses the response before invoking WRITEFUNCTION, so the callback receives decompressed bytes, which are appended to an unbounded BytesIO until the transfer ends or the process dies. The only ceiling is request_timeout (default 20 s) — at zlib's hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no pycurl.MAXFILESIZE, no max_buffer_size/max_body_size plumbing (the constructor accepts no body-size option), and streaming_callback users fare no better (the callback variant at :353-356 also performs zero accounting).
Contrast — SimpleAsyncHTTPClient path (tornado/http1connection.py), all absent from the curl path:
if cast(int, content_length) > self._max_body_size: # :620 Content-Length gate
if total_size > self._max_body_size: # :676 chunked total gate
if self._decompressed_body_size > self._max_body_size: # :742 CVE-2026-49855 decompressed gate
SimpleAsyncHTTPClient.initialize() defaults max_buffer_size = 104857600 (100 MiB) with max_body_size defaulting to it (simple_httpclient.py:117-121); CurlAsyncHTTPClient.initialize() has no corresponding parameter at all.
Attack chain (attacker = malicious HTTP server; victim = any Tornado app doing fetch() on attacker-influenced URLs — URL fetchers, webhook processors, link previewers, RSS/probe pollers):
- App configures
AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")(documented for proxy support; proxies are only supported with the curl client). - App calls
fetch("http://attacker/...")with defaults → request advertisesAccept-Encoding: gzip,deflate. - Attacker replies
200,Content-Encoding: gzip,Transfer-Encoding: chunked, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks). - libcurl auto-decodes at ~350 MB/s into
buffer.writewith no size accounting → process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).
Variant without compression: decompress_response=False plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted buffer.write — this client never enforces any cap on any path.
PoC
Verified end-to-end 2026-08-15 in a single container (cgroup --memory 1g --memory-swap 1g so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on 127.0.0.1:8081: a raw-socket malicious server (evil_server.py, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (victim_curl.py, configures CurlAsyncHTTPClient, fetch(..., request_timeout=300), samples /proc/self/status VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).
Build & run the victim
git clone https://github.com/tornadoweb/tornado
cd tornado
pip install pycurl
python evil_server.py & # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING
python victim_curl.py # victim: CurlAsyncHTTPClient fetch -> expect linear RSS rise -> OOM
python victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb
Verified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot 6.6.dev1 of 2026-08-15 run from the source tree (sys.path), container memory capped at 1 GiB. curl_httpclient.py verified byte-equivalent (still zero size-limit references) in tag v6.5.8 and on master as of 2026-08-17.
Reproduction steps
-
Precondition — the documented curl-client deployment fetching a remote URL. The vulnerability requires the application to use
CurlAsyncHTTPClient(the standard configuration when proxy support or advanced TLS options are needed) with defaultdecompress_response=True, and to fetch a URL whose server the attacker controls or has compromised.victim_curl.pyimplements exactly that (AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient")→fetch()), and the server log confirms the ENCODING path engaged — the victim's request arrived withUser-Agent: Mozilla/5.0 (compatible; pycurl)andAccept-Encoding: gzip,deflate. -
Attack: start
evil_server.py, wait forEVIL_LISTENING, then runvictim_curl.py(the fetch itself is the attack; no further interaction). -
Expected:
victim_curl_rss.logshows VmRSS 30,884 → 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (exit 137, dockerOOMKilled=true); the server logsCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525— the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered. -
Variant: with
decompress_response=Falseand an unterminated chunked body (server keeps sending forever), the samebuffer.writepath accumulates unbounded plain bytes — no compression needed;request_timeoutonly extends the ceiling. -
Control:
victim_simple.pyfetches the identical bomb with the defaultSimpleAsyncHTTPClient→ cleanFETCH_FAILED: HTTP 599: Connection closed, RSS peak ~65 MB (24,984 → 66,712 kB), script exit 0 — the CVE-2026-49855 accounting inhttp1connection.pyaborts the transfer, proving the gap is specific to the curl client.
PoC source
Full PoC source (victim_curl.py, stdlib only, no dependencies): victim_curl.py (secret gist, unlisted).
The gist carries evil_server.py (bomb server), victim_curl.py (victim), victim_simple.py (control), and REPRODUCE.md.
Captured output (2026-08-15 run, verbatim excerpts)
evil_server.log:
BOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1
EVIL_LISTENING 127.0.0.1:8081
REQUEST_FROM 127.0.0.1:57544 -> GET /bomb HTTP/1.1
REQUEST_HEADERS:
GET /bomb HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (compatible; pycurl)
Accept: */*
Accept-Encoding: gzip,deflate
WIRE_SENT 65536/4174525
WIRE_SENT 2162688/4174525
CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, 'Connection reset by peer')
victim_curl_rss.log (VmRSS kB, every 0.2 s):
0.00 30884
0.61 231848
1.41 514720
2.22 794480
2.82 1000756
3.18 1032100 <- last sample before kill
driver_f1.log:
timeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed
VICTIM_CURL_EXIT=137 # docker inspect -> OomKilled: true
victim_simple.log (control, same bomb):
FETCH_FAILED: HTTP 599: Connection closed
SCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB
Honest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test's 1 GiB cgroup cap as the observation instrument; the "unbounded" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path — with more memory the transfer would have continued to the full 4 GiB payload.
Impact
Denial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as available_memory / 1000. Because the accumulation happens on the shared event loop's client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim's configured client visits the attacker's origin.
Suggested fix
Enforce a byte budget in the write path of CurlAsyncHTTPClient: wrap the WRITEFUNCTION (both the buffer.write branch and the streaming_callback branch) in a counter that aborts the transfer (curl.setopt(pycurl.FAILONERROR)-style cancellation or raising from the callback) once the received total exceeds max_body_size, plumbed from initialize() with the same 100 MiB default as SimpleAsyncHTTPClient. Because libcurl decompresses before the write callback, the counter naturally measures decompressed bytes — the same semantics as the CVE-2026-49855 fix. (pycurl.MAXFILESIZE alone is insufficient: it applies to the compressed transfer size.)
Affected versions
- <= 6.5.8 (latest tag; the curl client has never had a response-size limit) and master (
6.6.dev1, verified 2026-08-15/17). - 6.5.6's CVE-2026-49855 fix covered
SimpleAsyncHTTPClient/http1connection.pyonly;curl_httpclient.pywas not touched.
Credit
Reported by the diff/ambidiff security research effort (afldl).
| URL | Type | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "tornado",
"resource_purl": "pkg:pypi/tornado@6.6",
"upstream_fixed_in": "6.5.9"
},
"package": {
"ecosystem": "Homebrew",
"name": "snakeviz",
"purl": "pkg:brew/snakeviz"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.2_6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/tornado@6.6",
"name": "tornado",
"resource": "tornado",
"strategy": "registry",
"subject_version": "6.6"
}
]
},
"details": "An unbounded memory accumulation (decompression bomb) in `tornado.curl_httpclient.CurlAsyncHTTPClient` \u2014 the client-side sibling gap of CVE-2026-49855 \u2014 verified end-to-end on the 2026-08-15 master snapshot (`6.6.dev1`) and present unchanged in the latest release tag `v6.5.8` and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and `fetch()`es an attacker-chosen or attacker-compromised URL with default `decompress_response=True`, a malicious server replying `Content-Encoding: gzip` with a ~2.8 MB wire bomb drove the client\u0027s RSS from 30,884 kB to **1,032,100 kB (~1008 MB) in 3.18 s** (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup `OOMKilled=true`) \u2014 with the transfer only 67% complete and **no client-side size check ever intervening**: `curl_httpclient.py` contains zero occurrences of `max_body_size`/`MAXFILESIZE`. The identical bomb against the default `SimpleAsyncHTTPClient` fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size \u2014 `http1connection.py:620,676,742`) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed `_GzipMessageDelegate`/`SimpleAsyncHTTPClient` only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file\u0027s full commit history (latest 2026-06-17) shows no response-size work.\n\n## Details\n\n`tornado/curl_httpclient.py` (line numbers identical on master `6.6.dev1`, `v6.5.8`, and the audited snapshot):\n\n```python\n\"buffer\": BytesIO(), # :202 \u2014 plain BytesIO, no accounting\n...\nelse:\n write_function = buffer.write # :359 \u2014 every decompressed byte lands here\ncurl.setopt(pycurl.WRITEFUNCTION, write_function) # :360\n...\nif request.decompress_response: # default True (HTTPRequest)\n curl.setopt(pycurl.ENCODING, \"gzip,deflate\") # :373-374 \u2014 libcurl advertises + auto-decodes\n```\n\nlibcurl decompresses the response **before** invoking `WRITEFUNCTION`, so the callback receives decompressed bytes, which are appended to an unbounded `BytesIO` until the transfer ends or the process dies. The only ceiling is `request_timeout` (default 20 s) \u2014 at zlib\u0027s hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no `pycurl.MAXFILESIZE`, no `max_buffer_size`/`max_body_size` plumbing (the constructor accepts no body-size option), and `streaming_callback` users fare no better (the callback variant at `:353-356` also performs zero accounting).\n\nContrast \u2014 `SimpleAsyncHTTPClient` path (`tornado/http1connection.py`), all absent from the curl path:\n\n```python\nif cast(int, content_length) \u003e self._max_body_size: # :620 Content-Length gate\nif total_size \u003e self._max_body_size: # :676 chunked total gate\nif self._decompressed_body_size \u003e self._max_body_size: # :742 CVE-2026-49855 decompressed gate\n```\n\n`SimpleAsyncHTTPClient.initialize()` defaults `max_buffer_size = 104857600` (100 MiB) with `max_body_size` defaulting to it (`simple_httpclient.py:117-121`); `CurlAsyncHTTPClient.initialize()` has no corresponding parameter at all.\n\nAttack chain (attacker = malicious HTTP server; victim = any Tornado app doing `fetch()` on attacker-influenced URLs \u2014 URL fetchers, webhook processors, link previewers, RSS/probe pollers):\n\n1. App configures `AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` (documented for proxy support; proxies are only supported with the curl client).\n2. App calls `fetch(\"http://attacker/...\")` with defaults \u2192 request advertises `Accept-Encoding: gzip,deflate`.\n3. Attacker replies `200`, `Content-Encoding: gzip`, `Transfer-Encoding: chunked`, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks).\n4. libcurl auto-decodes at ~350 MB/s into `buffer.write` with no size accounting \u2192 process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).\n\nVariant without compression: `decompress_response=False` plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted `buffer.write` \u2014 this client never enforces any cap on any path.\n\n## PoC\n\nVerified end-to-end 2026-08-15 in a single container (cgroup `--memory 1g --memory-swap 1g` so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on `127.0.0.1:8081`: a raw-socket malicious server (`evil_server.py`, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (`victim_curl.py`, configures `CurlAsyncHTTPClient`, `fetch(..., request_timeout=300)`, samples `/proc/self/status` VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).\n\n### Build \u0026 run the victim\n\n```bash\ngit clone https://github.com/tornadoweb/tornado\ncd tornado\npip install pycurl\npython evil_server.py \u0026 # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING\npython victim_curl.py # victim: CurlAsyncHTTPClient fetch -\u003e expect linear RSS rise -\u003e OOM\npython victim_simple.py # control: default SimpleAsyncHTTPClient on the same bomb\n```\n\nVerified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot `6.6.dev1` of 2026-08-15 run from the source tree (`sys.path`), container memory capped at 1 GiB. `curl_httpclient.py` verified byte-equivalent (still zero size-limit references) in tag `v6.5.8` and on master as of 2026-08-17.\n\n### Reproduction steps\n\n1. **Precondition \u2014 the documented curl-client deployment fetching a remote URL.** The vulnerability requires the application to use `CurlAsyncHTTPClient` (the standard configuration when proxy support or advanced TLS options are needed) with default `decompress_response=True`, and to fetch a URL whose server the attacker controls or has compromised. `victim_curl.py` implements exactly that (`AsyncHTTPClient.configure(\"tornado.curl_httpclient.CurlAsyncHTTPClient\")` \u2192 `fetch()`), and the server log confirms the ENCODING path engaged \u2014 the victim\u0027s request arrived with `User-Agent: Mozilla/5.0 (compatible; pycurl)` and `Accept-Encoding: gzip,deflate`.\n\n2. **Attack:** start `evil_server.py`, wait for `EVIL_LISTENING`, then run `victim_curl.py` (the fetch itself is the attack; no further interaction).\n\n3. **Expected:** `victim_curl_rss.log` shows VmRSS 30,884 \u2192 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (`exit 137`, docker `OOMKilled=true`); the server logs `CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525` \u2014 the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered.\n\n4. **Variant:** with `decompress_response=False` and an unterminated chunked body (server keeps sending forever), the same `buffer.write` path accumulates unbounded plain bytes \u2014 no compression needed; `request_timeout` only extends the ceiling.\n\n5. **Control:** `victim_simple.py` fetches the identical bomb with the default `SimpleAsyncHTTPClient` \u2192 clean `FETCH_FAILED: HTTP 599: Connection closed`, RSS peak ~65 MB (24,984 \u2192 66,712 kB), script exit 0 \u2014 the CVE-2026-49855 accounting in `http1connection.py` aborts the transfer, proving the gap is specific to the curl client.\n\n### PoC source\n\nFull PoC source (**victim_curl.py**, stdlib only, no dependencies): [victim_curl.py](https://gist.github.com/afldl/211c0e7af8175c2eabab53ed037c435d) (secret gist, unlisted).\n\n\nThe gist carries `evil_server.py` (bomb server), `victim_curl.py` (victim), `victim_simple.py` (control), and `REPRODUCE.md`.\n\n### Captured output (2026-08-15 run, verbatim excerpts)\n\n```\nevil_server.log:\nBOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1\nEVIL_LISTENING 127.0.0.1:8081\nREQUEST_FROM 127.0.0.1:57544 -\u003e GET /bomb HTTP/1.1\nREQUEST_HEADERS:\nGET /bomb HTTP/1.1\nHost: 127.0.0.1:8081\nUser-Agent: Mozilla/5.0 (compatible; pycurl)\nAccept: */*\nAccept-Encoding: gzip,deflate\nWIRE_SENT 65536/4174525\nWIRE_SENT 2162688/4174525\nCLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, \u0027Connection reset by peer\u0027)\n\nvictim_curl_rss.log (VmRSS kB, every 0.2 s):\n0.00 30884\n0.61 231848\n1.41 514720\n2.22 794480\n2.82 1000756\n3.18 1032100 \u003c- last sample before kill\n\ndriver_f1.log:\ntimeout 240 python3 /e2e/F1/victim_curl.py ... 606 Killed\nVICTIM_CURL_EXIT=137 # docker inspect -\u003e OomKilled: true\n\nvictim_simple.log (control, same bomb):\nFETCH_FAILED: HTTP 599: Connection closed\nSCRIPT_FINISHED_NORMALLY # exit 0, VmRSS peak 66712 kB\n```\n\nHonest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test\u0027s 1 GiB cgroup cap as the observation instrument; the \"unbounded\" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path \u2014 with more memory the transfer would have continued to the full 4 GiB payload.\n\n## Impact\n\nDenial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as `available_memory / 1000`. Because the accumulation happens on the shared event loop\u0027s client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim\u0027s configured client visits the attacker\u0027s origin.\n\n### Suggested fix\n\nEnforce a byte budget in the write path of `CurlAsyncHTTPClient`: wrap the `WRITEFUNCTION` (both the `buffer.write` branch and the `streaming_callback` branch) in a counter that aborts the transfer (`curl.setopt(pycurl.FAILONERROR)`-style cancellation or raising from the callback) once the received total exceeds `max_body_size`, plumbed from `initialize()` with the same 100 MiB default as `SimpleAsyncHTTPClient`. Because libcurl decompresses before the write callback, the counter naturally measures *decompressed* bytes \u2014 the same semantics as the CVE-2026-49855 fix. (`pycurl.MAXFILESIZE` alone is insufficient: it applies to the compressed transfer size.)\n\n### Affected versions\n\n- **\u003c= 6.5.8** (latest tag; the curl client has never had a response-size limit) and master (`6.6.dev1`, verified 2026-08-15/17).\n- 6.5.6\u0027s CVE-2026-49855 fix covered `SimpleAsyncHTTPClient`/`http1connection.py` only; `curl_httpclient.py` was not touched.\n\n## Credit\n\nReported by the diff/ambidiff security research effort (afldl).",
"id": "BREW-snakeviz-GHSA-chx6-46f5-w4vp",
"modified": "2026-10-30T00:29:26Z",
"published": "2026-10-01T11:45:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/pull/3719"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/15f056080d8e456f92cca8ad0c33e5a5480414ac"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/6564e0a0922c16f239d3a18adccd04736e380c89"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/aa2eb0d989716ac00fe8d7a9919b81c1eccd6ec4"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9"
},
{
"type": "PACKAGE",
"url": "https://github.com/tornadoweb/tornado"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/releases/tag/v6.5.9"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "tornado: CurlAsyncHTTPClient enforces no response-size limit \u2014 decompression bomb drives unbounded memory accumulation to OOM",
"upstream": [
"GHSA-chx6-46f5-w4vp",
"CVE-2026-103262"
]
}
CERTFR-2026-AVI-1431
Vulnerability from certfr_avis - Published: 2026-10-30 - Updated: 2026-10-30
De multiples vulnérabilités ont été découvertes dans le noyau Linux de Red Hat. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.6 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.21 for RHEL 9 s390x | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - AUS 8.6 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.0 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.21 for RHEL 8 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian 8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.2 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - AUS 8.4 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems 8 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.22 for RHEL 8 s390x | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.2 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 10.0 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.14 for RHEL 8 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.12 for RHEL 8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 8 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.22 for RHEL 9 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.20 for RHEL 8 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.12 for RHEL 8 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.14 for RHEL 8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.2 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.18 for RHEL 9 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.12 for RHEL 9 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 10 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.6 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - TUS 8.8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Real Time 8 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.22 for RHEL 9 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - Extended Life Cycle Support Extension 6 i386 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.6 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.19 for RHEL 8 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.18 for RHEL 9 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.12 for RHEL 9 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.22 for RHEL 8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.0 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.18 for RHEL 8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.0 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.2 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.18 for RHEL 8 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.19 for RHEL 8 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.0 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.22 for RHEL 8 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - AUS 9.6 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.22 for RHEL 8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.6 s390x | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 10 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.22 for RHEL 9 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.21 for RHEL 9 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.14 for RHEL 9 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.2 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.16 for RHEL 9 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.20 for RHEL 8 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.19 for RHEL 8 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.20 for RHEL 9 s390x | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for IBM z Systems 10 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.2 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.16 for RHEL 9 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.0 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.19 for RHEL 9 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 10.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.6 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.14 for RHEL 8 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 8.10 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.6 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.21 for RHEL 8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.6 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.6 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.6 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.12 for RHEL 9 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 8.10 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.6 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 8 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.12 for RHEL 8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 10 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.20 for RHEL 8 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 8 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 10.2 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.0 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.2 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.18 for RHEL 9 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - Extended Life Cycle Support Extension 6 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 9.6 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.12 for RHEL 9 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.18 for RHEL 8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Real Time for NFV 8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.6 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.16 for RHEL 9 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 10.2 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.6 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 8 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.18 for RHEL 8 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 10.0 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.6 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.2 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.20 for RHEL 9 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 8.10 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.18 for RHEL 9 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.14 for RHEL 9 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.0 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.20 for RHEL 8 s390x | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - AUS 9.2 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.12 for RHEL 8 s390x | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 10 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.19 for RHEL 9 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.21 for RHEL 8 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.2 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.16 for RHEL 9 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.21 for RHEL 9 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.6 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle Long Life 8.8 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.6 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.2 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.19 for RHEL 8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle Long Life 8.6 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.22 for RHEL 9 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.19 for RHEL 9 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 10.2 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 8.10 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.21 for RHEL 9 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian 8 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.19 for RHEL 9 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux Hidden Content for x86_64 10 x86_64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.20 for RHEL 9 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 10.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.2 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.2 s390x | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - Extended Life Cycle Support Extension (for IBM z Systems) 6 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.2 aarch64 | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for Power 4.21 for RHEL 8 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.20 for RHEL 9 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems 10 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.14 for RHEL 8 s390x | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform 4.14 for RHEL 9 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian 10 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian 10 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle Long Life 8.4 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 10.2 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.2 ppc64le | ||
| Red Hat | Red Hat OpenShift Container Platform | Red Hat OpenShift Container Platform for ARM 64 4.14 for RHEL 9 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.0 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.0 aarch64 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.6 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.21 for RHEL 9 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 8.6 x86_64",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.0 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.21 for RHEL 8 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 8 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 8.4 x86_64",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 8 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.22 for RHEL 8 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.2 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 10.0 s390x",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.14 for RHEL 8 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.12 for RHEL 8 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.22 for RHEL 9 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.20 for RHEL 8 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.12 for RHEL 8 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.14 for RHEL 8 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.18 for RHEL 9 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.12 for RHEL 9 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 10 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.6 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - TUS 8.8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Real Time 8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.22 for RHEL 9 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - Extended Life Cycle Support Extension 6 i386",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.6 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.19 for RHEL 8 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.18 for RHEL 9 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.12 for RHEL 9 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.22 for RHEL 8 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.0 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.18 for RHEL 8 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.0 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.18 for RHEL 8 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.19 for RHEL 8 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.0 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.22 for RHEL 8 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 9.6 x86_64",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.22 for RHEL 8 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.6 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 10 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.22 for RHEL 9 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.21 for RHEL 9 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.14 for RHEL 9 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.16 for RHEL 9 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.20 for RHEL 8 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.19 for RHEL 8 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.20 for RHEL 9 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems 10 s390x",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.16 for RHEL 9 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.0 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.19 for RHEL 9 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 10.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.6 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.14 for RHEL 8 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 8.10 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.6 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.21 for RHEL 8 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.6 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.6 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.6 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.12 for RHEL 9 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 8.10 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.6 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 8 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.12 for RHEL 8 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 10 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.20 for RHEL 8 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 8 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 10.2 s390x",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.0 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.18 for RHEL 9 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - Extended Life Cycle Support Extension 6 x86_64",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 9.6 s390x",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.12 for RHEL 9 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.18 for RHEL 8 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Real Time for NFV 8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.6 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.16 for RHEL 9 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 10.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.6 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 8 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.18 for RHEL 8 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 10.0 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.6 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.20 for RHEL 9 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 8.10 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.18 for RHEL 9 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.14 for RHEL 9 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.0 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.20 for RHEL 8 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 9.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.12 for RHEL 8 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 10 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.19 for RHEL 9 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.21 for RHEL 8 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.16 for RHEL 9 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.21 for RHEL 9 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.6 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle Long Life 8.8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.6 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.19 for RHEL 8 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle Long Life 8.6 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.22 for RHEL 9 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.19 for RHEL 9 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 10.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 8.10 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.21 for RHEL 9 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 8 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.19 for RHEL 9 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.8 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Hidden Content for x86_64 10 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.20 for RHEL 9 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 10.2 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - Extended Life Cycle Support Extension (for IBM z Systems) 6 s390x",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for Power 4.21 for RHEL 8 ppc64le",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.20 for RHEL 9 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 10 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for IBM Z and LinuxONE 4.14 for RHEL 8 s390x",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform 4.14 for RHEL 9 x86_64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 10 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 10 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle Long Life 8.4 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 10.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat OpenShift Container Platform for ARM 64 4.14 for RHEL 9 aarch64",
"product": {
"name": "Red Hat OpenShift Container Platform",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.0 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.0 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-80887",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80887"
},
{
"name": "CVE-2026-54369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54369"
},
{
"name": "CVE-2026-68138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68138"
},
{
"name": "CVE-2026-59995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59995"
},
{
"name": "CVE-2026-63384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63384"
},
{
"name": "CVE-2026-19667",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19667"
},
{
"name": "CVE-2026-89972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89972"
},
{
"name": "CVE-2026-63993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63993"
},
{
"name": "CVE-2026-59999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59999"
},
{
"name": "CVE-2026-40468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40468"
},
{
"name": "CVE-2026-68338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68338"
},
{
"name": "CVE-2026-40467",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40467"
},
{
"name": "CVE-2026-89480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89480"
},
{
"name": "CVE-2026-89638",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89638"
},
{
"name": "CVE-2026-23199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23199"
},
{
"name": "CVE-2026-64319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64319"
},
{
"name": "CVE-2026-93207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93207"
},
{
"name": "CVE-2026-63924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63924"
},
{
"name": "CVE-2026-72083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72083"
},
{
"name": "CVE-2026-63979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63979"
},
{
"name": "CVE-2026-10723",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10723"
},
{
"name": "CVE-2026-93228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93228"
},
{
"name": "CVE-2026-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53224"
},
{
"name": "CVE-2026-97417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-97417"
},
{
"name": "CVE-2026-31581",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31581"
},
{
"name": "CVE-2026-94640",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-94640"
},
{
"name": "CVE-2026-45445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45445"
},
{
"name": "CVE-2026-64017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64017"
},
{
"name": "CVE-2026-66046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66046"
},
{
"name": "CVE-2026-89811",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89811"
},
{
"name": "CVE-2026-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58014"
},
{
"name": "CVE-2026-86142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86142"
},
{
"name": "CVE-2026-64508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64508"
},
{
"name": "CVE-2026-16445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16445"
},
{
"name": "CVE-2026-15816",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15816"
},
{
"name": "CVE-2026-80864",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80864"
},
{
"name": "CVE-2026-90036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-90036"
},
{
"name": "CVE-2026-19953",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19953"
},
{
"name": "CVE-2026-80824",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80824"
},
{
"name": "CVE-2025-35973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-35973"
},
{
"name": "CVE-2026-68476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68476"
},
{
"name": "CVE-2026-31692",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31692"
},
{
"name": "CVE-2026-43450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43450"
},
{
"name": "CVE-2026-64523",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64523"
},
{
"name": "CVE-2026-0799",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0799"
},
{
"name": "CVE-2026-80274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80274"
},
{
"name": "CVE-2026-99999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-99999"
},
{
"name": "CVE-2026-43493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
},
{
"name": "CVE-2026-46259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46259"
},
{
"name": "CVE-2026-89846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89846"
},
{
"name": "CVE-2026-64061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64061"
},
{
"name": "CVE-2026-98222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-98222"
},
{
"name": "CVE-2026-80792",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80792"
},
{
"name": "CVE-2026-5260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5260"
},
{
"name": "CVE-2026-64109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64109"
},
{
"name": "CVE-2026-64320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64320"
},
{
"name": "CVE-2026-81003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-81003"
},
{
"name": "CVE-2026-63984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63984"
},
{
"name": "CVE-2026-114406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-114406"
},
{
"name": "CVE-2026-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53236"
},
{
"name": "CVE-2026-43051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43051"
},
{
"name": "CVE-2026-89894",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89894"
},
{
"name": "CVE-2026-63978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63978"
},
{
"name": "CVE-2026-74641",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74641"
},
{
"name": "CVE-2026-80586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80586"
},
{
"name": "CVE-2026-42013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42013"
},
{
"name": "CVE-2026-63920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63920"
},
{
"name": "CVE-2026-64027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64027"
},
{
"name": "CVE-2026-64378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64378"
},
{
"name": "CVE-2026-86145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86145"
},
{
"name": "CVE-2026-45447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45447"
},
{
"name": "CVE-2026-8924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8924"
},
{
"name": "CVE-2026-68257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68257"
},
{
"name": "CVE-2026-60002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60002"
},
{
"name": "CVE-2026-74515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74515"
},
{
"name": "CVE-2026-93262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93262"
},
{
"name": "CVE-2025-68745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68745"
},
{
"name": "CVE-2026-80863",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80863"
},
{
"name": "CVE-2026-63382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63382"
},
{
"name": "CVE-2026-53073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53073"
},
{
"name": "CVE-2026-103111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-103111"
},
{
"name": "CVE-2026-90227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-90227"
},
{
"name": "CVE-2026-63383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63383"
},
{
"name": "CVE-2026-72242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72242"
},
{
"name": "CVE-2026-53388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53388"
},
{
"name": "CVE-2026-42011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42011"
},
{
"name": "CVE-2026-68136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68136"
},
{
"name": "CVE-2026-43020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43020"
},
{
"name": "CVE-2026-34183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34183"
},
{
"name": "CVE-2026-68121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68121"
},
{
"name": "CVE-2026-89777",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89777"
},
{
"name": "CVE-2026-89690",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89690"
},
{
"name": "CVE-2026-103262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-103262"
},
{
"name": "CVE-2026-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68200"
},
{
"name": "CVE-2026-6893",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6893"
},
{
"name": "CVE-2026-68140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68140"
},
{
"name": "CVE-2026-93817",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93817"
},
{
"name": "CVE-2026-89481",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89481"
},
{
"name": "CVE-2026-93990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93990"
},
{
"name": "CVE-2026-46086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46086"
},
{
"name": "CVE-2026-63385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63385"
},
{
"name": "CVE-2026-63387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63387"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-63831",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63831"
},
{
"name": "CVE-2026-89161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89161"
},
{
"name": "CVE-2026-86144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86144"
},
{
"name": "CVE-2022-50315",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50315"
},
{
"name": "CVE-2026-72098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72098"
},
{
"name": "CVE-2026-72289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72289"
},
{
"name": "CVE-2026-63922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63922"
},
{
"name": "CVE-2026-90011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-90011"
},
{
"name": "CVE-2026-68108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68108"
},
{
"name": "CVE-2026-43114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43114"
},
{
"name": "CVE-2026-53246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53246"
},
{
"name": "CVE-2026-89663",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89663"
},
{
"name": "CVE-2026-34182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34182"
},
{
"name": "CVE-2026-86138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86138"
},
{
"name": "CVE-2026-86140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86140"
},
{
"name": "CVE-2026-63388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63388"
},
{
"name": "CVE-2026-19666",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19666"
},
{
"name": "CVE-2026-72243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72243"
},
{
"name": "CVE-2026-68123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68123"
},
{
"name": "CVE-2026-89669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89669"
},
{
"name": "CVE-2026-64507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64507"
},
{
"name": "CVE-2026-93288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93288"
},
{
"name": "CVE-2026-42012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42012"
},
{
"name": "CVE-2026-74631",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74631"
},
{
"name": "CVE-2026-80921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80921"
},
{
"name": "CVE-2026-86143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86143"
},
{
"name": "CVE-2026-72288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72288"
},
{
"name": "CVE-2026-64564",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64564"
},
{
"name": "CVE-2026-52972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52972"
},
{
"name": "CVE-2026-63802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63802"
}
],
"initial_release_date": "2026-10-30T00:00:00",
"last_revision_date": "2026-10-30T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1431",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-10-30T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Falsification de requ\u00eates c\u00f4t\u00e9 serveur (SSRF)"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de Red Hat. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de Red Hat",
"vendor_advisories": [
{
"published_at": "2026-10-23",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:88687",
"url": "https://access.redhat.com/errata/RHSA-2026:88687"
},
{
"published_at": "2026-10-27",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89232",
"url": "https://access.redhat.com/errata/RHSA-2026:89232"
},
{
"published_at": "2026-10-30",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:92993",
"url": "https://access.redhat.com/errata/RHSA-2026:92993"
},
{
"published_at": "2026-10-27",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89838",
"url": "https://access.redhat.com/errata/RHSA-2026:89838"
},
{
"published_at": "2026-10-28",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:91648",
"url": "https://access.redhat.com/errata/RHSA-2026:91648"
},
{
"published_at": "2026-10-29",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:92209",
"url": "https://access.redhat.com/errata/RHSA-2026:92209"
},
{
"published_at": "2026-10-27",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89725",
"url": "https://access.redhat.com/errata/RHSA-2026:89725"
},
{
"published_at": "2026-10-28",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:91585",
"url": "https://access.redhat.com/errata/RHSA-2026:91585"
},
{
"published_at": "2026-10-24",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89082",
"url": "https://access.redhat.com/errata/RHSA-2026:89082"
},
{
"published_at": "2026-10-30",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:92997",
"url": "https://access.redhat.com/errata/RHSA-2026:92997"
},
{
"published_at": "2026-10-27",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89197",
"url": "https://access.redhat.com/errata/RHSA-2026:89197"
},
{
"published_at": "2026-10-29",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:92362",
"url": "https://access.redhat.com/errata/RHSA-2026:92362"
},
{
"published_at": "2026-10-27",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:90272",
"url": "https://access.redhat.com/errata/RHSA-2026:90272"
},
{
"published_at": "2026-10-27",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:90933",
"url": "https://access.redhat.com/errata/RHSA-2026:90933"
},
{
"published_at": "2026-10-28",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:91565",
"url": "https://access.redhat.com/errata/RHSA-2026:91565"
},
{
"published_at": "2026-10-26",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89814",
"url": "https://access.redhat.com/errata/RHSA-2026:89814"
},
{
"published_at": "2026-10-24",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89083",
"url": "https://access.redhat.com/errata/RHSA-2026:89083"
},
{
"published_at": "2026-10-27",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89714",
"url": "https://access.redhat.com/errata/RHSA-2026:89714"
},
{
"published_at": "2026-10-26",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89816",
"url": "https://access.redhat.com/errata/RHSA-2026:89816"
},
{
"published_at": "2026-10-27",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89333",
"url": "https://access.redhat.com/errata/RHSA-2026:89333"
},
{
"published_at": "2026-10-27",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89651",
"url": "https://access.redhat.com/errata/RHSA-2026:89651"
},
{
"published_at": "2026-10-29",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:92208",
"url": "https://access.redhat.com/errata/RHSA-2026:92208"
},
{
"published_at": "2026-10-28",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:91493",
"url": "https://access.redhat.com/errata/RHSA-2026:91493"
},
{
"published_at": "2026-10-26",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:89890",
"url": "https://access.redhat.com/errata/RHSA-2026:89890"
}
]
}
FKIE_CVE-2026-103262
Vulnerability from fkie_nvd - Published: 2026-10-01 11:17 - Updated: 2026-10-06 01:16| URL | Tags | ||
|---|---|---|---|
| disclosure@vulncheck.com | https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9 | ||
| disclosure@vulncheck.com | https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp | ||
| disclosure@vulncheck.com | https://www.vulncheck.com/advisories/tornado-before-6.5.9-denial-of-service-via-curlasynchttpclient | ||
| 134c704f-9b21-4f2e-91b3-4a467353bcc0 | https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp |
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"packageURL": "pkg:pypi/tornado",
"product": "tornado",
"vendor": "tornadoweb",
"versions": [
{
"lessThan": "6.5.9",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.5.9",
"versionType": "semver"
}
]
}
],
"source": "disclosure@vulncheck.com"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Tornado versions before 6.5.9 contain an unbounded memory accumulation vulnerability in CurlAsyncHTTPClient that allows remote attackers to cause denial of service by sending a compressed response. Attackers can send a gzip-encoded decompression bomb that accumulates in memory without size limits, causing the application process to be killed by out-of-memory conditions."
}
],
"id": "CVE-2026-103262",
"lastModified": "2026-10-06T01:16:32.767",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"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"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6,
"source": "disclosure@vulncheck.com",
"type": "Secondary"
}
],
"cvssMetricV40": [
{
"cvssData": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"availabilityRequirement": "NOT_DEFINED",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"confidentialityRequirement": "NOT_DEFINED",
"exploitMaturity": "NOT_DEFINED",
"integrityRequirement": "NOT_DEFINED",
"modifiedAttackComplexity": "NOT_DEFINED",
"modifiedAttackRequirements": "NOT_DEFINED",
"modifiedAttackVector": "NOT_DEFINED",
"modifiedPrivilegesRequired": "NOT_DEFINED",
"modifiedSubAvailabilityImpact": "NOT_DEFINED",
"modifiedSubConfidentialityImpact": "NOT_DEFINED",
"modifiedSubIntegrityImpact": "NOT_DEFINED",
"modifiedUserInteraction": "NOT_DEFINED",
"modifiedVulnAvailabilityImpact": "NOT_DEFINED",
"modifiedVulnConfidentialityImpact": "NOT_DEFINED",
"modifiedVulnIntegrityImpact": "NOT_DEFINED",
"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:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"source": "disclosure@vulncheck.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-103262",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-06T00:08:34.189311Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-10-01T11:17:21.050",
"references": [
{
"source": "disclosure@vulncheck.com",
"url": "https://github.com/tornadoweb/tornado/commit/e412435febba4569c552c5c9054f1bf92bd171a9"
},
{
"source": "disclosure@vulncheck.com",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
},
{
"source": "disclosure@vulncheck.com",
"url": "https://www.vulncheck.com/advisories/tornado-before-6.5.9-denial-of-service-via-curlasynchttpclient"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-chx6-46f5-w4vp"
}
],
"sourceIdentifier": "disclosure@vulncheck.com",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-409"
}
],
"source": "disclosure@vulncheck.com",
"type": "Secondary"
}
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.