Link to headingSummary

We have shipped a coordinated security release for Next.js addressing 13 advisories across denial of service, middleware and proxy bypass, server-side request forgery, cache poisoning, and cross-site scripting. One advisory addresses an upstream React Server Components vulnerability tracked as CVE-2026-23870.

Link to headingRecommended actions

Patched versions are available for both React and Next.js, and all affected users should upgrade immediately.

Link to headingImpact

The release addresses the following advisories:

Link to headingMiddleware and proxy bypass

Affects applications that rely on middleware.js or proxy.js for authorization.

• High: Auth bypass via App Router segment-prefetch URL

• High: App Router segment-prefetch bypass, incomplete fix follow-up

• High: Pages Router i18n default-locale path bypasses proxy authorization

• High: Bypass via dynamic route parameter injection

• Low: Middleware redirects can be cache-poisoned

Link to headingDenial of service

Affects applications using Server Functions, Partial Prerendering with Cache Components, or the Image Optimization API.

• High: DoS in React Server Components (tracked upstream as CVE-2026-23870)

• High: DoS via connection exhaustion in applications using Cache Components

• Moderate: DoS via the Image Optimization API

Link to headingServer-side request forgery

Affects applications that handle WebSocket upgrade requests.

• High: SSRF in applications using WebSocket upgrades

Link to headingCache poisoning

Affects applications with caching layers in front of React Server Component responses.

• Moderate: Cache poisoning in React Server Component responses

• Low: Cache poisoning via collisions in RSC cache-busting

Link to headingCross-site scripting

Affects applications using CSP nonces in App Router, or beforeInteractive scripts that consume untrusted input.

• Moderate: XSS in App Router applications using CSP nonces

• Moderate: XSS in beforeInteractive scripts with untrusted input

Link to headingResolution

These vulnerabilities are addressed by the patched releases of React and Next.js. Patching is the only complete mitigation, and all affected users should upgrade immediately.

Vercel has not deployed new WAF rules for this release; these advisories cannot be reliably blocked at the WAF layer.

Link to headingAffected versions

Link to headingFixed in

• Next.js: 15.5.18, 16.2.6

• React: 19.0.6, 19.1.7, 19.2.6 for the react-server-dom-parcel, react-server-dom-webpack and react-server-dom-turbopack packages

Frameworks and bundlers using react-server-dom-* packages should install the latest versions provided by their respective maintainers.

Link to headingReferences

• Upstream React advisory (CVE-2026-23870)

You can now store JSON values in Vercel Flags, extending the existing support for boolean, string, and number values. This allows you to collapse what used to take several related flags into a single feature flag.

For example, to A/B test how a different model performs, you can now define a single model flag. This allows you to manage one flag that serves the full object rather than managing ai_model, ai_temperature, and ai_max_tokens separately:

1
// Variant A
2
{
3
  "id": "claude-sonnet-4-6",
4
  "temperature": 0.7, 
5
  "maxTokens": 1024,
6
  "systemPrompt": "You are a helpful shopping assistant."
7
}
8

9
// Variant B
10
{
11
  "id": "claude-opus-4-6",
12
  "temperature": 0.8, 
13
  "maxTokens": 2048,
14
  "systemPrompt": "You help with shopping."
15
}

Use Vercel Flags to progressively route traffic to a new model, A/B test, or quickly switch models in case a provider is having issues.

Try it out or learn more about Vercel Flags.

Pro teams can now choose how Git committers to private repositories are added to their Vercel team.

• Auto Approval: non-team committers with Vercel accounts are automatically added to your team and their deployments proceed immediately. Added members count toward your team seats at standard Pro pricing.

• Manual Approval: deployments are blocked until an owner approves the new member.

Choose your approval preference in team settings.

Learn more about collaboration settings and troubleshooting project collaboration.

You can now secure native integration resources by restricting where they can be used. Setting a resource to Production only removes non-production access and protects credentials as sensitive environment variables. This makes it so secret values or no longer readable from the dashboard or CLI

From the integration resource Settings, select Allowed Environments → Production only and save. We recommend that you rotate the secrets of the integration resource after saving.

Once applied:

• Development and Preview connections are removed

• New non-production connections are blocked

• Connections without a Production target are disconnected

• Credentials are protected and no longer readable

Reverting this setting requires Owner permissions for your Vercel team. Owners can re-enable Development and Preview environment from Settings and reconnect projects if needed. You may be prompted to reauthenticate with an MFA challenge depending on your settings. Learn more in the Vercel documentation.

You can now access Observability Plus metrics in the Vercel CLI.

Query observability data for any Vercel team or project using the new vercel metrics command. Coding agents can also leverage this new command to better analyze the performance, reliability, or security of applications on Vercel, as well as debug issues.

This feature is available in public beta for all teams with Observability Plus.

Learn more about vercel metrics.

Vercel Sandbox can now connect to hosted Postgres databases, including Neon, Supabase, AWS RDS, Nile, and Prisma Postgres. To enable a connection, add the database host to your Sandbox's allowed domains.

