You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Versions of @ai-sdk/provider-utils before 3.0.28, from 4.0.0 before 4.0.33, and from 5.0.0 before 5.0.1 are vulnerable to uncontrolled resource consumption. The createJsonResponseHandler, createJsonErrorResponseHandler, and createStatusCodeErrorResponseHandler functions in packages/provider-utils/src/response-handler.ts read response bodies without a shared size limit, allowing a remote attacker with low privileges to cause excessive memory consumption. The exploit has been publicly disclosed and may be utilized.
779f5cd: fix(provider-utils): cancel response body on download rejection to prevent socket leak
When a download was rejected early — because the Content-Length header exceeded the size limit, the response status was not ok, or a redirect resolved to a blocked URL — the fetch response body was left unconsumed and uncancelled. With WHATWG Fetch/undici this leaves the underlying TCP socket open instead of returning it to the connection pool, allowing an attacker-controlled origin to exhaust file descriptors and cause a denial of service. The body is now cancelled on all early-rejection paths in readResponseWithSizeLimit, download, and downloadBlob, and fetchWithValidatedRedirects cancels each redirect hop's body before following or rejecting the next hop.
bfa5864: fix: only send provider credentials to same-origin response-supplied URLs
Several provider clients followed a URL taken from the provider's API response (a polling/status URL or a final media URL such as polling_url, urls.get, result_url, result.sample, or video.uri) and reused the authenticated headers — or appended ?key=<API_KEY> — on that request. Because the host of the response-supplied URL was never validated, the long-lived API key was sent to whatever host the response named (a CDN in the benign case, or an attacker-chosen host if the provider response was tampered with), allowing credential exfiltration.
A new isSameOrigin helper is added to @ai-sdk/provider-utils, and the affected fetches in @ai-sdk/black-forest-labs, @ai-sdk/fireworks, @ai-sdk/replicate, @ai-sdk/gladia, @ai-sdk/fal, and @ai-sdk/google now attach credentials only when the followed URL is same-origin with the provider's configured API origin. Requests to a foreign origin are made without the credential.
f42aa79: fix: harden download URL SSRF guard against hostname and redirect bypasses
validateDownloadUrl and the file download helpers (downloadBlob, download) could be bypassed in several ways when handling untrusted URLs:
A fully-qualified hostname with a trailing dot (e.g. localhost., myhost.local.) skipped the localhost/.local blocklist.
IPv6 addresses that embed an IPv4 address in their last 32 bits — IPv4-compatible (::127.0.0.1), IPv4-translated (::ffff:0:127.0.0.1), and NAT64 (64:ff9b::127.0.0.1, including the 64:ff9b:1::/48 local-use prefix) — were not decoded and checked against the private IPv4 ranges.
Redirects were validated only afterfetch had already followed them, so the request to a redirect target (e.g. an internal/metadata address) had already been issued before the check ran.
Several reserved/internal address ranges were not blocked: CGNAT (100.64.0.0/10, used by some cloud providers for internal traffic), benchmarking (198.18.0.0/15), IETF protocol assignments (192.0.0.0/24), the reserved 240.0.0.0/4 block (including the 255.255.255.255 broadcast address), and IPv6 site-local (fec0::/10) and multicast (ff00::/8).
The validator now strips trailing dots before the hostname checks and fully expands IPv6 addresses to detect embedded private IPv4 targets. The download helpers now follow redirects manually (redirect: 'manual'), re-validating each hop before requesting it, so an unsafe redirect target is never fetched. When a redirect cannot be inspected because the runtime returns an opaque response, the helpers fail closed (reject the redirect) on the server; only in a real browser — where SSRF is not reachable (fetch is constrained by CORS and cannot reach a server's internal network or cloud-metadata endpoints) — is the redirect followed natively so legitimate redirected downloads keep working.
Low Risk
Lockfile-only patch upgrade that applies a published security fix in the AI SDK stack; no application logic changes, though nested @ai-sdk/react still resolves an older nested provider-utils until that package is updated.
Overview
Bumps @ai-sdk/provider-utils from 4.0.21 to 4.0.33 in package-lock.json (direct dependency in the app) to address CVE-2026-8769 / GHSA-866g-f22w-33x8, where JSON response handlers could read provider response bodies without a size cap and allow excessive memory use.
The lockfile also picks up related transitive updates: @ai-sdk/provider3.0.12 under the top-level provider-utils install and eventsource-parser3.1.1 (with ^3.0.8 on the updated provider-utils). @ai-sdk/react still nests its own @ai-sdk/provider-utils@4.0.21 copy unchanged in the lockfile.
There are no source changes—only dependency resolution updates.
Reviewed by Cursor Bugbot for commit 090de48. Bugbot is set up for automated code reviews on this repo. Configure here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
4.0.21→4.0.33@ai-sdk/provider-utils has an Uncontrolled Resource Consumption issue
CVE-2026-8769 / GHSA-866g-f22w-33x8
More information
Details
Versions of
@ai-sdk/provider-utilsbefore 3.0.28, from 4.0.0 before 4.0.33, and from 5.0.0 before 5.0.1 are vulnerable to uncontrolled resource consumption. ThecreateJsonResponseHandler,createJsonErrorResponseHandler, andcreateStatusCodeErrorResponseHandlerfunctions inpackages/provider-utils/src/response-handler.tsread response bodies without a shared size limit, allowing a remote attacker with low privileges to cause excessive memory consumption. The exploit has been publicly disclosed and may be utilized.Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:PReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
vercel/ai (@ai-sdk/provider-utils)
v4.0.33Compare Source
Patch Changes
b30e43a: Limit JSON response body reads in response handlers to prevent unbounded memory use.v4.0.32Compare Source
Patch Changes
f19334d]v4.0.31Compare Source
Patch Changes
1b40ac7: Publish all packages under the@ai-v6dist tag.1b40ac7]v4.0.30Compare Source
Patch Changes
779f5cd: fix(provider-utils): cancel response body on download rejection to prevent socket leakWhen a download was rejected early — because the
Content-Lengthheader exceeded the size limit, the response status was not ok, or a redirect resolved to a blocked URL — the fetch response body was left unconsumed and uncancelled. With WHATWG Fetch/undici this leaves the underlying TCP socket open instead of returning it to the connection pool, allowing an attacker-controlled origin to exhaust file descriptors and cause a denial of service. The body is now cancelled on all early-rejection paths inreadResponseWithSizeLimit,download, anddownloadBlob, andfetchWithValidatedRedirectscancels each redirect hop's body before following or rejecting the next hop.v4.0.29Patch Changes
bfa5864: fix: only send provider credentials to same-origin response-supplied URLsSeveral provider clients followed a URL taken from the provider's API response (a polling/status URL or a final media URL such as
polling_url,urls.get,result_url,result.sample, orvideo.uri) and reused the authenticated headers — or appended?key=<API_KEY>— on that request. Because the host of the response-supplied URL was never validated, the long-lived API key was sent to whatever host the response named (a CDN in the benign case, or an attacker-chosen host if the provider response was tampered with), allowing credential exfiltration.A new
isSameOriginhelper is added to@ai-sdk/provider-utils, and the affected fetches in@ai-sdk/black-forest-labs,@ai-sdk/fireworks,@ai-sdk/replicate,@ai-sdk/gladia,@ai-sdk/fal, and@ai-sdk/googlenow attach credentials only when the followed URL is same-origin with the provider's configured API origin. Requests to a foreign origin are made without the credential.f42aa79: fix: harden download URL SSRF guard against hostname and redirect bypassesvalidateDownloadUrland the file download helpers (downloadBlob,download) could be bypassed in several ways when handling untrusted URLs:localhost.,myhost.local.) skipped the localhost/.localblocklist.::127.0.0.1), IPv4-translated (::ffff:0:127.0.0.1), and NAT64 (64:ff9b::127.0.0.1, including the64:ff9b:1::/48local-use prefix) — were not decoded and checked against the private IPv4 ranges.fetchhad already followed them, so the request to a redirect target (e.g. an internal/metadata address) had already been issued before the check ran.100.64.0.0/10, used by some cloud providers for internal traffic), benchmarking (198.18.0.0/15), IETF protocol assignments (192.0.0.0/24), the reserved240.0.0.0/4block (including the255.255.255.255broadcast address), and IPv6 site-local (fec0::/10) and multicast (ff00::/8).The validator now strips trailing dots before the hostname checks and fully expands IPv6 addresses to detect embedded private IPv4 targets. The download helpers now follow redirects manually (
redirect: 'manual'), re-validating each hop before requesting it, so an unsafe redirect target is never fetched. When a redirect cannot be inspected because the runtime returns an opaque response, the helpers fail closed (reject the redirect) on the server; only in a real browser — where SSRF is not reachable (fetch is constrained by CORS and cannot reach a server's internal network or cloud-metadata endpoints) — is the redirect followed natively so legitimate redirected downloads keep working.v4.0.27Compare Source
Patch Changes
f591416: feat(ai): add toolMetadata for tool specific metdatav4.0.26Compare Source
Patch Changes
7beadf0: feat(mcp): propagate the server name through dynamic tool partsConfiguration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.