chore(deps): bump aiohttp to clear security advisories

[EvilHumphrey]

What

Bump aiohttp 3.13.3 → 3.14.0 to clear all outstanding security advisories OSV flagged against the locked version.

Touches the exact pin in pyproject.toml (4 extras) and re-resolves uv.lock scoped to aiohttp only. No other package moves.

Why — headline: a 9.1 Critical

The locked aiohttp 3.13.3 carries 12 known advisories, led by a CVSS 9.1 Critical:

GHSA-63hf-3vf5-4wqf (CVE-2026-34520) — 9.1 Critical — aiohttp's C parser (llhttp) accepts null bytes and control characters in response headers, enabling HTTP response splitting / request smuggling.

Most of these are fixed in 3.13.4, but two require 3.14.0, so 3.14.0 is the minimum version that clears the entire set:

• GHSA-hg6j-4rv6-33pg (CVE-2026-47265) — cross-origin redirect leaks per-request cookies (confidentiality: High). Fixed in 3.14.0.
• GHSA-jg22-mg44-37j8 (CVE-2026-34993) — deserialization of untrusted data. Fixed in 3.14.0.

All advisories cleared (aiohttp 3.13.3 → 3.14.0)

GHSA	CVE	Severity	Summary
GHSA-63hf-3vf5-4wqf	CVE-2026-34520	9.1 Critical	llhttp accepts null bytes / control chars in response headers (response splitting)
GHSA-p998-jp59-783m	CVE-2026-34515	High	UNC SSRF / NTLMv2 credential theft / local file read in static resources
GHSA-hg6j-4rv6-33pg	CVE-2026-47265	High	Cross-origin redirect with per-request cookies (cookie leak) — needs 3.14.0
GHSA-jg22-mg44-37j8	CVE-2026-34993	Moderate	Deserialization of untrusted data — needs 3.14.0
GHSA-m5qp-6w8w-w647	CVE-2026-34516	Moderate	Multipart header size bypass (availability)
GHSA-966j-vmvw-g2g9	CVE-2026-34518	Moderate	Leaks Cookie / Proxy-Authorization headers on cross-origin redirect
GHSA-2vrm-gr82-f7m5	CVE-2026-34514	Moderate	CRLF injection via multipart part content-type header construction
GHSA-3wq7-rqq7-wx6j	CVE-2026-34517	Moderate	Late size enforcement for non-file multipart fields → memory DoS
GHSA-c427-h43c-vf67	CVE-2026-34525	Moderate	Accepts duplicate Host headers (request smuggling surface)
GHSA-hcc4-c3v8-rx92	CVE-2026-34513	Moderate	Unbounded DNS cache in TCPConnector → DoS
GHSA-mwh4-6h8g-pg8w	CVE-2026-34519	Moderate	HTTP response splitting via \r in reason phrase
GHSA-w2fm-2cpv-w7v5	CVE-2026-22815	Moderate	Unlimited trailer headers → uncapped memory usage

OSV verification: aiohttp 3.13.3 → 12 advisories; aiohttp 3.14.0 → 0 advisories.

Changes

• pyproject.toml — bump the exact pin aiohttp==3.13.3 → aiohttp==3.14.0 in the 4 extras that declare it: messaging, slack, homeassistant, sms. (The pin had to move because uv lock --upgrade-package cannot cross an == constraint. Kept exact-pin style to match the file's convention; the all / termux-all aggregates inherit the new pin via homeassistant/sms.)
• uv.lock — re-resolved with uv lock --upgrade-package aiohttp. The only package version that changed is aiohttp (3.13.3 → 3.14.0); the rest of the diff is aiohttp's own wheel/hash set plus the root project's requires-dist metadata recording the new specifier.

Validation

• uv lock --check → lockfile is in sync (pre-validates the uv-lockfile-check.yml CI gate).
• CI (test suite + uv-lockfile-check) validates runtime compatibility of the 3.13.3 → 3.14.0 minor bump.
• No uv sync / install / test execution was run locally — this is a resolution-only lockfile change.

[EvilHumphrey]

Both red checks here look transient/unrelated to this change — not the aiohttp bump:

test (4) — the single failure (1 of 4358) is tests/gateway/test_telegram_topic_mode.py::test_group_new_keeps_existing_reset_semantics_when_dm_topic_mode_enabled, a Telegram session-reset text assertion that doesn't exercise aiohttp. It passed on a sibling PR (#39450) cut from the same base minutes apart, so it reads as a flake.

nix (macos-latest) (not a required check) — aiohttp 3.14.0 downloaded and built fine on macOS; the job then failed fetching an unrelated dependency (uv-0.11.2) from cache.nixos.org with HTTP 416 / Failed sending data to the peer — a binary-cache networking blip ("usually happens due to networking issues"). nix (ubuntu-latest) (required) and uv lock --check both passed.

Could a maintainer re-run the two failed jobs when convenient? Both should go green on a retry. Happy to rebase onto fresh main for a clean run if that's easier.

[EvilHumphrey]

Follow-up commit (abdf1b3fd): bumps tools/lazy_deps.py's lazy Slack aiohttp pin 3.13.4 → 3.14.0, so the lazy-install path can't pull a still-vulnerable aiohttp independently of pyproject.toml / uv.lock.

Hermes' lazy deps use exact pins and can install/downgrade a package on their own, so the manifest bump alone wasn't enough: OSV shows aiohttp 3.13.4 still carries 2 advisories (CVE-2026-47265, CVE-2026-34993), while 3.14.0 clears the full set. With this, every aiohttp resolution path — pyproject.toml extras, uv.lock, and the lazy Slack install — lands on 3.14.0 (0 advisories).

[tonydwb]

Code Review Summary

Verdict: Approved

Straightforward dependency security bump: aiohttp 3.13.3 → 3.14.0, clearing multiple CVEs (CVE-2026-34513/34518/34519/34520/34525 and others). All extras (messaging, slack, homeassistant, sms) updated consistently.

Looks Good

• Version bump is consistent across pyproject.toml, lazy_deps.py, and uv.lock.
• The comment in lazy_deps.py accurately reflects what the new version clears.
• No API changes expected from a patch/minor upgrade within aiohttp 3.x.

No concerns

• Standard security maintenance.

---

Reviewed by Hermes Agent

[EvilHumphrey]

Rebased onto current main, conflicts resolved, CI green.

Re-framing since main has moved: it's now on aiohttp==3.13.4 (a partial bump), which per OSV still carries CVE-2026-47265 and CVE-2026-34993. This PR takes it to 3.14.0, clearing the full set — across pyproject.toml, uv.lock, and the lazy Slack pin in tools/lazy_deps.py (which can otherwise pull a still-vulnerable aiohttp independently of the manifest). So it now completes the in-progress 3.13.x hardening rather than duplicating it.

Small and self-contained, type/security. Thanks for taking a look!

[austinpickett]

Closing as superseded — aiohttp 3.14.0 is the canonical bump in #42334 (already approved), which also covers the full CVE set including 34520 (9.1). Thanks for the contribution!