Changelog

The Nuxt team has disclosed several security vulnerabilities fixed in Nuxt 4.5.1 and 3.21.10, ranging from a high-severity server-side remote code execution (under specific conditions) to lower-severity and development-only issues. Here’s what Netlify customers need to know.

Vulnerabilities

• GHSA-9473-5f9j-94wq (High): remote code execution via server island props
• GHSA-48hr-524c-v5w3 (Medium): unauthorized component instantiation via server island props
• GHSA-hxvh-4h3w-prp9 (High): route rule authorization bypass when a route rule key contains an uppercase character
• GHSA-hxcr-hm88-mpq6 and GHSA-9pgf-384g-p7mv (High): server component denial of service
• GHSA-wm8w-6qjm-cv43 (High): cross-user disclosure of cached payloads (Nuxt 4.x only, 4.4.0 and later)
• GHSA-7c4v-fwgw-9rf7 (Low): dev server path disclosure
• GHSA-279x-mwfv-vcqv (Critical, development only): remote code execution in Nuxt DevTools, fixed in @nuxt/devtools@3.3.1

Impact on Netlify

Remote code execution (GHSA-9473-5f9j-94wq)

This issue only applies under uncommon conditions: it requires Vue’s runtime compiler (vue.runtimeCompiler: true, which is off by default) and a server island that forwards untrusted input into a component. Few applications meet both conditions, so real-world exposure is limited. We’ve proactively reached out to the very small number of Netlify customers whose projects could potentially be affected.

Route rule authorization bypass (GHSA-hxvh-4h3w-prp9)

This is a framework-level issue that affects Nuxt apps regardless of hosting provider. It is not specific to Netlify. You’re affected if you use routeRules with appMiddleware as an authorization gate and any rule key contains an uppercase character, such as a rule derived from a page like pages/Admin.vue or written explicitly as routeRules: { '/Admin': ... }. Because routing is case-insensitive by default, the page was served while its route rule (and the middleware guarding it) was silently skipped. This is a regression in the earlier fix for CVE-2026-53721, so upgrading only to 4.4.7 or 3.21.7 does not protect you. Upgrade to Nuxt 4.5.1 or 3.21.10, then audit any uppercase route rule keys used for access control.

Denial of service (GHSA-hxcr-hm88-mpq6, GHSA-9pgf-384g-p7mv)

These are server-side denial-of-service (DoS) vulnerabilities. On Netlify, these have minimal impact: our autoscaling serverless architecture means that a malicious request resulting in a crashed or hung function does not affect other requests. However, active exploitation could increase your function costs.

Cross-user payload disclosure (GHSA-wm8w-6qjm-cv43)

If you use the cache, swr, or isr route rules on authenticated pages that render user-specific data, a cached payload could be served to the wrong user. After upgrading, purge any upstream CDN cache (e.g. Akamai or Cloudflare) that may already be holding a leaked payload. Upgrading alone won’t evict it.

Development-only issues (GHSA-279x-mwfv-vcqv, GHSA-7c4v-fwgw-9rf7)

The Nuxt DevTools remote code execution and the dev server path disclosure only affect local development, not deployed Netlify sites. Still, refresh your lockfile so it picks up @nuxt/devtools@3.3.1.

What should I do?

We strongly recommend upgrading as soon as possible to a patched release:

• nuxt 4.5.1 or later (for Nuxt 4)
• nuxt 3.21.10 or later (for Nuxt 3)

Running npx nuxt upgrade --dedupe also refreshes your lockfile so it pulls in @nuxt/devtools@3.3.1, which fixes the critical development-only issue above.

Note that any publicly available deploy previews and branch deploys may remain vulnerable until they are automatically deleted. Consider deleting these deploys manually.

Resources

• Nuxt security post
• Nuxt security advisories

Anthropic’s Claude Opus 5 model is now available through Netlify’s AI Gateway and Agent Runners with zero configuration required.

Use the Anthropic SDK directly in your Netlify Functions without managing API keys or authentication. The AI Gateway handles everything automatically. Here’s an example using the Claude Opus 5 model:

