fix(deps): bump urllib3, aiohttp, cryptography to patch disclosed CVEs - #4829
fix(deps): bump urllib3, aiohttp, cryptography to patch disclosed CVEs#4829aeonframework wants to merge 4 commits into
Conversation
- urllib3 2.5.0 -> 2.7.0: fixes GHSA-qccp-gfcp-xxvc (CVE-2026-44431, proxied-redirect header leak), GHSA-2xpw-w6gg-jr37 (CVE-2025-66471, streaming decompression-bomb), GHSA-38jv-5279-wg99 (CVE-2026-21441, decompression-bomb bypass via redirects), GHSA-gm62-xv2j-4w53 (CVE-2025-66418, unbounded decompression chain). Transitive dependency of the core requests dependency; no manifest change needed. - aiohttp 3.12.15 -> 3.14.3 (blaxel/cloudflare extras): clears 30 disclosed advisories, all fixed by the current release; within the existing aiohttp>=3.12,<4 declared range. - cryptography 45.0.7 -> 46.0.7 (encrypt extra + dev group): fixes GHSA-p423-j2cm-9vmq (CVE-2026-39892, CVSS 9.8 critical buffer overflow on non-contiguous buffer input to Hash.update()/similar). No 45.x release fixes this; required widening the declared range from <46 to <47. Not bundled: 4 residual cryptography advisories (GHSA-537c-gmf6-5ccf bundled vulnerable OpenSSL, GHSA-g6cj-pr64-35w5 PKCS#7 Bleichenbacher oracle, GHSA-jwv3-5hgf-82ww path-building DoS, GHSA-m2h6-j472-rp4c wildcard-DNS permittedSubtrees escape) need 48.0.1+/50.0.1, a much larger jump across several majors -- left as a follow-up rather than risk in this PR. litellm's open advisories have no fix available within this repo's own uv exclude-newer=7-days supply-chain freshness policy as of today; will resolve on its own once the fixed litellm release ages past that window.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 74d8a7efb5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| [[package]] | ||
| name = "aiohttp" | ||
| version = "3.12.15" | ||
| version = "3.14.3" |
There was a problem hiding this comment.
When a user upgrades openai-agents[cloudflare] or openai-agents[blaxel] in an environment that already contains a vulnerable aiohttp 3.12.x release, the unchanged aiohttp>=3.12,<4 requirements in pyproject.toml remain satisfied. This lockfile-only bump therefore protects repository development installs but not SDK consumers, even though these extras directly execute aiohttp networking code; raise both published extra constraints to the first remediated version (>=3.14.3).
AGENTS.md reference: AGENTS.md:L145-L148
Useful? React with 👍 / 👎.
sylvesterkaczmarek
left a comment
sylvesterkaczmarek
left a comment
There was a problem hiding this comment.
There’s the same consumer-side gap for urllib3. This only moves urllib3 to 2.7.0 in uv.lock; the published core requirement is still just requests>=2,<3, which can leave an already-installed vulnerable urllib3 2.5.0 in place. If this PR is meant to remediate the listed urllib3 CVEs for SDK users, the published dependency graph needs a safe urllib3 floor too, not only the dev lock.
The urllib3 CVEs this PR remediates are pulled in transitively via the core `requests` dependency, so bumping only uv.lock left the published dependency graph without a safe floor: an SDK consumer with urllib3 2.5.0 already installed would keep a vulnerable version. Add an explicit `urllib3>=2.7.0, <3` core dependency so a fresh install or upgrade cannot resolve below the highest disclosed fix (GHSA-qccp-gfcp-xxvc). Addresses review feedback from @sylvesterkaczmarek.
|
Thanks @sylvesterkaczmarek, you are right - the urllib3 CVEs come in transitively through |
seratch
left a comment
seratch
left a comment
There was a problem hiding this comment.
The published blaxel and cloudflare extras still allow aiohttp>=3.12,<4, so an SDK upgrade can retain an older installed aiohttp even though uv.lock selects 3.14.3. Please align the published requirements with the intended remediated floor, then validate the affected extras with the actual upgraded dependencies. The existing probe environment used the old versions and cannot establish that compatibility.
seratch
changed the title
…+ fix pyright WS generic Addresses @seratch's review on openai#4829. - Raise the published aiohttp requirement in the `blaxel` and `cloudflare` extras from `>=3.12,<4` to `>=3.14.3,<4` (and the matching specifiers in uv.lock) so an SDK upgrade cannot retain an aiohttp older than the remediated floor. 3.14.3 is the release that clears the disclosed advisories; the lock already resolves aiohttp to 3.14.3, so the resolution is unchanged. - Fix pyright typecheck failures introduced by aiohttp 3.14, which made `ClientWebSocketResponse` generic (default `Literal[True]`). Parameterize the three annotations in the Cloudflare PTY path to `ClientWebSocketResponse[bool]` to match `ClientSession.ws_connect`'s return type, resolving the assignment mismatch at sandbox.py:1149 and the cascading Optional-member-access errors.
|
Thanks @seratch, good catch. Fixed in f9f8107:
So the published requirements now match the intended remediated floor, and the affected |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f9f8107620
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| realtime = ["websockets>=15.0, <17"] | ||
| sqlalchemy = ["SQLAlchemy>=2.0", "asyncpg>=0.29.0"] | ||
| encrypt = ["cryptography>=45.0, <46"] | ||
| encrypt = ["cryptography>=46.0.7, <47"] |
There was a problem hiding this comment.
When a user upgrades the base openai-agents package without the encrypt extra in an environment containing vulnerable cryptography 45.x, this constraint is never evaluated. The base dependency graph already installs cryptography through mcp → PyJWT[crypto], whose looser requirement allows pip to retain 45.x; the lockfile upgrade therefore does not remediate those published installations. Add the safe cryptography>=46.0.7,<47 constraint to the core dependencies (or otherwise constrain the base graph), as was done for transitive urllib3.
AGENTS.md reference: AGENTS.md:L145-L147
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch, fixed in 7c54392. Confirmed the transitive path: base dep mcp>=1.19.0 requires pyjwt[crypto], which pulls cryptography into the base graph with no floor of its own, so a base openai-agents upgrade (without the encrypt extra) could retain vulnerable 45.x. Added cryptography>=46.0.7,<47 to the core dependencies (unmarked; the package is requires-python >= 3.10) plus the matching base requires-dist entry in uv.lock, mirroring the urllib3 base-floor already applied for the requests-transitive CVEs. Resolution graph is unchanged (already resolved to 46.0.7).
…pt extra Addresses the Codex P1 on openai#4829. cryptography reaches the base openai-agents dependency graph transitively via the core `mcp` dependency -> `pyjwt[crypto]`, whose own cryptography requirement is unpinned. The bump previously floored cryptography only in the `encrypt` extra and the dev group, so a base install or upgrade (no `encrypt` extra) could still resolve/retain vulnerable 45.x, leaving GHSA-p423-j2cm-9vmq (CVE-2026-39892, CVSS 9.8) unremediated for base users. Add `cryptography>=46.0.7,<47` to the core dependencies (unmarked; the package is already `requires-python >= 3.10`) and the matching base requires-dist entry in uv.lock. This mirrors the urllib3 base-floor already applied for the requests-transitive CVEs; the lock already resolves cryptography to 46.0.7, so the resolution graph is unchanged.
sylvesterkaczmarek
left a comment
sylvesterkaczmarek
left a comment
There was a problem hiding this comment.
Re-reviewed my earlier dependency-floor finding. pyproject.toml now publishes urllib3>=2.7.0,<3, and the lockfile is aligned at 2.7.0, so consumers cannot silently remain on the vulnerable 2.5.0 through requests. My previous blocker is resolved.
|
@seratch following up on this one. The aiohttp lower-bound you flagged should be covered now - the matching floor bump landed and the bot fix comment above reflects it. Could you re-check when you have a moment so this can unblock? Happy to adjust if anything is still off. |
3 participants
Automated dependency bump addressing several disclosed CVEs, found via dependency scanning and verified against the OSV database at the target versions before opening this PR.
Changes
2.5.0→2.7.0— transitive dependency of the corerequestsdependency. Fixes:GHSA-qccp-gfcp-xxvc(CVE-2026-44431, CVSS 8.2) — sensitive headers forwarded across origins in proxied low-level redirectsGHSA-2xpw-w6gg-jr37(CVE-2025-66471, CVSS 8.9) — streaming API mishandles highly compressed dataGHSA-38jv-5279-wg99(CVE-2026-21441, CVSS 8.9) — decompression-bomb safeguard bypass via redirectsGHSA-gm62-xv2j-4w53(CVE-2025-66418, CVSS 8.9) — unbounded links in the decompression chain3.12.15→3.14.3(blaxel/cloudflareextras) — within the existingaiohttp>=3.12,<4range. Clears 30 disclosed advisories (CVE-2025-692xx / CVE-2026-345xx series), all fixed as of this release.45.0.7→46.0.7(encryptextra + dev dependency group) — fixesGHSA-p423-j2cm-9vmq(CVE-2026-39892, CVSS 9.8 critical): a buffer overflow when a non-contiguous buffer (e.g.buf[::-1]) is passed to APIs likeHash.update()on Python >3.11. No45.xrelease fixes this advisory, so the declared range inpyproject.tomlneeded widening from>=45.0, <46to>=46.0.7, <47.Verified against
https://api.osv.dev/v1/queryat each target version — zero remaining advisories for urllib3 2.7.0 and aiohttp 3.14.3.Not fully remediated by this PR: cryptography 46.0.7 still carries 4 residual advisories that require a much larger jump (46.x → 48.0.1 for
GHSA-537c-gmf6-5ccf, bundled vulnerable OpenSSL; → a later release forGHSA-g6cj-pr64-35w5PKCS#7 Bleichenbacher oracle,GHSA-jwv3-5hgf-82wwduplicate-self-signed-intermediate path-building DoS, andGHSA-m2h6-j472-rp4cwildcard-DNSpermittedSubtreesescape — all clear only at50.0.1, the current latest). Spanning three more majors (47→50) is a larger compatibility surface than seemed appropriate to bundle here; happy to open that as a follow-up if useful. This PR's 46.0.7 landing was chosen specifically because it closes the one critical (9.8) advisory.litellm (
litellmextra) also has open advisories (e.g.GHSA-4xpc-pv4p-pm3w/CVE-2026-49468, CVSS 9.8) fixed in1.99.0, but this project'spyproject.tomlsets[tool.uv] exclude-newer = "7 days"as a deliberate supply-chain freshness policy, and1.99.0was published within that window as of this PR —uv lock --upgrade-package litellmcorrectly refuses to select it. Not bundled here since overriding that policy isn't this PR's call to make; it should resolve on its own once the fix ages past 7 days, or can be pulled forward explicitly viaexclude-newer-package = { litellm = false }if wanted sooner.Detected by osv-scanner, cross-checked against the OSV API. No code changes outside
pyproject.toml/uv.lock.Filed by Aeon.