Link to headingBackground

When SNI based filtering is used with Vercel Sandbox, the sandbox firewall restricts outbound network access by checking the domain name during a connection's TLS handshake. This works seamlessly for HTTPS traffic, where the domain is visible at the start of the connection.

Postgres, however, negotiates TLS differently. A Postgres client first opens a plain TCP connection and then upgrades to TLS. Because the domain isn't available when the firewall first needs it, Postgres connections through a standard domain-restricted Sandbox would fail.

Link to headingWhat changed

The Sandbox firewall now adjusts for the Postgres TLS negotiation flow. It detects the protocol's startup sequence, waits for the TLS upgrade, and then applies your domain policy before forwarding the connection to the database. No changes are needed to your code or database configuration.

Link to headingConnecting to hosted database

Here's a full example: create a Sandbox, install a Postgres client, lock down the network to only the database host, and run a query.

1
import { Sandbox } from '@vercel/sandbox';
2

3
const { PGHOST, PGUSER, PGPASSWORD, PGDATABASE } = process.env;
4
const connectionString = `postgres://${PGUSER}:${PGPASSWORD}@${PGHOST}:5432/${PGDATABASE}?sslmode=require`;
5

6
// Start with unrestricted network access to install dependencies.
7
const sandbox = await Sandbox.create();
8

9
await sandbox.runCommand({
10
  cmd: 'sudo',
11
  args: ['dnf', 'install', '-y', 'postgresql15'],
12
});
13

14
// Lock the sandbox down to only the database host before running untrusted code.
15
await sandbox.updateNetworkPolicy({
16
  allowDomains: [PGHOST!],
17
});
18

19
const result = await sandbox.runCommand({
20
  cmd: 'psql',
21
  args: [connectionString, '-c', 'SELECT now();'],
22
});
23

24
console.log(await result.stdout());

Link to headingImportant to know

• TLS is required: Domain-based rules rely on the hostname being visible during the TLS handshake, so clients must connect with sslmode=require or higher. If your database doesn't support TLS, you can allow it by IP range instead. Most managed Postgres providers require TLS by default.

• GSSAPI encryption is not supported: Clients using gssencmode=prefer will fall back to TLS automatically; gssencmode=require will not connect.

• No silent downgrades: If a client uses sslmode=prefer and the database doesn't support TLS, the connection will fail rather than silently falling back to plain-text.

Learn more about the Sandbox firewall.

Grok 4.3 is now available on Vercel AI Gateway. The model has a 1M token context window and improvements in accuracy, tool calling, and instruction following.

To use Grok 4.3, set model to xai/grok-4.3 in the AI SDK.

1
import { streamText } from 'ai';
2

3
const result = streamText({
4
  model: 'xai/grok-4.3',
5
  prompt: 'Analyze this dataset and summarize the key trends.',
6
});

AI Gateway provides a unified API for calling models, tracking usage and cost, and configuring retries, failover, and performance optimizations for higher-than-provider uptime. It includes built-in custom reporting, observability, Bring Your Own Key support, and intelligent provider routing with automatic retries.

Learn more about AI Gateway, view the AI Gateway model leaderboard or try it in our model playground.

As teams scale isolated environments for AI agents, code generation, or dev workflows, keeping track of which sandbox belongs to whom, and why, becomes critical. Custom tags allow you to organize, filter, and manage Vercel Sandboxes at scale. Each sandbox supports up to five tags.

Link to headingOrganize by environment, team, or customer

Tags are flexible by design. Use them to separate staging from production, attribute usage to specific teams, or isolate sandboxes per customer in multi-tenant platforms:

1
const sandbox = await Sandbox.create({
2
  name: "my-sandbox",
3
  tags: { env: "staging" },
4
});

Link to headingUpdate tags as context changes

Promote a sandbox from staging to production, reassign ownership, or mark it for cleanup without recreating it:

1
await sandbox.update({
2
  tags: { env: "production", team: "infra" },
3
});

Link to headingEasily track your sandboxes

Filter sandboxes by any tag to quickly surface the ones that matter. This is useful for dashboards, cleanup scripts, or routing logic that needs to find all sandboxes matching a specific environment or team:

1
const productionSandboxes = await Sandbox.list({
2
  tags: { env: "production" },
3
});
4
console.log(
5
  "Production sandboxes:",
6
  productionSandboxes.sandboxes.map((s) => s.name),
7
); // my-sandbox

Link to headingUse Cases

• AI agents at scale: Tag sandboxes by session, user, or agent run to track which execution environment belongs to which workflow.

• Multi-tenant platforms: Isolate and filter sandboxes per customer or workspace, making billing attribution and cleanup straightforward.

• Team-level visibility: Attribute sandbox usage to specific teams for cost tracking or capacity planning.

This feature is in beta and requires upgrading to the beta SDK and CLI packages. Learn more in the documentation.