Hackney 4.9 enforces max_body while it reads and returns
{:error, {:closed, partial}} for a truncated body; the hackney
regression tests now pin that. The certifi override goes, as
hackney itself now asks for certifi ~> 2.18.0.
A token with only the profile scope can call verify_credentials, as in
Mastodon 4.3. The answer is the public account, so apps can use it to
log users in without seeing their email or settings.
Hackney 4 reads every response completely before Pleroma can check its
size, so max_body no longer limits downloads or memory there; Gun stops
at the limit. Document the Hackney limitation for those who switch back.
FastSanitize checks the scheme with URI.parse/1, which finds none in
java<TAB>script:alert(1). Browsers remove tabs and newlines and leading
control characters first and run it as a javascript: link. The scrubbers
now use Pleroma.HTML.URIAttributes, which normalizes the URL the same
way before the scheme check.
Hackney 4 negotiates HTTP/2 and shares one connection per host. The
media proxy closes a response with :hackney.close/1, which stops the
whole connection, so parallel downloads from one host broke each other.
ConfigDB turns a numeric proxy host into an IP tuple. Hackney 1 took it,
Hackney 4 ignores such a proxy and connects directly, which skips a
SOCKS proxy (Tor) without any error.
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
Mint trusts the OTP CA store, which comes from the OS. Load the CAStore
bundle into it when Finch starts, so Finch trusts the same roots as the
other adapters.
The TLS version override replaced all Hackney TLS defaults. On OTP 26+
this fails with cacerts: :undefined; on older OTP it skipped certificate
checks. Closes#7962 on the public tracker.
Hackney trusts its own certifi bundle, which still has the roots of the
compromised eMudhra intermediate CAs. Pass explicit ssl_options with the
CAStore bundle. Hackney drops all its TLS defaults when ssl_options are
given, so keep peer and hostname checks in the options.
Also splits generic dependencies into elixir/erlang and the rest.
Generic depenencies then import the elixir/erlang snippets to preserve
previous layout.
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
