Posts tagged "Security"

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

Vulnerability	Severity	Affected versions
CVE-2026-75604 / GHSA-p293-qw3h-jr36 — Unauthenticated remote code execution on Windows-hosted servers	Critical	≥13.4.0 <15.5.24, ≥16.0.0 <16.3.3
GHSA-2xp9-vwfh-vxw4 — Unauthenticated remote code execution in Image Optimization API when AVIF files are used	Critical	≥10.0.0 <15.5.24, ≥16.0.0 <16.3.3

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

Vulnerability	CVE	Severity	Affected versions	Patched in
Open redirect leading to XSS	CVE-2026-53668	Medium	≥6.30.2 ≤6.30.4, ≥7.9.6 <7.13.0	7.13.0
Unauthenticated Denial of Service in React Router __manifest endpoint	CVE-2026-55685	High	≥7.0.0 <7.18.0	7.18.0
RSCErrorHandler Missing Protocol Validation (XSS)	CVE-2026-53667	Medium	≥7.11.0 <7.18.0	7.18.0
Arbitrary client-side constructor injection via React Router SSR Hydration	CVE-2026-53666	Medium	≥6.4.0 <7.18.0	7.18.0
Unexpected external redirect via untrusted paths	CVE-2026-53669	Medium	≥6.0.0 <7.18	7.18.0

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.

Vulnerability	Severity	Affected versions
CVE-2026-64645 / GHSA-p9j2-gv94-2wf4 — Server-Side Request Forgery in rewrites via attacker-controlled destination hostname	High	≥12.0.0 <15.5.21, ≥16.0.0 <16.2.11
CVE-2026-64649 / GHSA-89xv-2m56-2m9x — Server-Side Request Forgery in Server Actions on custom servers	High	≥14.1.1 <15.5.21, ≥16.0.0 <16.2.11
CVE-2026-64642 / GHSA-6gpp-xcg3-4w24 — Middleware / Proxy bypass in App Router applications using Turbopack and single locale	High	≥16.0.0 <16.2.11
CVE-2026-64641 / GHSA-m99w-x7hq-7vfj — Denial of Service in App Router using Server Actions	High	≥13.0.0 <15.5.21, ≥16.0.0 <16.2.11
CVE-2026-64644 / GHSA-q8wf-6r8g-63ch — Denial of Service in the Image Optimization API using SVGs	Medium	≥15.5.0 <15.5.21, ≥16.0.0 <16.2.11
CVE-2026-64646 / GHSA-4c39-4ccg-62r3 — Unbounded Server Action payload in Edge runtime	Medium	≥13.0.0 <15.5.21, ≥16.0.0 <16.2.11
CVE-2026-64648 / GHSA-68g3-v927-f742 — Cache confusion of response bodies for requests with bodies	Medium	≥13.0.0 <15.5.21, ≥16.0.0 <16.2.11
CVE-2026-64647 / GHSA-4633-3j49-mh5q — Cache confusion of response bodies for requests with bodies containing invalid UTF-8 byte sequences	Medium	≥13.0.0 <15.5.21, ≥16.0.0 <16.2.11
CVE-2026-64643 / GHSA-955p-x3mx-jcvp — Unauthenticated disclosure of internal Server Function endpoints	Medium	≥13.0.0 <15.5.21, ≥16.0.0 <16.2.11

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

When you provision new users through SAML SSO, you now have more options for assigning a default role.

Before this update, the Developer role was assigned by default. Now you can assign other roles with fewer permissions, such as Reviewers and Internal Builders.

Learn more about your options for provisioning with SAML SSO on Netlify.

The React Router team has disclosed seven security vulnerabilities. Here’s what Netlify customers need to know.

Vulnerabilities

Vulnerability	Package	Affected versions	Fixed in
GHSA-8x6r-g9mw-2r78 — DoS via __manifest endpoint	react-router	7.0.0–7.14.x	7.15.0
GHSA-rxv8-25v2-qmq8 — DoS via single-fetch request body	react-router	7.0.0–7.13.x	7.14.0
GHSA-8646-j5j9-6r62 — XSS via javascript: redirect in unstable RSC	react-router	7.7.0–7.13.1	7.13.2
GHSA-49rj-9fvp-4h2h — RCE when chained with prototype pollution	react-router	7.5.2–7.14.1	7.14.2
GHSA-2j2x-hqr9-3h42 — Protocol-relative open redirect	react-router	7.0.0–7.14.0	7.14.1
GHSA-f22v-gfqf-p8f3 — Stored XSS in prerendered redirect HTML	@react-router/dev	7.0.0–7.13.1	7.13.2
GHSA-84g9-w2xq-vcv6 — CSRF check bypassed for PUT/PATCH/DELETE	react-router	7.12.0–7.15.0	7.15.1

Impact on Netlify

GHSA-8x6r-g9mw-2r78 and GHSA-rxv8-25v2-qmq8 (denial of service)

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.

GHSA-8646-j5j9-6r62 (XSS in unstable RSC)

This vulnerability affects apps using the experimental unstable_* RSC APIs where an attacker can control a redirect target. Only apps using these unstable APIs are affected.

Regardless of hosting provider, affected apps passing untrusted input into RSC redirect calls may be vulnerable.

