Daily security sweep — backlog

[benfrank241]

Backlog from the daily security sweep for vectorize-io/agent-memory-benchmark, run 2026-09-01. This issue tracks advisories the sweep found but deliberately did not bundle into a PR, with the exact reason for each. It is appended to on subsequent runs.

What was shipped this run: PR for ui/package-lock.json fixing nanoid, postcss, unhead / @unhead/vue (7 GHSAs), verified locally green.

Note on this repo: Dependabot alerts return empty in every state (open / fixed / dismissed / auto-dismissed) while /dependabot/alerts itself returns 200 — i.e. alert ingestion appears to be off even though the endpoint is reachable. There are real advisories here, so the sweep falls back to npm audit and pip-audit. That is why everything below is referenced by GHSA/CVE and not by alert number. Worth enabling under Settings → Code security → Dependabot alerts so these get tracked automatically.

---

1. vite / esbuild — needs a major bump, not force-fixable

Path: ui/package-lock.json · Blocked, not fixed.

package	severity	vulnerable range	locked	advisory
vite	high	<= 6.4.2	5.4.21	GHSA-fx2h-pf6j-xcff — server.fs.deny bypass on Windows alternate paths
vite	moderate	<= 6.4.1	5.4.21	GHSA-4w7w-66w2-5vf9 — path traversal in optimized-deps .map handling
vite	moderate	<= 6.4.2	5.4.21	GHSA-v6wh-96g9-6wx3 — launch-editor NTLMv2 hash disclosure via UNC paths on Windows
esbuild	moderate	<= 0.24.2	0.21.5	GHSA-67mh-4wv8-2f99 — dev server accepts requests from any website and returns the response

Why the sweep could not bundle it. The only fix npm audit offers is:

fix available via `npm audit fix --force`
Will install vite@8.2.2, which is a breaking change

The sweep never runs --force or --legacy-peer-deps, so it stops here. And there is genuinely no in-range fix to fall back on: ui/package.json declares vite: ^5.0.0, the 5.x line ends at 5.4.21 (already installed), and the entire 5.x line sits inside <= 6.4.2. esbuild cannot be fixed independently either — vite@5.4.21 declares esbuild: ^0.21.3, and the first fixed esbuild is 0.25.0, outside that range. Leaving a major bump to a human is the intended behaviour, not a failure.

Recommended fix — vite@^6.4.3, not the 8.2.2 npm suggests. npm's --force path jumps three majors; one major is enough, and the peer ranges already declare support:

• vite@6.4.3 clears all four advisories at once: it is > 6.4.2 (so all three vite advisories), and it declares esbuild: ^0.25.0 (so GHSA-67mh-4wv8-2f99).
• @vitejs/plugin-vue@^5.0.0 (currently installed) declares peer vite: ^5.0.0 || ^6.0.0 — already compatible with 6, no bump needed.
• @tailwindcss/vite@4.2.1 (currently installed) declares peer vite: ^5.2.0 || ^6 || ^7 — already compatible with 6. Note it does not declare support for vite 8, so npm's --force target would leave this peer unsatisfied.
• vite@6.4.3 engines: ^18.0.0 || ^20.0.0 || >=22.0.0 — satisfied.

So the suggested change is a one-line ui/package.json edit, "vite": "^5.0.0" → "vite": "^6.4.3", plus a lockfile re-resolve. It still wants a human to review and to eyeball the built site, which is why the sweep is proposing rather than pushing it.

Practical exposure in the meantime. All four advisories are dev-server issues (vite dev / esbuild serve) — arbitrary-origin requests to the dev server, server.fs.deny bypass, sourcemap path traversal, and an editor-launch UNC disclosure. This repo ships a static vite build to Vercel (vercel.json sets outputDirectory: ui/dist), so the deployed site is not exposed; the risk is to contributors running npm run dev locally, particularly on Windows for two of them. Real, but not a production incident. Not dismissed.

---

2. Python side (uv.lock) — audited cleanly, deliberately not bundled

Path: root uv.lock / pyproject.toml · Assessed, no PR opened.