import Anthropic from '@anthropic-ai/sdk';

export default async () => {
    const anthropic = new Anthropic();

    const response = await anthropic.messages.create({
        model: 'claude-opus-5',
        max_tokens: 4096,
        output_config: { effort: 'medium' },
        messages: [
            {
                role: 'user',
                content: 'How can AI improve my coding?'
            }
        ]
    });

    return new Response(JSON.stringify(response), {
        headers: { 'Content-Type': 'application/json' }
    });
};

Claude Opus 5 is available for all Function types and Agent Runners. You get automatic access to Netlify’s caching, rate limiting, and authentication infrastructure.

Learn more in the AI Gateway documentation and Agent Runners documentation.

The React Router team has disclosed five security vulnerabilities affecting React Router. These issues are patched in React Router 7.18.0 (one issue was patched earlier, in 7.13.0). Here’s what Netlify customers need to know.

Vulnerabilities

Impact on Netlify

Open redirect leading to XSS

Attacker-controlled redirect targets combined with path concatenation and useNavigate can escape the intended app path, resulting in open redirects or XSS via javascript: URLs. This affects Declarative, Data, and Framework mode apps that pass user-controlled values into navigation APIs.

Regardless of hosting provider, all apps passing untrusted data into navigation APIs may be vulnerable.

Unauthenticated Denial of Service in React Router __manifest endpoint

Deep, attacker-controlled paths can trigger expensive synchronous route matching, blocking the Node.js event loop with a single unauthenticated request to manifest endpoints (__manifest, and *.manifest in unstable RSC mode). This affects Framework mode with SSR only, including unstable RSC framework mode.

This is a server-side denial-of-service (DoS) vulnerability. On Netlify, this has minimal impact: our autoscaling serverless architecture means that a malicious request resulting in a crashed or hung function does not affect other requests. However, active exploitation could increase your function costs.

RSCErrorHandler Missing Protocol Validation (XSS)

One RSC redirect handling path was missing protocol validation. Apps that redirect to attacker-controlled values may execute dangerous schemes such as javascript:. This only affects apps using unstable RSC Data or RSC Framework mode.

Regardless of hosting provider, all RSC apps redirecting to untrusted values may be vulnerable. Note that this affects an experimental feature only.

Arbitrary client-side constructor injection via React Router SSR Hydration

Serialized server errors can carry a subtype that’s resolved against window during hydration. Apps that set user-controlled input into error.name could have this instantiate browser constructors such as EventSource, WebSocket, Worker, or Image. This affects Data and Framework mode SSR hydration.

Regardless of hosting provider, apps setting user-controlled values into error.name may be vulnerable. This requires an unusual application code path, so real-world impact is expected to be low.

Unexpected external redirect via untrusted paths

Backslash-based URL forms such as \\evil.com, /\evil.com, or \/evil.com can be interpreted by browsers as cross-origin navigations, bypassing protections that only account for //. This affects <Link>, useNavigate, and redirects across Declarative, Data, Framework, and RSC modes.

Regardless of hosting provider, all apps passing untrusted destinations to <Link>, useNavigate, or redirects may be vulnerable.

What should I do?

We strongly recommend upgrading as soon as possible to patched releases:

• react-router 7.18.0 or later (all five issues)
• react-router 7.13.0 or later addresses the open redirect leading to XSS issue only — upgrade to 7.18.0 for full coverage

Note that any publicly available deploy previews and branch deploys may remain vulnerable until they are automatically deleted. Consider deleting these deploys manually.

Resources

• Open redirect leading to XSS (CVE-2026-53668)
• Unauthenticated Denial of Service in React Router __manifest endpoint (CVE-2026-55685)
• RSCErrorHandler Missing Protocol Validation (XSS) (CVE-2026-53667)
• Arbitrary client-side constructor injection via React Router SSR Hydration (CVE-2026-53666)
• Unexpected external redirect via untrusted paths (CVE-2026-53669)

