[uipreliga]

What

Bumps the locked dependencies that fail pip-audit on main, and removes the vulnerability ignores that no longer match anything.

Package	From	To	Advisory
filelock	3.32.6	4.2.4	CVE-2026-112907, CVE-2026-112913, CVE-2026-112940
litellm ([litellm] extra)	1.102.0	1.103.1	CVE-2026-114612
msgpack	1.2.1	1.2.3	CVE-2026-114613
oauthlib	3.3.1	4.0.0	CVE-2026-49272, CVE-2026-49264, CVE-2026-49265
virtualenv (via pre-commit, dev only)	21.14.12	21.14.13	GHSA-cx6f-vjhg-g3cc / CVE-2026-115586 (osv-scanner only)
certifi	2026.10.19	2026.10.23	trust-store refresh
cryptography	50.0.0	50.0.2	patch
requests	2.33.0	2.34.2	patch/minor
pip / pip-audit	26.2.1 / 2.10.0	26.2.2 / 2.10.1	tooling

• filelock, msgpack, oauthlib and virtualenv get floors in [tool.uv] constraint-dependencies. The litellm extra floor goes to >=1.103.1.
• virtualenv is pinned to 21.14.13, not 21.15.0: 21.15.0 is younger than the 24 h package-age gate.
• No other package in uv.lock changes. The lock stays at revision = 5 (locked with uv 0.13.6).
• All four --ignore-vuln flags on the pip-audit step and both osv-scanner.toml entries are removed. pip-audit with no ignores on the synced CI venv (pygments 2.20.0, pip 26.2.2, oauthlib 4.0.0) reports No known vulnerabilities found.

Why

The Quality Gate fails at the pip-audit step on every PR, for example #237 and #239. When that step fails, the test suite, osv-scanner and bandit do not run. main passed on 2026-10-22, before these advisories were published.

Package age

Every new version is older than the 24 h safe-chain minimum package age. The newest is certifi 2026.10.23, uploaded 2026-10-23 11:36 UTC.

Tests

• make verify: 6389 passed, 4 skipped, coverage 93.25%. This ran before the virtualenv bump; after it, tests/test_custom_lint.py passes (735).
• pip-audit --desc --skip-editable (no ignores) on a venv synced with --extra dev --extra uipath --extra codex --extra litellm --extra harbor: no known vulnerabilities.
• osv-scanner v2.3.8 (the CI version, checksum-verified) on uv.lock: No issues found. On main it reports 7 advisories in 5 packages.

Supersedes Dependabot #208 (oauthlib 4.0.0).

🤖 Generated with Claude Code

[github-actions]

Claude finished @uipreliga's task in 1m 29s —— View job

---

PR Review in Progress

Todo List:

• Read .github/code_review.md for review standards
• Review CLAUDE.md for project conventions
• Analyze the full diff (git diff origin/main...HEAD)
• Read and review each changed file with full context
• Check cross-file consistency
• Perform design-level scrutiny and "what's missing" analysis
• Post comprehensive review feedback

[uipreliga]

Review: coder_eval — pr:240 (4 files) axis:1,2,3,4,5,6,7,8

Scope: pr:240 (4 files) axis:1,2,3,4,5,6,7,8 · branch fix/deps-cve-bumps-2026-10 · 16f538d · 2026-10-27T18:55Z · workflow variant

Change class: trivial — dependency floor/lockfile bumps plus removal of now-unneeded CVE ignore entries; no code path changes

coder_eval is in very good health: seven of eight axes have no findings, and grading, resume, timing and the harness core show nothing that can change a task's score or final_status for the same agent output; the only real risk is one low-severity supply-chain gap, where the new CVE floors exist only in [tool.uv] constraint-dependencies and so do not reach PyPI consumers (oauthlib is on the base runtime chain); the bottom line is to merge after a one-line fix or a comment.

Summary

Axis	Score	🔴	🟠	🟡	🔵	Top Issue
1. Code Quality & Style	10 / 10	0	0	0	0	—
2. Type Safety	10 / 10	0	0	0	0	—
3. Test Health	10 / 10	0	0	0	0	—
4. Security	9.9 / 10	0	0	0	1	The new CVE floors are only in [tool.uv] constraint-dependencies, so PyPI consumers of coder-eval do not get them. One of them, oauthlib, is on the base runtime dependency chain.
5. Architecture & Design	10 / 10	0	0	0	0	—
6. Error Handling & Resilience	10 / 10	0	0	0	0	—
7. API Surface & Maintainability	10 / 10	0	0	0	0	—
8. Evaluation Harness Quality	10 / 10	0	0	0	0	—

