Python dependency CVEs: aiohttp, cryptography, curl-cffi need minimum version bumps

[shaun0927]

Summary

Several Python dependencies have known CVEs affecting versions currently allowed by pyproject.toml minimum version specifiers. Issue #9027 tracks JS-side dependency audit; this covers the Python side.

Affected packages

Package	Current spec	Installed	CVEs	Safe version
aiohttp	>=3.13.3 (messaging), >=3.9.0 (others)	3.13.3	CVE-2026-34518 (cookie/proxy-auth leak on cross-origin redirect), CVE-2026-34519 (response reason injection), CVE-2026-34520 (null bytes in headers), CVE-2026-34525 (multiple Host headers)	>=3.13.4
cryptography	(transitive)	46.0.4	CVE-2026-39892 (buffer overflow on non-contiguous buffers)	>=46.0.7
curl-cffi	(transitive)	0.13.0	CVE-2026-33752 (SSRF via redirect following)	>=0.15.0

Direct impact on hermes-agent

• aiohttp: Directly used by the gateway API server, all webhook platform adapters (Telegram, Discord, Slack, Matrix, Mattermost, WeCom, Feishu), and the ACP adapter. The cookie/auth leak on cross-origin redirect (CVE-2026-34518) is particularly relevant for the gateway which handles OAuth tokens.
• cryptography: Used transitively via PyJWT and other packages for JWT verification and TLS.
• curl-cffi: Used for HTTP requests with browser-like TLS fingerprints. The SSRF-via-redirect CVE is relevant since hermes-agent already has is_safe_url() protection that could be bypassed at the transport layer.

Note on PyJWT

pyproject.toml already specifies PyJWT[crypto]>=2.12.0 with a CVE-2026-32597 comment — good. The installed version (2.11.0) may lag behind the spec in existing environments; a pip install --upgrade or lockfile refresh would resolve this.

Suggested changes

# pyproject.toml
"aiohttp>=3.13.4,<4"        # was >=3.13.3 / >=3.9.0

For transitive dependencies (cryptography, curl-cffi), consider adding explicit lower bounds or running pip-audit in CI to catch regressions.

Related

• Issue Dependency audit: security and upgrade follow-ups #9027 — JS-side dependency audit
• Issue Security scan: ClawGuard found 688 findings #9867 — ClawGuard scan findings

[gnanirahulnutakki]

I validated the packaging surface locally and the clean source-level fix looks like this:

• raise anthropic floor in pyproject.toml to >=0.87.0,<1
• add an explicit cryptography>=46.0.7,<47 core dependency
  • Hermes imports cryptography directly in the WeCom/Weixin runtime paths today, so relying on PyJWT[crypto] to pull a safe transitive version is brittle
• raise all explicit aiohttp floors to >=3.13.4,<4
  • messaging
  • homeassistant
  • sms
• align the convenience requirements.txt
• add a packaging regression test so these floors don’t drift back down

I also confirmed the repo currently resolves:

• aiohttp==3.13.3
• anthropic==0.86.0
• cryptography==46.0.5
• curl-cffi==0.13.0
• pygments==2.19.2

One blocker from this environment: regenerating uv.lock is currently failing before it reaches these package upgrades because uv lock tries to resolve the RL git dependency (atroposlib @ git+https://github.com/NousResearch/atropos.git@...) and dies inside that repo’s submodule checkout when git-lfs is unavailable:

• git submodule update --recursive --init
• git-lfs filter-process: git-lfs: command not found
• fatal: Unable to checkout ... in submodule path 'environments/community/bleuberi/bleuberi-repo'

So the dependency floor patch itself is straightforward, but from a clean environment the lock refresh is blocked by the RL dependency path rather than the security bump itself.

[gnanirahulnutakki]

I opened #10784 to harden the dependency floors that Hermes can resolve today (anthropic, cryptography, aiohttp, cbor2, python-multipart, pytest, litellm, pillow) and to regenerate uv.lock with a packaging regression test.

After re-auditing the locked export, the remaining hit is PyNaCl 1.5.0 (CVE-2025-69277). That one is currently blocked by discord.py[voice] 2.7.1 still constraining PyNaCl<1.6, so I left it out of the PR rather than making messaging / all unsatisfiable.

[shaun0927]

Thanks for digging through the broader packaging surface and opening #10784.

That is a better upstream landing spot than my narrower aiohttp-only PR #10701 because it carries the wider floor corrections, lockfile refresh, and a regression test to keep the floors from drifting back down. To reduce duplicate review load, I'm closing #10701 and deferring to #10784 for this issue.

[alt-glitch]

Related to #10784 which already bumps dependency floors for several of these CVEs. The aiohttp floor bump to >=3.13.4 was addressed in closed #10701; remaining items (cryptography, curl-cffi) may need separate attention.

[shaun0927]

Quick status check against current origin/main (ec671c41):

• aiohttp: still split between >=3.13.3 (messaging) and >=3.9.0 (homeassistant, sms) in pyproject.toml. Not bumped to 3.13.4 yet on main. Harden dependency floors for vulnerable extras #10784 covers this but is still open.
• cryptography: still no explicit floor in pyproject.toml; >=46.0.7 is also pending in Harden dependency floors for vulnerable extras #10784.
• curl-cffi: no longer present anywhere in pyproject.toml or uv.lock on current main (grep -i curl uv.lock → 0 hits). Whatever brought it in transitively at the time of this issue has been removed in the meantime, so this part of the issue is effectively resolved without a floor bump being needed.

Happy to leave this open until #10784 lands for the aiohttp/cryptography pieces; once that merges this issue can probably be closed (modulo a follow-up if any extra had its floor missed).

[gnanirahulnutakki]

Rechecked this on April 30, 2026 against current upstream/main (0cf7d570e2be48e125d101c6a41aca837bb0b91c).

#10784 is still the landing PR for the unresolved pieces that are actually still live on main:

• raise the aiohttp floor to >=3.13.4 in messaging, homeassistant, and sms
• add the explicit cryptography>=46.0.7,<47 floor

I also re-ran the narrow packaging regression locally on the current branch:

/opt/homebrew/bin/python3.13 -m pytest -o addopts='' tests/test_packaging_metadata.py -q

Result: 3 passed.

I agree with the latest thread update that curl-cffi is no longer part of this issue on current main, so I would scope this issue to the still-pending aiohttp + cryptography floors. If maintainers want a narrower review unit than #10784, I can split that branch, but as of April 30, 2026 it is still the correct open PR for the remaining fixes.