https://foxio.io/blog/header-accordions-qpack-amplification-attacks-against-http-3-servers reports: A remote, unauthenticated client can force an HTTP/3 server to allocate tens to thousands of times more memory than it sends. One connection is enough to OOM or pin a default-configured server. Seven of the ten implementations tested are vulnerable; several are already fixed.

QPACK compresses HTTP/3 headers to minimize traffic sent over the wire. Across the affected implementations, decoded-header limits are missing, incomplete, or applied too late. A small HEADERS frame can therefore expand into hundreds of thousands of header objects in memory. Preventing that expansion from exhausting resources requires enforcing a cumulative budget as fields are decoded and retained.

Patched as of October 20, 2026 ==============================

Library Fixed version Advisory ------- ------------- -------- quic-go 0.57.0 CVE-2025-64702

Cloudflare quiche 0.29.3 CVE-2026-12523

lsquic 4.9.0 no CVE

Wireshark 4.6.2 / 4.4.12 CVE-2025-13945

Unpatched as of October 20, 2026 ================================

Library ------- Bun 1.4.3

h3 (hyperium)

aioquic / mitmproxy

Mitigations ===========

Bun: Don't expose HTTP/3 servers

mitmproxy: disable HTTP/3 (pass --set http3=false)

h3 crate: set a reasonable maxfieldsectionsize

Not affected: IIS, Envoy, ngtcp2/nghttp3 https://foxio.io/blog/header-accordions-qpack-amplification-attacks-against-http-3-servers goes into much more detail after providing that summary.

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Impact In mitmproxy 12.2.1 and below, the builtin LDAP proxy authentication does not correctly sanitize the username when querying the LDAP server. This allows a malicious client to bypass authentication.

Only mitmproxy instances using the proxyauth option with LDAP are affected. This option is not enabled by default.

Patches

The vulnerability has been fixed in mitmproxy 12.2.2 and above.

Acknowledgements

We thank Yue (Knox) Liu (@yueyueL) for responsibly disclosing this vulnerability to the mitmproxy team.

Timeline

- 2025-12-08: Received initial report. - 2025-12-09: Verified report and confirmed receipt. - 2026-01-02: Informed researcher that patch will be part of the next regular patch release. - 2026-04-12: Published patch release and advisory.

Impact

In mitmproxy 7.0.4 and below, a malicious client or server is able to perform HTTP request smuggling attacks through mitmproxy. This means that a malicious client/server could smuggle a request/response through mitmproxy as part of another request/response's HTTP message body. While mitmproxy would only see one request, the target server would see multiple requests. A smuggled request is still captured as part of another request's body, but it does not appear in the request list and does not go through the usual mitmproxy event hooks, where users may have implemented custom access control checks or input sanitization.

Unless you use mitmproxy to protect an HTTP/1 service, no action is required.

Patches

The vulnerability has been fixed in mitmproxy 8.0.0 and above.

Acknowledgements

We thank Zeyu Zhang (@zeyu2001) for responsibly disclosing this vulnerability to the mitmproxy team.

Timeline

- 2022-03-15: Received initial report. - 2022-03-15: Verified report and confirmed receipt. - 2022-03-16: Shared patch with researcher. - 2022-03-16: Received confirmation that patch is working. - 2022-03-19: Published patched release and advisory.

Impact

In mitmproxy 7.0.2 and below, a malicious client or server is able to perform HTTP request smuggling attacks through mitmproxy. This means that a malicious client/server could smuggle a request/response through mitmproxy as part of another request/response's HTTP message body. While mitmproxy would only see one request, the target server would see multiple requests. A smuggled request is still captured as part of another request's body, but it does not appear in the request list and does not go through the usual mitmproxy event hooks, where users may have implemented custom access control checks or input sanitization.

Unless you use mitmproxy to protect an HTTP/1 service, no action is required.

Patches

The vulnerability has been fixed in mitmproxy 7.0.3 and above.

Acknowledgements

We thank João Sobral (@chinchila) for responsibly disclosing this vulnerability to the mitmproxy team.

Timeline

- 2021-09-08: Received initial report for mitmproxy <= 6.0.2. - 2021-09-08: Requested clarification if 7.x is affected. - 2021-09-10: Received additional details, 7.x situation still unclear. - 2021-09-13: Internally determined that 7.x is also affected. - 2021-09-13: Shared initial fix with researcher. - 2021-09-14: Received confirmation that fix is working, but H2.TE/H2.CL should also be looked at. - 2021-09-14: Shared revised fix that includes additional H2.TE mitigations. - 2021-09-14: Received confirmation that revised fix is working. - 2021-09-16: Completed internal patch review. - 2021-09-16: Published patch release and advisory.

mitmweb in mitmproxy before v4.0.4 allows DNS Rebinding attacks, related to tools/web/app.py.