← All CVEs NewScan detects
high

CVE-2026-73548

Envoy before 1.36.10 / 1.37.6 / 1.38.4 / 1.39.1: one advisory batch of six routing and access-control bypasses - a non-WebSocket upgrade is forwarded as a tunnel (request smuggling), HTTP RBAC is fooled by RFC-valid opaque header forms, path-parameter and dot-segment normalization disagree with the route matcher, and the admin /stats HTML view reflects unescaped input

Severity
high
Affected product
Envoy
Affected versions
Envoy < 1.36.10
Affected versions
Envoy ≥ 1.37.0, < 1.37.6
Affected versions
Envoy ≥ 1.38.0, < 1.38.4
Affected versions
Envoy ≥ 1.39.0, < 1.39.1
Fixed in
Envoy 1.36.10
Fixed in
Envoy 1.37.6
Fixed in
Envoy 1.38.4
Fixed in
Envoy 1.39.1
Added to NewScan
2026-09-22
Detected by
NewScan — free, self-hosted

How NewScan reports it

COMPONENT VERSION RANGE

NewScan fingerprints Envoy from its response and reports this CVE when the detected version falls inside the affected range below.

Added 2026-09-22 (/daily-cve). Version-gated on the tech_signatures "Envoy" row's /server_info version_from added in the same batch - Envoy's `Server: envoy` banner carries no version, so this product was bucket [C] (permanently dead for known_vulns rows) until that measurement; see that row for it. FOUR ROWS, NOT ONE, because the advisories fix four maintained branches at once and state affected as "prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1": a single `lt 1.39.1` would flag a patched 1.36.10 and a patched 1.37.6 as vulnerable, which is a false positive on every up-to-date install not on the newest branch. Each row is one branch window and `ge` pins its floor. ONE PRIMARY cve PER ROW WITH THE OTHER FIVE IN `cves`, because the six ids are one advisory batch with one identical fixed-version set and one remediation - upgrade - so six separate rows per branch would be twenty-four rows saying the same sentence. 73548 is primary as the highest-impact of the six (the upgrade-tunnel smuggle). The admin-interface XSS 73546 ALSO appears on the interfaces.json `envoy` row, deliberately: that row detects its precondition (an anonymously reachable admin interface) without version-matching it, this one version-matches it without needing the admin interface reachable - except that in practice the version_from reads the admin interface too, so on a locked-down Envoy both stay silent rather than guessing. VERSION-MATCH ONLY: proving any of the six means smuggling a request past somebody's production edge proxy. MEASURED 2026-09-22 against envoyproxy/envoy:v1.31-latest: /server_info yields 1.31.10, below this row's `lt`, and the row fires - the positive case on a real build, not a synthetic banner.

COMPONENT VERSION RANGE

NewScan fingerprints Envoy from its response and reports this CVE when the detected version falls inside the affected range below.

The 1.37 branch window of the four-branch batch described on the `lt 1.36.10` row above - same six ids, same fix, different maintained branch. `ge` is what keeps this row off a 1.36.x install that the first row already judges correctly.

COMPONENT VERSION RANGE

NewScan fingerprints Envoy from its response and reports this CVE when the detected version falls inside the affected range below.

The 1.38 branch window of the four-branch batch described on the `lt 1.36.10` row above - same six ids, same fix, different maintained branch.

COMPONENT VERSION RANGE

NewScan fingerprints Envoy from its response and reports this CVE when the detected version falls inside the affected range below.

The newest branch window of the four-branch batch described on the `lt 1.36.10` row above - same six ids, same fix. An install at or above 1.39.1 matches no row here, which is the negative case the four-window split exists to get right.

References

Scan for this yourself — local, in-band scanning is free.

Get NewScan (FREE) →