Skip to content

chore(general): allow aiohttp 3.14 by widening the version range#7578

Open
isaacschepp wants to merge 1 commit into
bridgecrewio:mainfrom
isaacschepp:fix/aiohttp-3.14-cap
Open

chore(general): allow aiohttp 3.14 by widening the version range#7578
isaacschepp wants to merge 1 commit into
bridgecrewio:mainfrom
isaacschepp:fix/aiohttp-3.14-cap

Conversation

@isaacschepp

@isaacschepp isaacschepp commented Jun 12, 2026

Copy link
Copy Markdown

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Description

aiohttp 3.13.x has two known vulnerabilities — CVE-2026-34993 (GHSA-jg22-mg44-37j8, deserialization of untrusted data) and CVE-2026-47265 (GHSA-hg6j-4rv6-33pg, cross-origin redirect with per-request cookies) — and both are only fixed in 3.14.0. The current <3.14.0 cap makes it impossible for any consumer to resolve the fixed aiohttp alongside checkov (pip reports ResolutionImpossible), and Dependabot security PRs in downstream repos fail because of it.

This PR widens the range to >=3.8.0,<4.0.0 (matching the next-major cap style used for the other dependencies) rather than requiring >=3.14.0, because aiohttp 3.14 requires Python >=3.10 while checkov still supports 3.9:

  • Environments on Python 3.10+ can now resolve aiohttp 3.14.x and clear the CVEs.
  • Python 3.9 environments keep resolving 3.13.x, so nothing breaks there.

Two things worth calling out:

  1. Pipfile.lock is intentionally untouched. It still pins aiohttp 3.13.5 (installable on every supported Python). Notably, its _meta hash already corresponds to the >=3.8.0,<4.0.0 range: the lock was generated before the cap was tightened to <3.14.0 in feat(general): verify ECDSA-P256 signatures on external custom checks before loading #7556, and was never re-locked after. This PR restores Pipfile↔lock hash consistency (verified with pipenv's calculate_pipfile_hash).

  2. The only aiohttp 3.14 incompatibility found is in test tooling, not checkov. aioresponses cannot construct a mocked response under aiohttp >=3.14 (its mock ClientResponse is missing the new required stream_writer argument — issue with aiohttp-3.14 pnuckowski/aioresponses#289, fix PRs pending upstream). The single test that mocks a successful aiohttp response (test_aiohttp_client_session_wrapper_with_one_handled_exception) is now skipped only on that specific combination, with a version guard that deactivates automatically once aioresponses ships a release newer than 0.7.8. This matters for the CI jobs that run pipenv install --skip-lock (Python 3.12/3.13) and would otherwise pull aiohttp 3.14 and fail on the mocking library. The exception-only aioresponses tests are unaffected.

Verification performed:

  • tests/common/utils/test_http_utils.py with aiohttp 3.13.5: 16 passed (skip stays dormant).
  • Same file with aiohttp 3.14.0: 15 passed, 1 skipped.
  • End-to-end checkov -d <terraform dir> scan with aiohttp 3.14.0: works.
  • Checkov's only use of an API deprecated in 3.14 is aiohttp.BasicAuth in http_utils.py, which is slated for removal only in aiohttp 4.0 — safely inside the new <4.0.0 cap.

Fixes #7577

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added tests that prove my feature, policy, or fix is effective and works

aiohttp 3.13.x has two known vulnerabilities (CVE-2026-34993,
CVE-2026-47265) that are only fixed in 3.14.0, but the <3.14.0 cap
prevents any consumer from resolving the fixed version alongside
checkov.

Widen the range to >=3.8.0,<4.0.0 instead of requiring >=3.14.0
because aiohttp 3.14 needs Python >=3.10 while checkov still supports
3.9 - environments on 3.10+ can now resolve 3.14.x, while 3.9 keeps
3.13.x. Pipfile.lock is untouched: it still pins 3.13.5 (installable
everywhere) and its _meta hash already corresponds to the <4.0.0
range that was in the Pipfile before the cap was added.

The only 3.14 incompatibility is in tests: aioresponses cannot build
a mocked response for aiohttp>=3.14 (pnuckowski/aioresponses#289), so
the one test that mocks a successful aiohttp response is skipped on
that combination until aioresponses ships a fix. checkov's own
aiohttp usage is unaffected (verified: full test_http_utils pass on
3.13.5, 15 pass/1 skip on 3.14.0, end-to-end scan works on 3.14.0).

Fixes bridgecrewio#7577
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Update aiohttp to >=3.14.0

1 participant