pip-audit ran cleanly against the full resolved set exported from the lock (uv export --frozen --no-emit-project --no-hashes, 297 pinned distributions):

Found 182 known vulnerabilities in 35 packages

Worst offenders by count: pillow 11.3.0 (19), pypdf 6.8.0 (18), aiohttp 3.13.3 (24), litellm 1.82.1 (13), datamodel-code-generator 0.55.0 (10), pyjwt 2.11.0 (9), starlette 0.52.1 (5), cryptography 46.0.5 (6), python-multipart 0.0.22 (5), mcp 1.26.0 (3), transformers 4.57.6 (4), torch 2.10.0 (2). Also authlib, black, cbor2, click, datasets, diskcache, fastmcp, h2, idna, langchain-core, langchain-text-splitters, langsmith, lupa, lxml, mako, mem0ai, pyasn1, pydantic-settings, pygments, requests, setuptools, soupsieve, urllib3.

Four reasons the sweep did not open a PR for this:

1. Nothing in pyproject.toml is actually causing it. Every declared dependency is an open >= floor (datasets>=2.0, fastapi[standard]>=0.135.1, mem0ai>=1.0.5, …). No constraint pins anything to a vulnerable version — the lock is simply stale relative to its own floors. So there is no constraint to bump; the fix is a wholesale uv lock --upgrade, which is a dependency refresh rather than a scoped security fix, and would move ~35 packages plus their fallout through a 1.2 MB lockfile.
2. It cannot be verified. There is no test suite — no tests/ directory, no [tool.pytest] config in pyproject.toml, and no CI. The only test_*.py in the tree is scripts/test_hindsight_extraction.py, a script rather than a suite. uv sync alone would prove the graph resolves, not that the benchmark still runs. The sweep does not push what it cannot verify.
3. Several have no fix at all, so a refresh would not clear them regardless: diskcache 5.6.3 (CVE-2025-69872), lupa 2.6 (CVE-2026-34444), torch 2.10.0 (CVE-2026-4538), transformers 4.57.6 (CVE-2025-14929) — all with an empty fix-version list.
4. Several need majors or a pre-release, which are propose-only by policy: datasets 4.7.0 → 5.0.1, transformers 4.57.6 → 5.x, starlette 0.52.1 → 1.x, cryptography 46.0.5 → 49/50, torch 2.10.0 → 2.13.0, and mem0ai 1.0.5 → 2.0.0b2, a beta the sweep will not ship into a lockfile.

Scope note, and why this is lower priority than it looks: .vercelignore excludes uv.lock, and vercel.json sets installCommand: "" with outputDirectory: ui/dist. The deployed serverless function (api/index.py) installs from api/requirements.txt, which is the single unpinned line fastapi[standard]>=0.135.1 resolved fresh at deploy time. uv.lock therefore does not describe anything that gets deployed — it is the local benchmark/research harness (torch, transformers, mem0ai, cognee, sentence-transformers). The exposure is to maintainers running the harness locally, not to the hosted site.

Suggested owner action, in priority order:

• Run uv lock --upgrade on its own branch and actually exercise uv run amb against a small dataset — that clears the large majority of the 182 in one go, and needs a human who can tell whether the benchmark still behaves.
• Decide separately on the four no-fix advisories (accept, or drop the dependency).
• Consider pinning api/requirements.txt so the deployed function stops being a floating deploy-time resolve. Right now it is unpinned in both directions: it picks up security fixes automatically, but it is also unreproducible and unauditable.

---

3. api/requirements.txt — nothing to bundle

Single line, fastapi[standard]>=0.135.1. No advisory in the audit names fastapi itself, and the transitive starlette / python-multipart findings above come from the lock, which is not what Vercel installs. Nothing scoped and verifiable to change here. See the pinning suggestion in §2.

---

Sweep metadata

• Run date 2026-09-01. Verification host: macOS arm64, Node v22.22.3, npm 10.9.8, uv 0.11.18.
• This repo has no CI (.github/workflows does not exist), so all verification for the sweep is local, and any PR it opens will show no checks.
• Nothing was dismissed, closed, or merged by the sweep.

🤖 Generated with Claude Code