Overall Score: 10 / 10 · Weakest Axis: Security at 9.9 / 10
Totals: 🔴 0 · 🟠 0 · 🟡 0 · 🔵 1 across 8 axes.

Blockers

None.

Non-blocking, but please consider before merge

None.

Nits

1. [Axis 4] The new CVE floors are only in [tool.uv] constraint-dependencies, so PyPI consumers of coder-eval do not get them. One of them, oauthlib, is on the base runtime dependency chain. (pyproject.toml:231) — The PR adds these lines under constraint-dependencies = [ (line 224, comment # Fix known CVEs in transitive dependencies): "filelock>=4.2.1", (227), "msgpack>=1.2.3", (230), "oauthlib>=4.0.0", (231) and "virtualenv>=21.14.13", (238). uv applies constraint-dependencies only when it resolves this project. They are not written to the published wheel's Requires-Dist. In uv.lock, oauthlib is reached from the BASE runtime deps: coder-eval -> "azure-monitor-opentelemetry-exporter>=1.0.0b30,<1.1.0" (line 58) -> msrest 0.7.1 -> requests-oauthlib 2.0.0 (Requires-Dist: oauthlib >=3.0.0) -> oauthlib. A downstream consumer with an existing lock, such as the coder-eval-uipath nightly runner, can therefore keep oauthlib 3.3.1, which has CVE-2026-49272, -49264 and -49265. filelock reaches users through the harbor and litellm extras (harbor filelock>=3.29.4, tokenizers -> huggingface-hub filelock>=3.10.0), and msgpack through the uipath extra (uipath -> pysignalr). virtualenv is dev-only, so it does not matter downstream. The risk is low: the known oauthlib advisories are in server-side OAuth endpoints that coder-eval never runs, and a fresh uv tool install coder-eval (action.yml) resolves to the newest versions anyway. The repo already has a precedent for putting a floor in the published metadata: "starlette>=1.3.1", is a base dependency at line 52 (src/ does not import starlette) and also appears in the constraint list. Do one of these: (a) for the runtime-path package (oauthlib), add the same floor to [project.dependencies] as the starlette precedent does, or (b) add one comment at line 225 that says these floors protect only this repo's lock and CI, not PyPI consumers. That tells downstream maintainers to bump in their own lock. The litellm floor change ("litellm>=1.103.1,<2.0.0", line 108) is in [project.optional-dependencies], so it already goes to consumers. Its placement is correct. CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N

What's Missing

Tests:

• 🔵 No test imports the real telemetry exporter chain. The PR takes oauthlib from 3.3.1 to 4.0.0 (a major bump) on the base runtime path azure-monitor-opentelemetry-exporter -> msrest -> requests-oauthlib 2.0.0 -> oauthlib. Every telemetry test mocks the exporter: tests/test_telemetry.py:60 and :600 patch AzureMonitorLogExporter, and :586 sets the module to None. src/coder_eval/telemetry.py:219 catches ImportError and logs it only at debug level. So if a later oauthlib or requests-oauthlib release breaks that import, telemetry turns off with no message and CI stays green. I imported the chain manually with oauthlib 4.0.0 and requests-oauthlib 2.0.0 and it works today, but nothing will catch the next break. Add one unmocked smoke test that imports azure.monitor.opentelemetry.exporter and msrest.authentication. filelock 3.32.6 -> 4.2.4 is also a major bump, but the harbor-e2e workflow runs on pull requests and exercises it, so it is less exposed. (trigger: uv.lock)

Nightly pipeline:

• 🔵 The PR does not say what happens to the Docker image that the nightly driver: docker runs use. docker/Dockerfile:107 installs with uv export --frozen --extra codex --extra antigravity --extra litellm --extra harbor | uv pip install, so the next image published from this lock gets two major bumps (filelock 4.x, oauthlib 4.x) and litellm 1.103.1. The commit message covers CVEs and the package-age gate. It does not say that the image dependency set changes or that the nightly run was checked against it. Add one line to the PR body about the image and nightly impact. (trigger: uv.lock)

Downstream consumers:

• 🔵 Same root cause as the Axis 4 finding, so I am not reporting it twice. The new floors for filelock, msgpack and oauthlib hold only this repo's uv.lock and the Docker image built from it. A downstream consumer with its own lock, such as the coder-eval-uipath nightly runner, keeps the vulnerable versions until it bumps them itself, and the PR does not tell those maintainers to do so. (trigger: pyproject.toml) (restates: Axis 4: CVE floors only in [tool.uv] constraint-dependencies, not published to PyPI consumers)

Harness & Lint Improvements

Static checks (lint / type):

• [ce-lint] CE069 (next free number; CE067 was used and then removed, CE068 is taken). The rule: every [tool.uv] constraint-dependencies entry whose package uv.lock shows as reachable from coder-eval's BASE [project.dependencies] must also appear in [project.dependencies] with a floor that is equal or higher. The other path is an entry in an EXEMPT dict with a reason (for example 'advisory is in a server-side code path we never run; downstream bumps in their own lock'). For a package that is reachable only through a published extra (harbor, litellm, uipath, ...), the floor goes in that extra or gets an EXEMPT reason. Packages that only the dev extra or dependency group can reach are skipped, because they never reach a consumer. This is a doc-surface/whole-tree rule (it reads TOML and the lock, not a Python AST). So it goes in tests/test_custom_lint.py as a @pytest.mark.lint class TestCE069ConstraintFloorsPublished, and not in tests/lint/rules/ + runner.py. The helper goes in tests/lint/constraint_floor_parity.py and uses tomllib on pyproject.toml and uv.lock, like tests/lint/agent_roster_parity.py. It does a BFS from the coder-eval package's dependencies (and, separately, from each optional-dependencies key) through [[package]].dependencies and compares the floors with packaging.specifiers. The defect goes in .claude/notes/lint-rules.md. It would have caught "oauthlib>=4.0.0" at pyproject.toml:231, which is reachable through coder-eval -> azure-monitor-opentelemetry-exporter -> msrest -> requests-oauthlib -> oauthlib and is not in [project.dependencies]. It would also flag filelock>=4.2.1 (harbor/litellm extras) and msgpack>=1.2.3 (uipath extra) for an extra-floor or an EXEMPT decision. virtualenv (dev-only) and starlette (already a base dependency at line 52, the precedent) pass. The rule turns 'does this CVE floor reach PyPI consumers?' into a recorded decision for each package. Today that decision is left out without anyone noticing. Prevents: [Axis 4 Security, low] CVE floors for oauthlib (base runtime chain), filelock and msgpack (published extras) are only in [tool.uv] constraint-dependencies (pyproject.toml:224-238). uv does not write them to the wheel's Requires-Dist, so a downstream lock such as coder-eval-uipath's can keep oauthlib 3.3.1 (CVE-2026-49272/-49264/-49265).

Harness improvements (not statically reachable):

• Add a release-time check of the published metadata. In the Release workflow, build the wheel, then check that the floors in the wheel METADATA Requires-Dist are a superset of the non-EXEMPT CE069 floors. Also run pip-audit against the downstream consumer's lock (the coder-eval-uipath nightly runner) after each coder-eval release, so that a stale transitive version (oauthlib 3.3.1) is reported in the repo that actually installs it. Why not static: The consumer's lock is in a different repository. Its resolved versions and the advisory DB are network state that this repo's AST/TOML checks cannot see. CE069 can only check that this repo publishes the floor. It cannot check that a consumer has re-resolved. Prevents: [Axis 4 Security, low] Downstream installs with an existing lock keep vulnerable transitive versions (oauthlib on the base chain, filelock/msgpack through extras), because the constraint-dependencies floors protect only this repo's own uv.lock and CI pip-audit/osv-scanner scope.

Top 5 Priority Actions

1. No action is needed on score or final_status integrity: no confirmed finding can make the same agent output grade differently, so the grading, criteria, early-stop and resume paths need no change in this PR.
2. Add "oauthlib>=4.0.0" to [project.dependencies] in pyproject.toml (base list ending at line 59, next to the "starlette>=1.3.1" precedent at line 52), so PyPI consumers that reach it through azure-monitor-opentelemetry-exporter -> msrest -> requests-oauthlib get CVE-2026-49272/-49264/-49265 fixed and do not keep oauthlib 3.3.1.
3. Add one comment at pyproject.toml:225, under # Fix known CVEs in transitive dependencies, that says constraint-dependencies protect only this repo's lock and CI and are not written to the wheel's Requires-Dist, so downstream maintainers know they must bump in their own locks.
4. Bump oauthlib, filelock (harbor/litellm extras) and msgpack (uipath extra) in the lock files of downstream consumers such as the coder-eval-uipath nightly runner, because their existing locks keep the vulnerable versions whatever this repo sets in pyproject.toml:227-231.
5. Think about a small CE-style lint check, or an entry in .claude/harness-candidates.md, that flags a constraint-dependencies CVE floor for a package reachable from base [project.dependencies] that has no matching floor there; this stops the next CVE bump from repeating the gap.

---

Stats: 0 🔴 · 0 🟠 · 0 🟡 · 1 🔵 across 8 axes reviewed.