The Next.js team has disclosed nine security vulnerabilities, all patched in 15.5.21 and 16.2.11. The issues span server-side request forgery (SSRF), a middleware authorization bypass, denial of service (DoS), and cache/identifier disclosure. Here’s what Netlify customers need to know.

Summary

If you run Next.js on Netlify, upgrade next to 15.5.21 or 16.2.11 and redeploy. Netlify-hosted sites are not affected by three of these (Server Action Host forwarding, the Image Optimizer DoS, and the Edge-runtime OOM). The rest affect only apps using a specific pattern or configuration, and are resolved by upgrading — see Impact on Netlify for the per-issue verdict.

Vulnerabilities

All issues are patched in 15.5.21 and 16.2.11. Earlier minors of 15.x and 16.x will not be patched; affected projects must upgrade to a patched minor. Follow the GHSA links for full details.

Impact on Netlify

Server-side request forgery

CVE-2026-64645 / GHSA-p9j2-gv94-2wf4 (Server-Side Request Forgery in rewrites via attacker-controlled destination hostname): Netlify sites are affected if a rewrites() or redirects() rule builds the destination hostname from request input (static destinations are not). Upgrading Next.js resolves it.

CVE-2026-64649 / GHSA-89xv-2m56-2m9x (Server-Side Request Forgery in Server Actions on custom servers): Netlify sites are not affected — our edge overwrites inbound X-Forwarded-Host with the real host, so an attacker cannot redirect the Server Action’s outbound request to a host they control.

Middleware authorization bypass

CVE-2026-64642 / GHSA-6gpp-xcg3-4w24 (Middleware / Proxy bypass in App Router applications using Turbopack and single locale): Netlify sites are affected if they build with Turbopack and use the legacy middleware.ts convention with single-locale i18n. Webpack builds and the newer proxy.ts convention are not affected. Upgrading Next.js resolves it.

Denial of service

CVE-2026-64641 / GHSA-m99w-x7hq-7vfj (Denial of Service in App Router using Server Actions) and CVE-2026-64646 / GHSA-4c39-4ccg-62r3 (Unbounded Server Action payload in Edge runtime) are server-side DoS. On Netlify these have minimal impact: our autoscaling architecture means a hung or crashed function does not affect other requests, though active exploitation could increase your function costs. The Edge-runtime OOM specifically cannot exhaust memory on Netlify — request bodies are capped and each request runs in an isolated invocation. Upgrading Next.js resolves both.

CVE-2026-64644 / GHSA-q8wf-6r8g-63ch (Denial of Service in the Image Optimization API using SVGs): Netlify sites are not affected — /_next/image is served by Netlify Image CDN, so the vulnerable Next.js code path is not used.

Cache disclosure / confusion

CVE-2026-64648 / GHSA-68g3-v927-f742 (Cache confusion of response bodies for requests with bodies) and CVE-2026-64647 / GHSA-4633-3j49-mh5q (Cache confusion of response bodies for requests with bodies containing invalid UTF-8 byte sequences): Netlify sites are affected if they use the specific cached-fetch patterns — a cached fetch(new Request(url), init), or a cached binary-body POST fetch(). fetch(url, init) and cache: 'no-store' are not affected. Upgrading Next.js resolves both.

Information disclosure

CVE-2026-64643 / GHSA-955p-x3mx-jcvp (Unauthenticated disclosure of internal Server Function endpoints): Netlify sites are affected (low impact) if they use Cache Components with a reflective Server Action co-bundled alongside a use cache function. The leak is limited to opaque internal function identifiers — no credentials or PII. Upgrading Next.js resolves it.

What should I do?

We strongly recommend upgrading as soon as possible:

• Upgrade next to 15.5.21 or 16.2.11, then redeploy.

For Next.js 13.x and 14.x: patches target 15.x / 16.x — upgrade to a patched minor.

Note that any publicly available deploy previews and branch deploys may remain vulnerable until they are automatically deleted. Consider deleting these deploys manually.

Resources

• Next.js July 2026 security release
• Next.js security advisories

Google’s Gemini 3.6 Flash and Gemini 3.5 Flash-Lite models are now available through Netlify’s AI Gateway and Agent Runners with zero configuration required.

