Posts tagged "Security"

The Next.js and React teams have disclosed three security vulnerabilities (two critical, one high), released on October 14, 2026: a remote code execution (RCE) in SVG image processing, an RCE in use cache (Cache Components), and a denial of service (DoS) in App Router Server Actions. Here’s what Netlify customers need to know.

Summary

If you run Next.js on Netlify, we strongly recommend upgrading next to 15.5.28 or 16.4.1 and redeploying. Several of these have limited or no impact on Netlify; see Impact on Netlify. See What should I do? for steps.

Vulnerabilities

All issues are patched in 15.5.28 and 16.4.1.

Impact on Netlify

Remote code execution

GHSA-673q-mjm6-r5xr is a Critical RCE affecting Next.js 16.x apps using Cache Components, triggered by a use cache function that returns typed arrays — an unusual configuration not expected in normally functioning applications. On Netlify, apps that meet those conditions are affected; upgrading Next.js resolves it.

GHSA-2464-fhr4-w9xw (CVE-2026-96889) is an RCE in the image library (sharp) Next.js uses to process SVGs. The advisory describes it through the next/image Image Optimization API — which on Netlify is served by Netlify Image CDN, not your function, so that path is not exercised on Netlify. The same flaw is reachable through next/og ImageResponse, which does run in your Netlify function: apps that render untrusted input via ImageResponse are affected. There, the impact is limited to a crashed function invocation, not code execution — minimal impact on our autoscaling serverless architecture, though active exploitation could increase your function costs. Upgrading Next.js (which also updates the bundled sharp) resolves it.

Denial of service

GHSA-p3m5-59mp-jv5r is a server-side DoS affecting App Router apps that define a Server Action. On Netlify, this has minimal impact: our autoscaling serverless architecture means a malicious request that consumes excessive CPU in one function does not affect other requests. However, active exploitation could increase your function costs. Upgrading Next.js resolves it.

What should I do?

We strongly recommend upgrading next to 15.5.28 or 16.4.1 and redeploying as soon as possible.

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 Security Update for Upstream Vulnerabilities
• Next.js security advisories

On private projects and sites protected with Netlify team login, your Netlify Functions and Edge Functions can now see who is making the request. The signed-in Netlify user is available as context.user, with their user ID, email address, and when their access expires.

This function returns the signed-in user’s ID, email address, and access expiry as JSON at /whoami, and responds with a 401 when context.user isn’t set:

import type { Config, Context } from '@netlify/functions'

export default async (req: Request, context: Context) => {
  if (!context.user) {
    return new Response('Unauthorized', { status: 401 })
  }

  return Response.json({
    id: context.user.id,
    email: context.user.email,
    expiresAt: context.user.expiresAt.toISOString(),
  })
}

export const config: Config = { path: '/whoami' }

Previously, protecting a site meant Netlify checked who could visit, but your code couldn’t tell who they were. Knowing who’s on the other end meant adding a second login of your own on top.

Now Netlify verifies the visitor at the edge and passes their identity to your code. Because context.user comes from Netlify and not from the request, a visitor can’t impersonate someone else by sending their own headers.

With context.user, you can build on the login your team already uses. Examples like:

• Internal dashboards and admin tools that show each person their own data
• Audit logs that record who made a change or triggered an action
• Approval and review workflows that know who approved what
• Per-person settings, permissions, or feature access inside an internal app

Learn more in the Netlify documentation:

• context.user in Netlify Functions
• context.user in Edge Functions
• Private projects
• Team login protection

The Next.js team has disclosed seven security vulnerabilities in Next.js (one high, five medium, one low), patched on September 30, 2026 in 15.5.27 and 16.3.8. The issues span server-side request forgery (SSRF), cache poisoning, and information disclosure. Several of them do not affect apps hosted on Netlify. Here’s what Netlify customers need to know.

Summary

Some of these vulnerabilities affect Next.js sites hosted on Netlify (details in Impact on Netlify), so if you run Next.js on Netlify, we strongly recommend upgrading next to 15.5.27 or 16.3.8 and redeploying. The OpenNext Netlify Next.js adapter must also be updated to @netlify/plugin-nextjs 5.16.1; it’s auto-installed by default, so a redeploy picks it up (a manual upgrade is only needed if you pin the version). See What should I do? for full steps.

