Posts tagged "Security"

The Next.js team has disclosed seven security vulnerabilities in Next.js, patched on November 3, 2026 in 16.4.5 and 15.5.29. The issues span cached data leaking between users, exposure of HttpOnly cookies, cache poisoning, and cross-client response injection. 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 16.4.5 (or 15.5.29 on 15.x) and redeploying. One issue also needs an update to the OpenNext Netlify Next.js adapter, @netlify/plugin-nextjs 5.16.6. The adapter is auto-installed by default, so a redeploy picks it up. You only need to upgrade it manually if you pin its version. See What should I do? for full steps.

Vulnerabilities

Impact on Netlify

Not affected on Netlify

• GHSA-7qx7-33qx-rqx2 (SVG rejection bypass): Netlify projects are not affected. Image optimization on Netlify is handled by Netlify Image CDN, so the vulnerable Next.js image optimizer code is not used. Netlify Image CDN serves SVG images with a Content Security Policy that prevents scripts from running.
• GHSA-mfr8-8qww-v76h (use cache leak via unstable_cache): Netlify projects are not affected. This leak requires two requests to share a single server process’s in-progress cache fill. On Netlify’s serverless architecture each request is served by its own isolated invocation, so the required overlap cannot occur.
• GHSA-pc58-hwjq-p385 (cross-client response injection): Netlify projects are not affected. Netlify’s infrastructure frames responses itself, so a response with an incorrect length from your app cannot affect responses to other requests. However, on unpatched versions, a Route Handler that returns a fetched response unchanged can send a response that browsers fail to decode. Upgrading Next.js resolves it.

Information disclosure

• GHSA-vc7v-qv4w-wrv8 (nested use cache leak) and GHSA-rhh4-g77r-r9qj (binary use cache arguments): under the conditions in each advisory, content cached for one user or root param value (e.g. a locale or tenant) can be served to another. On Netlify, apps that meet those conditions are affected. Upgrading Next.js resolves both.
• GHSA-f3mh-rxg3-f5g2 (HttpOnly cookies in Edge responses): exploitation requires an attacker to already be able to run JavaScript on your site’s origin. It can then read cookies marked HttpOnly. On Netlify, this affects Edge Route Handlers and Edge API routes, and also cookies set in Next.js Middleware. The Netlify adapter update alone covers all of these. Upgrading Next.js fixes Edge Route Handlers and Edge API routes. The Middleware case is fixed in the Netlify adapter, so you also need adapter 5.16.6. See What should I do?.

Cache poisoning and availability

GHSA-vvgp-ww4w-46vf (cache poisoning of shared fallback shells): affects Next.js 16.4+ apps using Cache Components with the route shape described in the advisory. A single request can cause valid pages to return a cached 404 error. On Netlify, apps that meet those conditions are affected. Upgrading Next.js resolves it.

What should I do?

We strongly recommend upgrading as soon as possible:

• Upgrade next to 16.4.5 (or 15.5.29 if you’re on 15.x) and redeploy.

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

• Auto-installed adapter (default): redeploy — the update is applied automatically.
• Manually installed adapter: upgrade @netlify/plugin-nextjs to v5.16.6 and redeploy. Upgrading Next.js alone does not fix the Middleware case on Netlify. We recommend not pinning the adapter version so future fixes ship automatically.

A new deploy clears content cached by previous deploys in the same deploy context, including any entries affected by these issues. A production deploy does not clear the cache for branch deploys or Deploy Previews (and vice-versa). Purge affected entries in those contexts separately, purge the whole site or delete those deploys. If you’ve opted responses out of automatic invalidation with the Netlify-Cache-ID header, those stay cached after a deploy, so purge them on demand.

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

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