Use the Google GenAI SDK directly in your Netlify Functions without managing API keys or authentication. The AI Gateway handles everything automatically. Here’s an example using the Gemini 3.6 Flash model:

import { GoogleGenAI } from '@google/genai';

export default async () => {
  const ai = new GoogleGenAI({});

  const response = await ai.models.generateContent({
    model: 'gemini-3.6-flash',
    contents: 'How can AI improve my coding?',
  });

  return Response.json(response);
};

Gemini 3.6 Flash and Gemini 3.5 Flash-Lite are available for all Function types and Agent Runners. You get automatic access to Netlify’s caching, rate limiting, and authentication infrastructure.

Learn more in the AI Gateway documentation and Agent Runners documentation.

You can now invite a Developer or Internal Builder to your team without assigning them to an existing project.

Previously, the UI required every new Developer or Internal Builder to be given access to at least one existing project before you could add them. That got in the way of a common workflow: bringing someone on specifically to spin up new work, without handing them the keys to projects they don’t need to touch.

Because both roles can create their own projects directly, this is often exactly what teams want. Invite a new teammate, let them start building right away, and keep your existing projects untouched. When they create a project, they’re automatically assigned the Developer role on it, so they own the work they start without gaining access to everything else.

The result is cleaner, least-privilege onboarding: people get exactly the access they need to begin, and nothing more.

To try it, head to your team’s Members page and invite a Developer or Internal Builder without selecting any existing projects. Learn more about managing project access in our project access docs.

Team Owners on Pro plans can now limit Agent Runners spend for individual members in your team, giving you finer control over how AI credits are used across your team.

Set a single credit limit that applies to every member, then customize it with overrides for specific people who need more (or less) room to work. This makes it easy to give power users a higher ceiling while keeping predictable, budget-friendly defaults for everyone else.

You’ll find these controls in Team Settings under General > AI Enablement.

This builds on our existing team-wide AI usage limits, so you can now manage AI spend both for an entire team and down to each individual member.

We’ve also updated how AI inference credit usage is displayed in your dashboard, making it easier to monitor AI usage and manage your AI spend.

Learn more about AI inference usage and how credits work.

Team Owners on the credit-based Pro plan can now choose how many monthly credits come with their plan, instead of a single fixed amount. Pick the tier that fits your usage, and change it whenever your needs shift.

The new credit tiers, with rollover on higher tiers, can be especially helpful for teams with seasonal surges and teams with consistently high-credit usage and come with some per-credit cost savings.

What’s changing

Previously, every Pro plan included a fixed 3,000 monthly credits for $20/month.

New amounts for monthly credits

Now you can choose from five tiers:

All tiers include the same Pro plan features: unlimited seats, password protection, and everything else that comes with Pro.

Rollover credits on higher tiers

Choose 5,000 monthly credits or higher and unused credits rollover an additional billing cycle so you get an extra month to use them. The base 3,000-credit tier doesn’t roll over.

Change your tier anytime

Team Owners can switch tiers without limits to how many times they switch. Upgrades take effect immediately with a prorated refund; downgrades take effect next billing cycle. Learn more about switching between Pro tiers.

Learn more

• Pro plan
• How credits work
• Change your pricing plan
• Buy credit packs

OpenAI’s GPT-5.6 Sol, Luna, and Terra models are now available through Netlify’s AI Gateway and Agent Runners with zero configuration required.

Use the OpenAI SDK directly in your Netlify Functions without managing API keys or authentication. The AI Gateway handles everything automatically. Here’s an example using the GPT-5.6 Sol model:

import OpenAI from 'openai';

export default async () => {
    const openai = new OpenAI();

    const response = await openai.responses.create({
        model: 'gpt-5.6-sol',
        input: 'Give a concise explanation of how AI works.',
    });

    return Response.json(response);
};

GPT-5.6 Sol, Luna, and Terra are available for all Function types and Agent Runners. You get automatic access to Netlify’s caching, rate limiting, and authentication infrastructure.

Learn more in the AI Gateway documentation and Agent Runners documentation.