[Vidit Ostwal (Vidit-Ostwal)]

Summary

Raise the aiohttp security override from 3.14.3 to 3.14.4+, resolving GHSA-5wr8-gcqf-gqf3, GHSA-2g87-pp6c-29x5, and GHSA-494j-54xm-rwp3. The lock resolves to aiohttp 3.14.5.

Commits

• 2371b4cf3 updates the aiohttp floor and regenerated lockfile.

Verification

• uv lock --check
• CI-equivalent uv run pip-audit
• git diff --check

---

Note

Low Risk
Dependency-only security pin and lock refresh with no application code changes; minor risk from aiohttp/yarl patch upgrades in HTTP client paths.

Overview
Raises the workspace aiohttp security floor from >=3.14.3 to >=3.14.4 in pyproject.toml override-dependencies and documents that 3.14.3 and below are affected by GHSA-5wr8-gcqf-gqf3, GHSA-2g87-pp6c-29x5, and GHSA-494j-54xm-rwp3.

uv.lock is regenerated so the resolved aiohttp version moves to 3.14.5 (above the new minimum) and the transitive yarl pin updates to 1.25.1.

^{Reviewed by Cursor Bugbot for commit 0c9e86f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[strix-security]

Strix Security Review

Warning

This pull request has 3 commits after the last Strix review (2371b4c). Strix has not reviewed these changes.
Automatic review on push is off for this repository. To review the latest changes, tag @strix-security in a comment, or turn on re-review on push.

No security issues found.

Review summary

The PR only raises the aiohttp override floor from 3.14.3 to 3.14.4 in pyproject.toml and regenerates uv.lock, which resolves aiohttp to 3.14.5 and pulls the transitive yarl from 1.24.2 to 1.25.1; no application code is touched.

Verification of the change rather than a source review: the three advisories named in the PR (GHSA-5wr8-gcqf-gqf3 / CVE-2026-111064, GHSA-2g87-pp6c-29x5, GHSA-494j-54xm-rwp3 / CVE-2026-111063) each declare a single fixed version of 3.14.4, and OSV queries confirm 3.14.3 is flagged by all three while 3.14.4 and 3.14.5 are flagged by none — so the declared floor fully remediates the advisories instead of leaving one of them open above the new minimum. Every artifact hash and size in the regenerated lock for aiohttp and yarl matches the published PyPI metadata (79/79 and 70/70, zero mismatches), and uv lock --check resolves the lock consistently, so no tampered or mismatched artifact was introduced. No security-relevant issue found in the changed code.

_{Updated for 2371b4c.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[CrewAI AMP (CrewAI-AMP)]

Security review: no verified findings

The root workspace dependency policy raises the uv override for aiohttp from >=3.14.3 to >=3.14.4 and records three advisories affecting aiohttp through 3.14.3 (crewAIInc/crewAI:pyproject.toml:226-230,296-316). The changed-file list also reports a regenerated uv.lock, but that file was not available through the repository code reader at the PR head, so the claimed aiohttp 3.14.5 and yarl 1.25.1 resolutions could not be independently confirmed; no application code or published package dependency declaration was changed.

Who can reach the change (3)

• crewAIInc/crewAI:pyproject.toml:316: none; this is a dependency-resolution input read by uv when a developer, CI job, or package build resolves or synchronizes the repository workspace; held by Anyone able to run uv against a checkout of this workspace. GitHub Actions also reads it on pull requests, pushes to main, scheduled vulnerability scans, scheduled cache builds, and manual cache-build dispatches (crewAIInc/crewAI:.github/workflows/tests.yml:3-4,59-67; crewAIInc/crewAI:.github/workflows/vulnerability-scan.yml:3-9,68-76; crewAIInc/crewAI:.github/workflows/build-uv-cache.yml:3-12,28-38). There is no runtime caller credential to create or hand out.
• crewAIInc/crewAI:lib/crewai-tools/src/crewai_tools/tools/brightdata_tool/brightdata_dataset.py:550: BRIGHT_DATA_API_KEY in the process environment; _run rejects execution when it is absent, and get_dataset_data_async sends it as Authorization: Bearer to Bright Data; held by A local user, agent, or hosted crew that installs crewai-tools, selects BrightDataDatasetTool, and supplies a Bright Data API token. The repository instructs the user to sign up at brightdata.com and create the token and zone there (crewAIInc/crewAI:docs/edge/en/tools/web-scraping/brightdata-tools.mdx:18-24); creation and handout code is external to the repositories in scope and was not found in crewAIInc/crewai-oauth, crewAIInc/crewai-plus, crewAIInc/crewAI-enterprise, or crewAIInc/infra.
• crewAIInc/crewAI:conftest.py:104: none; pytest imports the repository conftest and applies the aiohttp/vcrpy compatibility patch during test startup; held by Developers running pytest and GitHub Actions pull-request test jobs. The test workflow checks out the submitted code, synchronizes the workspace, and runs pytest for crewai and crewai-tools (crewAIInc/crewAI:.github/workflows/tests.yml:3-4,42-67,75-112); there is no credential to create or hand out.

Connected applications (4)

• crewAIInc/crewai-plus -> crewAIInc/crewAI: crewai-plus builds its production image with the crewai CLI installed from a private enterprise uv index at CREWAI_VERSION=1.15.27. A workflow edits that Dockerfile pin when a CrewAI version is bumped, so PR #8288 reaches AMP only after publication and a corresponding pin update; the current default branch does not consume the PR-head workspace resolution.
• crewAIInc/crewai-plus -> crewAIInc/crewAI-enterprise: AMP provisioning passes CREWAI_VERSION into customer automation builds and, in the located Kubernetes CodeBuild path, installs crewAI-enterprise from that Git tag. Enterprise has a direct crewai dependency in its deployment-e2e package and its own uv dependency policy, but no code showing that its current default-branch runtime resolves aiohttp from PR #8288 was found.
• crewAIInc/crewAI-enterprise -> crewAIInc/crewAI: Enterprise consumes released crewai packages, including a crewai>=1.15.2 dependency in its deployment-e2e package. Its root resolver separately constrains multidict because it is transitive through aiohttp/yarl, but no aiohttp floor matching PR #8288 appears in Enterprise's override list.
• crewAIInc/infra -> crewAIInc/crewai-plus: Infra creates the platform ECR repository and runs its latest image as the AMP web ECS service; a public-subnet ALB fronts that service. Because the crewai CLI is installed inside the crewai-plus image, an AMP image rebuilt after a CrewAI pin update is the deployment path by which this dependency change can reach the hosted platform.

Coverage

Areas examined: Dependencies and Supply Chain, Infrastructure and Deployment, Secrets and Cryptography, AI Agent and LLM Risks.

• Checked pyproject.toml dependency override from lines 220-320 in crewAIInc/crewAI to confirm that aiohttp is pinned to >=3.14.4, avoiding vulnerable versions up to 3.14.3; this change improves the security floor and does not introduce a weaker patched version.
• Reviewed BrightDataDatasetTool in lib/crewai-tools/src/crewai_tools/tools/brightdata_tool/brightdata_dataset.py lines 400-599, which uses aiohttp for HTTP calls passing the BRIGHT_DATA_API_KEY from environment variable only via Authorization Bearer header; no new abstraction or transport method changes were introduced by the PR, so the update to aiohttp does not regress secrets handling or authz validation.
• Examined conftest.py lines 90-110 where aiohttp and vcrpy compatibility patches apply; no change by the PR, so compatibility is maintained with the updated aiohttp package.
• Verified that crewAI-enterprise lib/deployment-e2e/pyproject.toml pins crewai dependency at 1.15.2 and does not yet consume updated aiohttp constraints from this PR scope, confirming no immediate reaching of new dependency resolution by Enterprise without version bump.
• Inspected crewai-plus DockerfileMultiStage lines 20-40 confirming crewai CLI installed at version 1.15.27 from private index; this image does not yet consume updated aiohttp resolution from PR #8288, meaning rollout depends on publication and pin update.
• Checked infra applications/platform/ecs.tf lines 120-150 where AMP platform running the crewai-plus image is declared; no direct dependency or exposure to changed aiohttp version occurs here, as it relies on the image build and orchestration rather than direct runtime usage of aiohttp.
• Checked pyproject.toml override of aiohttp version to confirm dependency upgrade is correctly scoped and does not expose unsafe versions; found no unsafe downgrade or partial override that would allow an older vulnerable aiohttp version.
• Checked lib/crewai-tools/src/crewai_tools/tools/brightdata_tool/brightdata_dataset.py for any change introduced or error in handling of BRIGHT_DATA_API_KEY or aiohttp usage; the PR did not change this file and the existing implementation correctly reads the API key from environment, requiring it, and uses it in Authorization headers over HTTPS POST/GET; no secrets exposed in logs or URLs; input parameters are dynamically added but no direct unsanitized user input to aiohttp internals beyond construction, consistent with prior safe patterns.
• Checked conftest.py patch for vcrpy and aiohttp compatibility which runs at test startup; no change from PR; verified that this patch restores expected aiohttp behavior for tests and does not expose unsafe paths or secrets.
• Checked infra repository ECS and ALB configuration related to deployment of AMP platform and crewai-plus image; current deployment pulls pinned crewai CLI version 1.15.27 and does not automatically consume the PR's dependency bump, so the new aiohttp version does not reach runtime until explicit image rebuild and pin bump.
• Checked cross-repository linkage for dependency resolution and package publication workflows; verified that deployment and runtime resolution paths enforce pinned versions and controlled package indexes, preventing partial rollout or mixed dependency versions.
• Validated that BrightDataDatasetTool's network boundary is unchanged, its authorization depends solely on environment-held BRIGHT_DATA_API_KEY, which is a secret read from environment and not exposed elsewhere.
• Confirmed no added or changed code enables unsafe access or control over aiohttp configuration or secrets in transport, request, or response processing.
• Checked pyproject.toml dependency update in crewAIInc/crewAI to confirm no introduction of secret exposure or weaker cryptography directly; only bumps aiohttp minimum from 3.14.3 to 3.14.4
• Checked lib/crewai-tools/src/crewai_tools/tools/brightdata_tool/brightdata_dataset.py methods that use BRIGHT_DATA_API_KEY environment variable and aiohttp client session; confirmed API key is read from environment and sent as Authorization: Bearer header only over HTTPS URLs
• Confirmed BRIGHT_DATA_API_KEY environment variable must be present or _run method raises an error before any HTTP requests occur, preventing null or empty token usage
• Reviewed aiohttp usage for exposing tokens in query parameters, logs, or errors; only used in headers without logging sensitive headers or tokens
• Validated that the PR changes only dependency versions, no code in brightdata_dataset.py or elsewhere adjusting secret management or communication patterns
• Considered attack vectors where updated aiohttp parsing might introduce request smuggling or response splitting affecting secrets; such flaws would be in aiohttp itself and are mitigated by upgrading to fixed versions
• Reviewed vulnerability mitigations in pyproject.toml comments noting fixed CVEs and ensured PR raises aiohttp floor to a fixed patched version
• Inspected GitHub Actions workflow files referenced for executing tests and vulnerability scans; no secrets or unsafe paths exposed by the workflow changes
• Examined use cases of BRIGHT_DATA_API_KEY restricted to local or hosted agent environments, requiring manual token creation and enforcement outside the codebase
• Verified no secrets are committed in source code or logs in the affected files or changes
• Checked pyproject.toml line 220-320 to verify if the dependency change updates aiohttp floor only and ensures patched versions are used; confirmed no code logic changes affecting runtime behavior or interfaces with agent tools.
• Checked brightdata_dataset.py lines 400-650 including BrightDataDatasetTool class for new calls or validation changes in _run or get_dataset_data_async; confirmed usage and validation of parameters remain unchanged, update only affects aiohttp dependency version used.
• Checked conftest.py lines 90-120 for any monkeypatch or workaround changes in aiohttp or vcrpy compatibility that could alter network behavior; patch is present but unchanged in this PR and only executes in test context, no security impact on runtime agents.

pr-security-reviewer, a CrewAI use case

[iris-clawd]

The required tests and pip-audit have not completed, so I did not make the final merge call.

Someone else should sign off on this too: it touches pyproject.toml, uv.lock, which always gets a human look. Leaving this to a human reviewer: I couldn't verify enough with the tools I have.