Changelog

Netlify Agent Runners now have a mode selector. Pick Ask and the agent reads, investigates, and answers questions about your project. Build is still the default and works exactly as before.

Ask mode is strictly read-only. The agent can’t edit files, run commands, deploy, or change settings. With no build or Deploy Preview, Ask runs are often faster and use fewer credits.

It answers with real context: your repository, your project context, and your project’s Netlify Database. Your data is often the fastest way to answer a question about your app, and Ask mode can query it with no risk of a write.

A few prompts to steal:

• “How many users are in the database?”
• “Walk me through how authentication is implemented in this project. Which files handle it, and where is the token stored?”
• “Our Largest Contentful Paint is bad on mobile. Read the code and tell me what’s most likely responsible.”
• “Plan out how we can migrate to the latest version of Astro.”

Because it’s a mode on the same run, you can switch to Build the moment an answer turns into a task — same run, same context, no re-explaining.

Ask mode is available on all agents, Claude Code, Google Gemini, and OpenAI Codex, in Agent Runners today. See the docs on Ask and Build modes.

GPT-5.6 Luna now costs 80% less and GPT-5.6 Terra is 20% less through Netlify AI Gateway, making both models more cost-efficient for production AI workloads.

These reductions improve the price-performance tradeoff across the GPT-5.6 model family, giving teams more flexibility to choose the right balance of capability and cost for each workload.

Learn more in OpenAI’s announcement, Advancing the price-performance frontier with GPT-5.6.

Teams on a Free, Personal, or Pro plan now have project visibility settings to ensure that all of your project stay private until you decide to make them public.

More people are shipping prototypes, internal tools, early client work, and projects built with agents. A deploy is often a work in progress, not a publication. Netlify now reflects that distinction.

Project visibility settings allow you to:

• quickly ensure your project stays internal for your Netlify team until you’re ready to launch more publicly.
• ensure that your project stays private for you and your Netlify team.
• choose defaults that keep internal-only projects private, such as for internal apps and tools or sensitive releases.

While project access affects who on your team can access a project from the Netlify dashboard, project visibility impacts who can view your project, both at the live URL and inside of Netlify, and requires Netlify login credentials if a project is set to private.

Starting defaults

Starting today, all new Netlify teams on a Free, Personal, or Pro plan will have their projects set to private by default. This means that new Netlify teams will need to adjust the project visibility of each new site or app to decide when to make them publicly available.

If you have an existing Free, Personal, or Pro plan (all credit-based plans), then your starting project visibility settings are set differently to keep the previous default behavior before project visibility settings launched.

This means all your project URLs stay publicly available unless you’ve set up other authentication with code or Netlify’s password protection options.

Change your project visibility

To change your project’s visibility, you can set a team default for all new and existing projects at: Team settings > General > Visitor access > Default project visibility

To change only one project’s visibility settings: Project configuration > General > Visitor access > Project visibility

Availability

Project visibility settings are only available for Credit-based Free, Personal, or Pro plans.

If you have a Legacy pricing plan, an Enterprise plan, an Open Source plan, you will not find project visibility settings. In this case though, you can still use password protection, Team login protection (for Enterprise only) or configure authentication with code.

Learn more

Learn more about setting up and managing project visibility in our docs.

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

Netlify Drop has a refreshed look, with even more support for your questions and guidance on what’s next after you drop your latest site or app.

We first launched Netlify Drop 13 years ago when we introduced the web to a simpler way to deploy your web project and get a custom link for it.

Since that time we’ve learned a lot about how people (and now agents) use Drop. You can learn more from our official blog post revisiting Netlify Drop and how it’s evolved over time.

Same core functionality with more context

The newly improved Drop page keeps the same core functionality, letting you drag and drop your project files or folder, while making it easier for you or an agent to find answers along the way.

For example, did you know Netlify can detect your framework and run a build step for you?

You don’t have to build your project first. If you drop a project folder that uses a framework requiring a build, we’ll direct you to log in first, then take care of the build step for you.

Try it out

Try it out at app.netlify.com/drop.

After you drop

After you drop a project, claim it to keep your project online and join millions of others, from solo builders to global brands, who manage their sites and apps on Netlify.

After you claim your project, you can keep building in your preferred workflow.

We’ve got you covered with more ways than ever to keep building and deploying:

• Keep dropping to update the same production URL
• Push your deployed project to a newly created GitHub repo
• Keep deploying with dev tools, such as our CLI or API
• Keep developing with popular AI agents directly from your Netlify dashboard using Agent Runners

From there you can keep launching with confidence, undo mistakes (even without Git), build with a team, and grow to any size, all starting from a drop.

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.