Daily security sweep — backlog

[benfrank241]

Tracking issue for advisories in langchain/uv.lock that the daily security sweep could not clear, so they are not silently lost. Updated per run.

Context: Dependabot is not scanning this repo

GET /repos/vectorize-io/integrations-python/dependabot/alerts returns HTTP 200 with an empty array in every state (open, fixed, dismissed, auto_dismissed) while langchain/uv.lock is committed — the repo has never been scanned, so there are no alert numbers anywhere in this issue, only GHSA/CVE ids.

Action for a maintainer: enable Dependabot alerts under Settings -> Code security. Until then this repo is invisible to it and every sweep has to re-derive the advisory set by hand with uv export | uvx pip-audit.

---

2026-09-02

Baseline on main: 23 findings across 8 packages (uvx pip-audit, py3.13 resolution leg).

Shipped: #10 (12 advisories: h11, idna, orjson, requests, urllib3, pytest) and #11 (9 advisories: langchain-core, langsmith — major, needs review).

No check failed; nothing was backlogged for a build failure. What follows is backlogged because no upgrade path exists, not because anything broke.

Root cause of everything below: requires-python = ">=3.9"

Python 3.9 has been EOL since October 2025 and every fix listed here dropped 3.9 support. The lock therefore resolves two legs, and the 3.9 leg cannot be made clean at any version. Concretely, after #10 + #11 the py3.9 leg still carries:

package	best available on py3.9	still open	fix version	fix requires
urllib3	2.6.3	GHSA-qccp-gfcp-xxvc (CVE-2026-44431)	2.7.0	py>=3.10
urllib3	2.6.3	GHSA-mf9v-mfxr-j63j (CVE-2026-44432)	2.7.0	py>=3.10
requests	2.32.5	GHSA-gc5v-m9x4-r6x2 (CVE-2026-25645)	2.33.0	py>=3.10
orjson	3.11.5	GHSA-hx9q-6w63-j58v (CVE-2025-67221)	3.11.6	py>=3.10
pytest (dev)	8.4.2	GHSA-6w46-j5rx-g56g (CVE-2025-71176)	9.0.3	py>=3.10
langchain-core	0.3.86	GHSA-qh6h-p6c9-ff54 (CVE-2026-34070)	1.2.22	py>=3.10
langchain-core	0.3.86	GHSA-2g6r-c272-w58r (CVE-2026-26013)	1.2.11	py>=3.10
langsmith	0.4.37	GHSA-3644-q5cj-c5c7 (CVE-2026-45134)	0.8.0	py>=3.10
langsmith	0.4.37	GHSA-rr7j-v2q5-chgv (CVE-2026-41182)	0.7.31	py>=3.10
langsmith	0.4.37	GHSA-v34v-rq6j-cj6p (CVE-2026-25528)	0.6.3	py>=3.10
langsmith	0.4.37	GHSA-f4xh-w4cj-qxq8	0.8.18	py>=3.10

Proposed fix: drop Python 3.9. Remove it from requires-python, the classifiers block in langchain/pyproject.toml, and the matrices in .github/workflows/python_test.yml and lint.yml. That collapses the two resolution legs into one and clears every advisory above. It is an API-compatibility decision for the published langchain-vectorize package, so the sweep will not make it unilaterally.

Two regressions introduced on the py3.9 leg (accepted knowingly)

Both are cases where the newest 3.9-compatible version is itself vulnerable, and staying put would have been worse overall:

1. urllib3 2.3.0 -> 2.6.3 introduces GHSA-mf9v-mfxr-j63j (introduced in 2.6.0, fixed in 2.7.0). It clears 5 other urllib3 advisories in exchange, so 6 -> 2.
2. langsmith 0.3.15 -> 0.4.37 (forced by chore(security): bump langchain-core 0.3.45 -> 1.6.1 (9 advisories) - MAJOR, needs review #11: langchain-core 0.3.86 requires langsmith>=0.3.45) introduces GHSA-v34v-rq6j-cj6p (introduced in 0.4.10, fixed in 0.6.3). This one is a genuine net negative for the 3.9 leg: 3 -> 4. It is unavoidable while both langchain-core 0.3.86 and py3.9 are in play, and disappears entirely if 3.9 is dropped.

Note on local verification

langchain/tests/test_retrievers.py is a live integration suite, not a unit suite — its session fixture raises ValueError: Please set the VECTORIZE_TOKEN environment variable. It cannot be executed outside CI, on main or on any branch. Sweep verification is therefore limited to uv sync --dev, ruff format --check, ruff check, mypy . and pytest collection, on both py3.9 and py3.13; actual test execution is delegated to each PR's own CI run.

[benfrank241]

2026-09-02 (addendum) — CI is red on main-equivalent content, for two reasons unrelated to dependencies

Both #10 and #11 came back red. Neither failure is caused by a dependency bump; both would fail on unmodified main. Full evidence in the triage comments on #10 and #11. Summary, because both need a maintainer and neither can be fixed by a security bundle:

A. LangChain Unit Tests — the Vectorize API returns HTTP 402 to CI

vectorize_client.exceptions.ApiException: (402)
Reason: Payment Required
{"success":false,"error":"Upgrade Required",
 "message":"API access is available on paid plans only. Please upgrade to use this endpoint.",
 "code":"UPGRADE_REQUIRED"}

Raised in the session-scoped fixture of tests/test_retrievers.py (ERROR at setup), on all five matrix legs (3.9-3.13). A 402 rather than a 401 means VECTORIZE_TOKEN authenticated fine and was rejected on plan/billing — the account behind the CI secret has lost API access.

Consequence: this workflow currently cannot pass on any branch, so it provides no signal on dependency changes. Restoring API access on that account is a prerequisite for trusting any future sweep's CI result here.

B. Lint LangChain — lint.yml ignores its own matrix and installs Python 3.14

.github/workflows/lint.yml declares matrix.python-version: ['3.9', '3.13'] but configures actions/setup-python with python-version-file: "langchain/pyproject.toml" instead of ${{ matrix.python-version }}. setup-python resolves requires-python = ">=3.9" to the newest interpreter present and logs Successfully set up CPython (3.14.7) — so both matrix legs run 3.14. pydantic-core 2.27.2 ships no cp314 wheel, uv falls back to a maturin/pyo3 source build, and it fails:

PYO3_ENVIRONMENT_SIGNATURE="cpython-3.14-64bit"
Error: command ['maturin', 'pep517', 'build-wheel', ...] returned non-zero exit status 1
hint: `pydantic-core` (v2.27.2) was included because `langchain-vectorize` (v0.0.3)
      depends on `vectorize-client` (v0.4.0) which depends on `pydantic` (v2.10.6)

This is environment drift — the repo last ran CI on 2025-09-01, before 3.14 reached the runners. pydantic 2.10.6 / pydantic-core 2.27.2 are unchanged from main in both PRs.

Two independent fixes, deliberately not bundled into a security PR:

1. Use python-version: ${{ matrix.python-version }} in lint.yml so the matrix is honoured (this alone makes lint green again).
2. Bump pydantic / pydantic-core to a release with cp314 wheels, so the repo works on current interpreters at all.

Neither package carries a security advisory, so mixing them into a security bundle would violate the sweep's own rule against combining unrelated changes.