Vulnerabilities

All issues are patched in 15.5.27 and 16.3.8.

Impact on Netlify

Not affected on Netlify

• GHSA-cjq9-62q9-8jv4 (Image optimizer SSRF): Netlify projects are not affected. Image optimization on Netlify is handled by Netlify Image CDN — a separate service outside your project’s functions — so the vulnerable Next.js image-optimizer code path is not used, and the Image CDN has its own protections against this class of SSRF.
• GHSA-3w37-wq28-93x7 (Draft Mode use cache content leak): Netlify projects are not affected. This leak requires two requests to share a single server process’s in-flight cache fill. On Netlify’s serverless architecture each request is served by its own isolated invocation, so the required overlap cannot occur.
• GHSA-39w2-rjm5-chcv (Development MCP information disclosure): Netlify projects are not affected. This affects the next dev development server only; Netlify serves production builds, which do not expose the development MCP endpoint.

Information disclosure

GHSA-f87g-xv8r-7p7x (Metadata image dynamicParams bypass) can expose content from routes excluded via dynamicParams through metadata image routes. It only affects Webpack builds; Turbopack builds are not affected. On Netlify, apps that use a Webpack build are affected; upgrading Next.js resolves it.

Cache poisoning and availability

GHSA-4jqv-mc3x-m676 and GHSA-mcj8-r9mp-w47p affect apps with SSG/ISR routes behind a root catch-all.

• GHSA-4jqv-mc3x-m676 (cross-route cache poisoning): Pages Router apps with SSG/ISR and a root catch-all route are affected on Netlify. Upgrading Next.js resolves the poisoning on its own. The fix also changes how cache entries are keyed, so you should update the Netlify adapter (5.16.1) as well — otherwise prerendered pages miss the cache and re-render (a serving/performance regression, not a security one). See What should I do?.
• GHSA-mcj8-r9mp-w47p (encoded paths / /index): App Router apps with a prerendered catch-all route are affected by an availability issue — certain valid percent-encoded URLs can return an error (HTTP 500) instead of the page. Upgrading Next.js resolves it.
• GHSA-h694-7cp9-m8p3 (cache leak across root param values): affects Next.js 16.x apps using Cache Components with a nested use cache that reads root params (e.g. locale or region segments) — an enclosing cache entry can be keyed without the root param and reused across values, so content produced for one value can be served for another. Upgrading Next.js resolves it.

What should I do?

We strongly recommend upgrading as soon as possible:

• Upgrade next to 15.5.27 or 16.3.8 and redeploy.

The OpenNext Netlify Next.js adapter that runs your app must also be updated to v5.16.1:

• Auto-installed adapter (default): redeploy — the update is applied automatically.
• Manually installed adapter: upgrade @netlify/plugin-nextjs to v5.16.1 and redeploy. We recommend not pinning the adapter version so future fixes ship automatically.

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 September 2026 security release
• Next.js security advisories

The TanStack team has disclosed a critical cross-site scripting (XSS) vulnerability in TanStack Start. A crafted URL can cause an affected app to return attacker-controlled HTML from its own origin, which may run attacker-supplied JavaScript in a visitor’s browser. Here’s what Netlify customers need to know.

Vulnerabilities

GHSA-qx66-fv34-fjm8 (CVE-2026-102989): Unauthenticated reflected XSS in server-function responses.

Impact on Netlify

This is a client-side cross-site scripting (XSS) vulnerability in TanStack Start’s server-function response handling. Because the malicious response is returned from the app’s own origin, an attacker who gets a victim to open a crafted link can run JavaScript in that visitor’s session — for example, to read their data or act as them on the site. All applications on an affected version should upgrade.

What should I do?

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

• @tanstack/react-start 1.168.60 or later
• @tanstack/solid-start 1.168.57 or later
• @tanstack/vue-start 1.168.56 or later
• @tanstack/start-server-core 1.169.39 or later

