Fixes:
mint 1.10.0 - EEF-CVE-2026-92103 (MEDIUM)
aka: CVE-2026-92103, GHSA-q95c-ccq6-j5j6
Mint HTTP/2 client buffers oversized frames up to 16 MiB before enforcing max_frame_size
https://osv.dev/vulnerability/EEF-CVE-2026-92103
mint 1.10.0 - EEF-CVE-2026-82672 (MEDIUM)
aka: CVE-2026-82672, GHSA-rj5m-69wp-cxq9
Unvalidated chunk-size line tail in Mint HTTP/1 client enables response smuggling against strict intermediaries on pooled connections
https://osv.dev/vulnerability/EEF-CVE-2026-82672
mint 1.10.0 - EEF-CVE-2026-91043 (HIGH)
aka: CVE-2026-91043, GHSA-9x8p-qrf4-jq7g
HPACK-indexed cookie fields in Mint HTTP/2 responses bypass max_header_list_size and exhaust client memory
https://osv.dev/vulnerability/EEF-CVE-2026-91043
mint 1.10.0 - EEF-CVE-2026-94194 (MEDIUM)
aka: CVE-2026-94194, GHSA-gvrc-75rc-7gj9
Mint HTTP/1 client applies chunked framing when chunked is not the final transfer coding, enabling response smuggling through intermediaries
https://osv.dev/vulnerability/EEF-CVE-2026-94194
Fixes:
mint 1.9.3 - EEF-CVE-2026-82729 (MEDIUM)
aka: CVE-2026-82729, GHSA-7p8w-j234-7qc8
Quadratic chunk-size parsing in Mint.HTTP1.Parse allows CPU-exhaustion DoS
https://osv.dev/vulnerability/EEF-CVE-2026-82729
mint 1.9.3 - EEF-CVE-2026-82728 (HIGH)
aka: CVE-2026-82728, GHSA-g83f-2j6r-q6m4
Unbounded HTTP/1 status-line and chunk-extension buffering in Mint causes memory-exhaustion DoS
https://osv.dev/vulnerability/EEF-CVE-2026-82728
An unpooled Hackney 4 connection that ends without a reusable socket -- a
body cut short by the peer, a bodyless 204/304, or a failed read -- parks
in its `closed` state forever, holding every refc binary it read.
read_full_body/2 hands back `socket = undefined`, so it never reaches the
reuse check; `closed(enter)` arms a stop timer only for pooled
connections; and an unpooled connection is owned by hackney_conn_sup, so
the owner-DOWN cleanup never fires.
Nothing here can work around it. Since 4.0 Hackney ignores `with_body`
and always returns a fully read binary, so a synchronous request never
yields a handle to close, and the short read still reports {:ok, body}.
Media proxy warming hits this whenever an attachment fetch is cut short
and the outbound proxy is used as a CONNECT tunnel, since tunnels are
never pooled.
Pin the fix, a single commit on top of the 4.7.2 tag, until it ships in a
release. While it is a git dep Hackney drops out of `mix deps.audit` and
`mix hex.outdated`, so this wants moving back to hex promptly.
benoitc/hackney#918, benoitc/hackney#919
Conflict resolution notes:
- mix.lock: kept this branch's versions for cowlib, h2, hackney and hpax.
Those upgrades are the point of the branch; develop is still on hackney
1.20.1.
- .woodpecker/docker-armv7.yaml: accepted develop's deletion. It only
existed here to build mdex_native on armv7, and mdex was already
replaced with earmark again.
- lib/pleroma/reverse_proxy.ex: took develop's version. It independently
grew request_with_constraints/5 and the invalid-status close, which
supersede the equivalent fixes on this branch. Re-applied this branch's
recv_timeout seeding, which develop does not have.
- lib/pleroma/gun/connection_pool/worker.ex and
lib/pleroma/reverse_proxy/client/tesla.ex: took develop's versions. The
gun pool rework (#7934) already guards the demonitor and makes
release_conn/cancel_stream exit-safe, and it splits the Tesla client's
graceful release from its abort path, so this branch's changes there are
obsolete.
That leaves the client leak fix as a Hackney-only concern, which
stream_body/1 now handles the same way the gun client does.
It appears the implementation of Happy Eyeballs in 1.22.0 is the origin of
some pretty serious performance regressions that remain even in the latest
Hackney 3.0 branch.
Connection tests:
=== 1.22.0 ===
First call: 9434ms
Second call: 14ms
=== 1.21.0 ===
First call: 228ms
Second call: 16ms
We went back further to 1.20.1 though because of reported problems with the mail
client and ssl_options. That bug was not reproduced by a dev, though, but we'll
trust it for now.
