requirements.txt hasn't been regenerated since 2026-03-17, and because pyproject.toml:30 makes it the install set —
[tool.setuptools.dynamic]
dependencies = { file = "requirements.txt" }— the pins in it are exactly what everyone gets from pip install aider-chat.
Scanning that file today reports 44 HIGH/CRITICAL advisories, and every one of them has a fixed version available. I checked the versions against OSV directly rather than trusting the scanner: litellm 1.82.3 → 25 advisories, gitpython 3.1.46 → 20, pillow 12.1.1 → 36, urllib3 2.6.3 → 4.
Two of the affected packages stood out to me as worth surfacing separately, because of what they do in aider specifically rather than because of their CVE counts:
litellm 1.82.3 — this is the path every provider request goes through, so it's the code holding the user's API keys. It carries three CRITICALs, including:
gitpython 3.1.46 — aider touches the user's repository through this on essentially every run. Four HIGH advisories, fixed across 3.1.47–3.1.49 (CVE-2026-42215, CVE-2026-42284, CVE-2026-44243, CVE-2026-44244).
The rest, briefly: pillow 12.1.1 → 12.3.0 (9 HIGH), urllib3 2.6.3 → 2.7.0 (CVE-2026-44431/44432), starlette 0.52.1 (CVE-2026-48818, CVE-2026-54283), soupsieve 2.8.3 → 2.8.4.
I also noticed there's no .github/dependabot.yml, which would explain how five months passed without this surfacing — nothing is watching these pins.
On the fix: I don't think this is a case where an outside PR helps. CONTRIBUTING.md says these files are generated by ./scripts/pip-compile.sh and committed, so the change should come from that script on your toolchain rather than from me hand-editing pins. And a blanket regeneration isn't obviously safe either — litellm 1.82.3 → 1.84.0 crosses minor versions, and the model-name tables move with it, so that one probably wants deliberate validation rather than a bump.
So the realistic options as I see them, and it's your call which:
- Re-run
./scripts/pip-compile.sh and validate against the test suite.
- Targeted bumps of just the security-relevant pins (litellm, gitpython, pillow, urllib3, starlette), leaving the rest alone.
- Add a
dependabot.yml so this surfaces automatically next time.
Happy to open a PR for any of these if it's useful — I held off because a large generated diff from an outside contributor seemed more likely to get in the way than help. Also happy to be told this is already tracked somewhere I didn't find; I searched open and closed issues and PRs for dependency/CVE/security and came up empty.
Disclosure: I used an AI coding agent (Claude Opus 5) to help run the scan and cross-check the advisories. I verified the pins against pyproject.toml, confirmed the CVE details against OSV myself, and checked the fix path in CONTRIBUTING.md before opening this.
requirements.txthasn't been regenerated since 2026-03-17, and becausepyproject.toml:30makes it the install set —— the pins in it are exactly what everyone gets from
pip install aider-chat.Scanning that file today reports 44 HIGH/CRITICAL advisories, and every one of them has a fixed version available. I checked the versions against OSV directly rather than trusting the scanner: litellm 1.82.3 → 25 advisories, gitpython 3.1.46 → 20, pillow 12.1.1 → 36, urllib3 2.6.3 → 4.
Two of the affected packages stood out to me as worth surfacing separately, because of what they do in aider specifically rather than because of their CVE counts:
litellm 1.82.3 — this is the path every provider request goes through, so it's the code holding the user's API keys. It carries three CRITICALs, including:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)gitpython 3.1.46 — aider touches the user's repository through this on essentially every run. Four HIGH advisories, fixed across 3.1.47–3.1.49 (CVE-2026-42215, CVE-2026-42284, CVE-2026-44243, CVE-2026-44244).
The rest, briefly: pillow 12.1.1 → 12.3.0 (9 HIGH), urllib3 2.6.3 → 2.7.0 (CVE-2026-44431/44432), starlette 0.52.1 (CVE-2026-48818, CVE-2026-54283), soupsieve 2.8.3 → 2.8.4.
I also noticed there's no
.github/dependabot.yml, which would explain how five months passed without this surfacing — nothing is watching these pins.On the fix: I don't think this is a case where an outside PR helps.
CONTRIBUTING.mdsays these files are generated by./scripts/pip-compile.shand committed, so the change should come from that script on your toolchain rather than from me hand-editing pins. And a blanket regeneration isn't obviously safe either — litellm 1.82.3 → 1.84.0 crosses minor versions, and the model-name tables move with it, so that one probably wants deliberate validation rather than a bump.So the realistic options as I see them, and it's your call which:
./scripts/pip-compile.shand validate against the test suite.dependabot.ymlso this surfaces automatically next time.Happy to open a PR for any of these if it's useful — I held off because a large generated diff from an outside contributor seemed more likely to get in the way than help. Also happy to be told this is already tracked somewhere I didn't find; I searched open and closed issues and PRs for dependency/CVE/security and came up empty.
Disclosure: I used an AI coding agent (Claude Opus 5) to help run the scan and cross-check the advisories. I verified the pins against
pyproject.toml, confirmed the CVE details against OSV myself, and checked the fix path in CONTRIBUTING.md before opening this.