chore(deps): bump @ai-sdk/provider-utils from 4.0.23 to 4.0.33 in /packages/core

DE
13d ago
+1-1

Bumps @ai-sdk/provider-utils from 4.0.23 to 4.0.33.

Changelog

Sourced from @​ai-sdk/provider-utils's changelog.

4.0.33

Patch Changes

  • b30e43a: Limit JSON response body reads in response handlers to prevent unbounded memory use.

4.0.32

Patch Changes

  • Updated dependencies [f19334d]
    • @​ai-sdk/provider@​3.0.12

4.0.31

Patch Changes

  • 1b40ac7: Publish all packages under the @ai-v6 dist tag.
  • Updated dependencies [1b40ac7]
    • @​ai-sdk/provider@​3.0.11

4.0.30

Patch Changes

  • 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.

4.0.29

Patch Changes

  • 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 after fetch 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.

... (truncated)

Commits
Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for @​ai-sdk/provider-utils since your current version.


Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    You can disable automated security fix PRs for this repo from the Security Alerts page.

Summary by cubic

Updates @ai-sdk/provider-utils in packages/core from 4.0.23 to 4.0.33, bringing upstream security and resource-safety fixes. JSON response reads are now bounded, rejected downloads cancel response bodies, credentials stay on same-origin requests, and download redirects are validated before they are fetched.