Daily security sweep — backlog

[benfrank241]

Items from the daily security sweep that could not be bundled into a PR. Appended to per run.

---

2026-08-26 — datasheetsChat (npm)

Bundle PR: #9 (closes 22 of 23 open alerts).

1. Alert #52 — @ai-sdk/provider-utils (low) — no upstream fix exists

GHSA-866g-f22w-33x8, vulnerable range <= 3.0.97. Dependabot reports no patched version — there is nothing to bump to.

npm audit proposes fixes, but every one is a semver-major across the whole AI SDK surface:

package	current	audit's proposed fix
ai	^5.0.68	7.0.79 (major)
@ai-sdk/openai	^1.1.9	4.0.47 (major)
@ai-sdk/react	^1.2.2	4.0.82 (major)
@ai-sdk/groq	^1.1.7	4.0.31 (major)

Six resolved copies of @ai-sdk/provider-utils are present (2.2.0, 2.2.1, 3.0.12) across ai, @ai-sdk/gateway, @ai-sdk/groq, @ai-sdk/openai, @ai-sdk/react, @ai-sdk/ui-utils.

Not dismissed — the advisory is in the AI SDK request path, which this app genuinely uses, so it is not unreachable. Needs a human decision on the AI SDK major migration (see item 2, which forces the same migration anyway).

2. main does not build — pre-existing, blocks meaningful verification

Reproduced on a clean, unmodified checkout of main (next@15.5.18, before any sweep changes):

./src/app/api/chat/route.ts:134:5
Type error: Type 'LanguageModelV1' is not assignable to type 'LanguageModel'.
  Property 'supportedUrls' is missing in type 'LanguageModelV1' but required in type 'LanguageModelV2'.

tsc --noEmit reports 8 errors, all in src/app/api/chat/route.ts:

• (134,5) TS2322 — LanguageModelV1 not assignable to LanguageModel
• (160,9) (184,9) (226,9) (259,9) (331,9) (371,9) TS2353 — 'parameters' does not exist in type ... (renamed to inputSchema in AI SDK v5)
• (379,17) TS2551 — Property 'toDataStreamResponse' does not exist on type 'StreamTextResult'. Did you mean 'toTextStreamResponse'? (renamed to toUIMessageStreamResponse in v5)

Cause: package.json pairs ai@^5.0.68 with v1-line providers (@ai-sdk/openai@^1.1.9, @ai-sdk/react@^1.2.2, @ai-sdk/groq@^1.1.7), while route.ts is written against the AI SDK v4 API. The ai package was bumped to v5 at some point without migrating the providers or the call sites.