GHSA-49rj-9fvp-4h2h (RCE when chained)

This vulnerability is not directly exploitable against React Router alone. Reaching the vulnerable code path requires the application to first be independently vulnerable to a prototype pollution attack.

GHSA-2j2x-hqr9-3h42 (open redirect)

Apps that redirect users to attacker-supplied URLs with the intent to restrict them to the same origin may inadvertently allow protocol-relative redirects to external origins.

Regardless of hosting provider, all affected apps passing untrusted input to redirect() may be vulnerable.

GHSA-f22v-gfqf-p8f3 (stored XSS in prerendering)

This vulnerability affects apps using the prerendering feature (prerender: [...] in react-router.config.ts). If any redirect target baked into a prerendered build originates from external or attacker-controlled data, the static artifact remains affected until a fresh build is run with a patched version.

Regardless of hosting provider, all affected apps using prerendering with externally sourced redirect targets may be vulnerable.

GHSA-84g9-w2xq-vcv6 (CSRF bypass for PUT/PATCH/DELETE)

The CSRF origin check introduced in React Router 7.12.0 only applied to POST requests on the document-request path, leaving PUT, PATCH, and DELETE unchecked. In practice, exploitation additionally requires the app to have explicitly opened CORS for those methods and to be issuing session cookies with SameSite=None.

Regardless of hosting provider, this only poses a meaningful risk in apps with permissive cross-origin configurations.

What should I do?

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

• react-router 7.15.1 or later
• @react-router/dev 7.13.2 or later (if using prerendering)

If your app uses prerendering, trigger a fresh build after upgrading to regenerate any affected static assets.

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

The Nuxt team has disclosed four security vulnerabilities. Here’s what Netlify customers need to know.

Vulnerabilities

• CVE-2026-47200: Route middleware bypass via island page endpoints (nuxt 3.11.0–3.21.5, 4.0.0-alpha.1–4.4.5)
• CVE-2026-46342: Island response not validated against request props (nuxt 3.1.0–3.21.5, 4.0.0-alpha.1–4.4.5)
• CVE-2026-45670: Dev server exposes built source over LAN (nuxt 3.15.4–3.21.5, 4.0.0-alpha.1–4.4.5)
• CVE-2026-45669: Reflected XSS via navigateTo with external: true (nuxt 3.4.3–3.21.5, 4.0.0-alpha.1–4.4.5)

Impact on Netlify

CVE-2026-47200 (route middleware bypass)

When component islands are enabled — the default in Nuxt 4, and available via an opt-in flag in Nuxt 3 — .server.vue page files are accessible via /__nuxt_island/page_* endpoints that render pages without invoking Vue Router, bypassing route middleware entirely. An unauthenticated attacker can request these endpoints directly to access pages that rely solely on middleware for access control.

Regardless of hosting provider, all affected Nuxt apps using .server.vue pages with route-middleware-only authentication are vulnerable.

CVE-2026-46342 (island cache poisoning)

The /__nuxt_island/* endpoint accepts props via query parameters without server-side hash validation, allowing the same path to return different content depending on query parameters. If an upstream cache keys on path only, an attacker can inject crafted props into cached responses — enabling XSS if the application renders those props through unsafe HTML sinks.

On Netlify, cached function responses vary by query string. This vulnerability requires overriding Netlify’s default Netlify-Vary behavior and is not exploitable in standard Netlify deployments.

CVE-2026-45670 (dev server source exposure)

Running nuxt dev --host binds the development server to a non-loopback address; with the rspack or webpack builder (not the default Vite builder), malicious sites on the same network can access the application’s source code. This only affects local development environments.

Netlify production deployments are not affected. Developers should avoid using --host with rspack or webpack builders, or upgrade to patch the issue.

CVE-2026-45669 (reflected XSS via navigateTo)

When navigateTo() is called with external: true, Nuxt generates a server-side HTML meta-refresh redirect. The destination URL is insufficiently sanitized — HTML-significant characters are not encoded, so an attacker who controls the URL parameter can inject arbitrary scripts that execute before the redirect occurs.

Regardless of hosting provider, all apps passing untrusted user input to navigateTo() with external: true are vulnerable.

What should I do?

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

• nuxt 3.21.6 or later (for Nuxt 3.x), or 4.4.6 or later (for Nuxt 4.x)
• @nuxt/rspack-builder and @nuxt/webpack-builder 3.21.6 or later, or 4.4.6 or later (if applicable)

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 advisories

Team Owners can now guarantee that projects stay within the team to meet compliance or ownership requirements by blocking every project from being transferred to another team.

Once a Team Owner blocks project transfers out of the team, even the Team Owner cannot transfer projects out of the team unless they change this setting, which is tracked in the team’s audit log.

Try it out

To change the setting, go to Team settings > Access & security > Transfer site settings and select Edit settings.

When transfers are blocked, the Transfer project action is hidden for every project owned by the team and the backend rejects transfer requests for those projects.

Enterprise defaults

Enterprise teams start with project transfers set to Blocked for security reasons, but Team Owners can change this setting to Allowed at any time. Only Team Owners can change this setting and changes are recorded in the team audit log.

Learn more

Learn more in our docs on Transferring a project.