CVE-2026-8769

What it actually does

In vercel ai (provider-utils) through 3.0.97, createJsonResponseHandler and createJsonErrorResponseHandler in packages/provider-utils/src/response-handler.ts can be driven into excessive CPU and/or memory use while parsing or materializing JSON provider responses or error bodies. Availability of the local Node.js process is reduced (CVSS VA:L); confidentiality and integrity are not affected. The condition is network-reachable with low privileges and no user interaction.

Why it matters to the business

AI features that rely on this SDK can slow, time out, or become unavailable, interrupting user-facing chat, agents, or automation without data theft. Severity is modest (CVSS 4.3) and exploit probability is low (EPSS ~0.007, up ~30% over 30 days), it is not in KEV, and there is no confirmed ransomware use. Residual risk is operational: the issue has been public for about 137 days, the vendor did not respond, and no official fixed versions are listed, so unpatched services may stay exposed until a patch, fork, or compensating control is applied.

How an attack unfolds

A remote attacker with low privileges locates an application that uses vercel ai ≤ 3.0.97 and can cause it to run provider response handling. They induce the app to pass a provider success or error body through createJsonResponseHandler or createJsonErrorResponseHandler such that JSON processing consumes disproportionate CPU or memory. Repeating or sustaining that traffic degrades or denies the Node.js worker. Disclosure exists, but exploit maturity is none and no named threat actors are associated; abuse would look like availability pressure against AI endpoints rather than a distinct implant.

How to fix it

No vendor fixed versions are published and the maintainer did not respond, so there is no official upgrade target. Inventory every service that depends on vercel ai / provider-utils and treat ≤ 3.0.97 as vulnerable. Prefer an upstream patch or patched fork when one appears; until then reduce blast radius: cap request rate and concurrency on AI routes, enforce strict maximum body size and parse depth/time on provider responses, isolate AI workers with memory/CPU limits and automatic restart, and fail closed on oversized or slow JSON. Track the vercel ai changelog and lockfile for a provider-utils release that hardens response-handler.ts, then upgrade and redeploy promptly.

How to confirm the fix worked

Confirm lockfiles and installed packages: vercel ai / provider-utils must not remain at ≤ 3.0.97 once a patched release exists; until then record residual exposure. In staging, exercise normal provider success and error paths under load and verify JSON parse size, depth, and time limits reject oversized bodies without unbounded memory growth. Watch process RSS, heap, and event-loop lag on AI workers during tests. SCA, SBOM, and container image scans should flag the vulnerable package range until it is removed.

Typical attack path

1. Find internet-facing or internally reachable apps that depend on vercel ai / provider-utils at or below 3.0.97.
2. Authenticate or otherwise obtain the low privilege needed to invoke AI provider calls that hit the JSON response or JSON error handlers.
3. Cause those handlers to process a response or error body that triggers unbounded or costly JSON handling.
4. Repeat or parallelize requests to keep CPU or memory elevated until workers stall, time out, or crash.
5. Optionally watch for process restarts and resume traffic to prolong downtime.

How to detect it

This is a resource-consumption issue, not a implant, and no named actors are tied to it. Hunt for availability incidents rather than malware. Review Node.js/host metrics (RSS, heap, event-loop lag, GC thrash, OOM kills) on processes that load vercel ai / provider-utils, correlated with inbound traffic to AI or provider-proxy routes and with provider success/error handling around the time of slowness. Application and access logs showing bursts of authenticated, low-privilege calls that end in 5xx, 429, or timeouts, plus APM traces stuck in JSON parse/serialize of provider bodies, are the primary artifacts. There is no reliable post-exploitation file or registry residue; empty or missing IOCs do not mean the condition was not abused.

What your security team should do

• Immediately inventory applications and lockfiles using vercel ai / provider-utils ≤ 3.0.97 and assign owners.
• Apply rate limits, body-size caps, and worker memory/CPU limits on AI provider response handling as compensating controls.
• Subscribe for an official or community patch to response-handler.ts; upgrade and redeploy as soon as a fixed provider-utils version ships.
• Add availability alerts (heap, event-loop delay, 5xx/timeouts) on AI endpoints; this is not KEV but EPSS has risen ~30% in 30 days.
• Until a patch exists, consider isolating or temporarily disabling unneeded AI routes that deserialize untrusted provider JSON.