You can now run commands with sudo inside Vercel Sandbox, giving you full control over runtime environment setup, just like on a traditional Linux system.

This makes it possible to install system dependencies at runtime, like Go, Python packages, or custom binaries, before executing your code.

sudo is available via the runCommand method:

import { Sandbox } from "@vercel/sandbox";

const sandbox = await Sandbox.create();
await sandbox.runCommand({
  cmd: "dnf",
  args: ["install", "-y", "golang"],
  sudo: true,
});

The sandbox sudo configuration is designed to be easy to use:

• PATH is preserved

• HOME is set to /root

• Custom environment variables like env: { FOO: "bar" } are passed through

With sudo on Sandbox it's easier to run untrusted code in isolated environments with the right permissions, with no workarounds required.

Learn more about Vercel Sandbox and sudo in the documentation.

Vercel now automatically correlates logs with distributed traces for customers using OpenTelemetry to instrument their applications.

Traces are a way to collect data about the performance and behavior of your application and help identify the cause of performance issues, errors, and other problems. OpenTelemetry (OTel) is an open source project that allows you to instrument your application to collect traces.

When a request is traced using OTel, Vercel will enrich the relevant logs with trace and span identifiers. This allows you to correlate your individual logs to a trace or span.

This feature is available to customers using log drains through our integrations with Datadog and Dash0. No action is required and log to trace correlation will happen automatically going forward for customers using OTel with any of these integrations.

Learn more about correlating logs to traces using log drains.

Summary

A cache poisoning vulnerability affecting Next.js App Router >=15.3.0 < 15.3.3 / Vercel CLI 41.4.1–42.2.0 has been resolved. The issue allowed page requests for HTML content to return a React Server Component (RSC) payload instead under certain conditions. When deployed to Vercel, this would only impact the browser cache, and would not lead to the CDN being poisoned. When self-hosted and deployed externally, this could lead to cache poisoning if the CDN does not properly distinguish between RSC / HTML in the cache keys.

Impact

Under specific conditions involving App Router, middleware redirects, and omitted Vary headers, applications may:

• Serve RSC payloads in place of HTML

• Cache these responses at the browser or CDN layer

• Display broken or incorrect client content

This issue occurs in environments where middleware rewrites or redirects result in improper cache key separation, because the cache-busting parameter added by the framework is stripped by the user’s redirect.

Resolution

The issue was resolved in Next.js 15.3.3 by:

• Ensuring the Vary header is correctly set to distinguish between different content types

Customers hosting on Vercel with deployments that used the impacted CLI versions must redeploy their applications to receive the fix.

Workarounds

• Manually add the Vary header on RSC responses to differentiate between RSC and HTML payloads. Specifically, Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch.

• Apply a unique cache-busting search parameter to the middleware redirect destination

Credit

Thanks to internal incident response teams and affected Vercel customers for timely reports and debugging assistance.

References

• Fix in Next.js v15.3.3

• GitHub Issue #79346

• GHSA-r2fc-ccr8-96c4