Fix required: migrate src/app/api/chat/route.ts to the AI SDK v5 API and bring @ai-sdk/* onto the matching major. This is app-code work, deliberately kept out of the security bundle. It would also resolve item 1.

Impact: the sweep cannot get a green build for this repo, so security bundles here can only be verified by differential comparison against main (confirming no new errors), not by an absolute green. PR #9 was verified that way.

3. npm run lint is not runnable

No ESLint config is committed, so next lint drops into an interactive "How would you like to configure ESLint?" prompt and never exits non-interactively. Same on main. Also note next lint is deprecated and removed in Next.js 16.

Fix required: commit an eslint.config.mjs (or migrate to the ESLint CLI per the Next.js codemod) so lint is a usable CI signal.

[benfrank241]

2026-08-28 — datasheetsChat (npm) — re-confirmed, with the escape version pinned down

Alert #52 / GHSA-866g-f22w-33x8 re-checked this sweep. Conclusion unchanged — no PR opened, alert not dismissed. Adding the specific detail of which upgrade actually clears the range, because the obvious reading of item 2 above ("bring @ai-sdk/* onto the matching major" alongside ai@^5) would not clear this alert.

Re-confirmed

• Vulnerable range <= 3.0.97, first_patched_version: null.
• The published @ai-sdk/provider-utils 3.x line tops out at 3.0.35 (ai-v5 dist-tag), so every stable 3.x release is inside the range. There is nothing in the affected line to bump to.

Why no in-range fix exists

Every parent pins @ai-sdk/provider-utils to an exact version, so npm has no re-resolution room at all and npm update moves nothing:

parent (installed)	pins provider-utils
ai@5.0.68	3.0.12
@ai-sdk/gateway@1.0.39	3.0.12
@ai-sdk/groq@1.2.1	2.2.1
@ai-sdk/openai@1.3.0	2.2.0
@ai-sdk/react@1.2.2	2.2.1
@ai-sdk/ui-utils@1.2.1	2.2.1

Note the 2.2.x copies are inside <= 3.0.97 too — all six resolved copies are vulnerable, not just the 3.0.12 ones.

Which upgrade actually clears it

Verified against the registry:

upgrade target	resulting provider-utils	clears <= 3.0.97?
ai@5.0.249 (top of the ai-v5 line)	3.0.35	❌ no
@ai-sdk/openai@2.0.122 (ai-v5 line)	3.0.35	❌ no
ai@6.0.271 (ai-v6 line)	4.0.49	✅ yes
@ai-sdk/openai@3.0.104 (ai-v6 line)	4.0.49	✅ yes

So the v5 migration described in item 2 fixes the build, but leaves this alert open. Clearing the alert requires going to the ai v6 line.

What this means

The only route out is a coordinated major upgrade onto the ai v6 line (ai ^5 → ^6, providers 1.x → 3.x), together with the src/app/api/chat/route.ts migration already described in item 2. A breaking major on a runtime path is out of scope for the automated sweep and needs human scheduling — worth doing in the same pass as item 2 rather than twice.

An npm overrides forcing 4.x was considered and rejected: it pins a 4.x transitive under parents declaring exact 3.0.x/2.2.x deps — a forced resolve with high breakage risk.

Not dismissed — the AI SDK request path is genuinely reachable here.

[benfrank241]

2026-09-01 — datasheetsChat (npm) — no PR opened

Sweep scope this run: 1 open alert (#52). No PR opened; see below. Nothing dismissed.

Alert #52 — @ai-sdk/provider-utils (low) — correcting the 2026-08-26 entry

The entry above says "no upstream fix exists." That was wrong, and this run corrects it.

A fix does exist. It shipped in @ai-sdk/provider-utils 3.0.28 — which sits inside the advisory's declared vulnerable range <= 3.0.97. That is precisely why GitHub reports first_patched_version: null and why the alert will keep firing no matter what this repo bumps to.

Established by tarball bisection of package/dist/index.js across 2.2.1 / 2.2.4 / 2.2.8 / 3.0.20 / 3.0.25 / 3.0.28 / 3.0.30–3.0.36 / 4.0.50 / 5.0.34. At 3.0.28 both createJsonResponseHandler and createJsonErrorResponseHandler switch from an unbounded

const responseBody = await response.text();

to

const responseBody = await readResponseBodyAsText({ response, url });

which routes through readResponseWithSizeLimit — a Content-Length precheck plus a streaming totalBytes > maxBytes guard. That is exactly the CWE-400 the advisory describes.

4.0.50 and 5.0.34 carry the same mitigation — they are not "more fixed". They merely fall outside a stale range string. So the AI SDK v6/v7 major migration floated in the entry above buys a green badge and zero additional security. Do not do it for this reason.

What this repo actually resolves today — genuinely unmitigated

consumer	provider-utils	mitigated?
ai@5.0.68	3.0.12	no — below 3.0.28
@ai-sdk/gateway@1.0.39	3.0.12	no — below 3.0.28
@ai-sdk/openai@1.3.0	2.2.0	no — 2.x line never got the fix
@ai-sdk/groq@1.2.1	2.2.1	no — 2.x line never got the fix
@ai-sdk/react@1.2.2	2.2.1	no — 2.x line never got the fix
@ai-sdk/ui-utils@1.2.1	2.2.1	no — 2.x line never got the fix

The 2.x line is dead at 2.2.8 and still uses unbounded await response.text() — no size limiting at all. Those four copies cannot reach a mitigated version without a semver-major move off the @ai-sdk/* v1 generation.

Why no mitigation PR was opened — the in-range bump is a net security regression

Bumping ai to ^5.0.207 does move the two 3.0.12 copies to a mitigated 3.0.36, and it verifies cleanly (byte-identical failure set vs main, see below). But it drags in a new transitive: undici@5.29.0.

provider-utils 3.0.31+ added a dependency on undici ^5.29.0. The undici 5.x line is dead at 5.29.0, and the whole line is vulnerable — npm audit reports vulnerable range <= 6.27.0 with 12 advisories, including HTTP request/response smuggling, response-queue poisoning via keep-alive socket reuse, and unbounded decompression. npm audit offers only a semver-major @ai-sdk/openai@4.0.53 as a fix.

Net effect of the "mitigation" bump, measured:

	main today	after ai@^5.0.207
low	7	6
moderate	0	1
high	0	1

Trading one low DoS for a high request-smuggling surface is not an improvement. Not shipped.

The only clean window is a maintenance trap

provider-utils 3.0.28 and 3.0.30 are mitigated and undici-free; 3.0.31+ are not. Because ai pins provider-utils exactly, that maps to a 16-version box:

• ai 5.0.207 – 5.0.222 → provider-utils 3.0.28–3.0.30 — mitigated, no undici
• ai 5.0.223+ → provider-utils 3.0.31+ — pulls vulnerable undici

Holding that would mean a constraint like "ai": ">=5.0.207 <5.0.223", which blocks every future ai patch and rots the moment upstream moves. Rejected as worse than the exposure it removes.

What would actually unblock this

1. The real unblock is not a dependency change. GitHub's Advisory Database range for GHSA-866g-f22w-33x8 should be corrected from <= 3.0.97 to < 3.0.28. Until that lands, alert #52 stays open for every reachable version, and any PR claiming to close it would be false.
2. Upstream: @ai-sdk/provider-utils should move off the dead undici 5.x line (>= 6.28.0), which would make an in-range mitigation bump safe here.
3. This repo: migrating the @ai-sdk/* v1 packages (openai, groq, react) onto the generation matching ai@5 would mitigate the four 2.2.x copies — the genuinely exposed ones — and is the same work already required by item 2 of the 2026-08-26 entry (main does not build). That remains app-code work, deliberately out of scope for a security bundle.

Not dismissed — the AI SDK request path is genuinely used by this app, so the vulnerable code is reachable.

Verification notes

main still does not build, unchanged from 2026-08-26. Baseline captured this run on a pristine checkout: npx tsc --noEmit → 8 errors, all in src/app/api/chat/route.ts (134,5 TS2322; 160/184/226/259/331/371 TS2353; 379,17 TS2551). The ai@^5.0.207 experiment produced a byte-identical 8-error set — so the bump itself is behaviourally clean; it was rejected purely on the undici regression above, not on build breakage.

npm run lint remains unrunnable non-interactively (no committed ESLint config; next lint prompts). Unchanged.