Not sure if you’re affected?

Open your project in Agent Runners in ask mode and try this prompt:

Does this project use TanStack Start? If so, which versions of `@tanstack/react-start`, `@tanstack/solid-start`, `@tanstack/vue-start`, and `@tanstack/start-server-core` are resolved in the lockfile? Is the resolved `@tanstack/start-server-core` version 1.169.39 or later? If not, what do I need to change to upgrade? (Advisory: GHSA-qx66-fv34-fjm8)

Ask mode answers without changing your code. If an upgrade is needed, switch to Build mode to make the change, preview, and redeploy.

Deploy previews and branch deploys

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

Resources

• GitHub security advisory (GHSA-qx66-fv34-fjm8)
• TanStack security update: CVE-2026-102989
• CVE-2026-102989

The Next.js team has disclosed a critical severity vulnerability in an upstream dependency that can lead to remote code execution when ImageResponse renders untrusted input. It is patched in 15.5.26 and 16.3.6. Applications that do not pass untrusted input into ImageResponse are not expected to be affected. Here’s what Netlify customers need to know.

Vulnerabilities

• GHSA-vcvr-r3jv-pc5j / CVE-2026-94545 — Remote Code Execution in next/og ImageResponse. Critical. Patched in 15.5.26 and 16.3.6.

Impact on Netlify

Netlify sites are affected only if they use ImageResponse and the image it generates includes untrusted input — text, or an image loaded from the request. Sites that don’t use ImageResponse, or that only render trusted content through it, are not affected.

For sites that do, the impact is limited to a crashed function invocation, not code execution. On Netlify, this has minimal impact: our autoscaling serverless architecture means that a malicious request resulting in a crashed function does not affect other requests. However, active exploitation could increase your function costs.

What should I do?

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

• next 15.5.26 or later, or 16.3.6 or later, then redeploy.

Until you can upgrade, do not place untrusted input inside elements passed to ImageResponse. Escape it as XML before rendering, or keep it out of the generated image entirely.

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 security advisory (GHSA-vcvr-r3jv-pc5j)
• Next.js Security Update for a Critical Upstream Issue
• Next.js security advisories

The Next.js team has disclosed two critical severity vulnerabilities, both of which can lead to unauthenticated remote code execution. Both are patched in 15.5.24 and 16.3.3. Netlify-hosted sites are not affected by the Windows issue, and do not run the Next.js code path affected by the image issue. We still recommend upgrading. Here’s what Netlify customers need to know.

Vulnerabilities

Impact on Netlify

Unauthenticated remote code execution on Windows-hosted servers

CVE-2026-75604 / GHSA-p293-qw3h-jr36: Netlify sites are not affected. The issue affects Windows-hosted deployments only, and Netlify Functions and Edge Functions run on Linux.

Unauthenticated remote code execution in Image Optimization API when AVIF files are used

GHSA-2xp9-vwfh-vxw4: Netlify sites do not run the affected Next.js code path. Requests to /_next/image are rewritten to Netlify Image CDN at our edge, so the Next.js Image Optimization API is never invoked.

What should I do?

Netlify sites are not affected by the Windows issue and do not run the affected image code path, but we always strongly recommend upgrading as soon as possible to patched releases:

• next 15.5.24 or later, or 16.3.3 or later, then redeploy.

Resources

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

If your team uses SSO (single sign-on) with an identity provider, you can now sign in with just your email address without using your team ID. Netlify recognizes your domain and sends you straight to your identity provider.

Previously, SSO required you to know your Team ID. That meant every new hire had to know and enter a Team ID, and anyone who forgot or didn’t know it was stuck at the login screen. It was a small detail that quietly created support work for the people administering the team.

Now the flow is simplified: enter your email, get redirected to whichever identity provider your team has configured, authenticate there, and land back in Netlify.

This is live for every team using SSO with an identity provider that lets you use your email address to authenticate. This means your existing SAML setup already carries everything Netlify needs to route people to the right place.

Learn more about configuring SAML SSO in the Netlify documentation.

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

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)