Nine vulnerabilities announced, seven actually fixed, two postponed — all within a single calendar week. Anyone running Next.js in production has seen this pattern before in September 2026: first a critical zero-day patch, then a comprehensive security release. The Next.js September 2026 Security Release marks the current conclusion of this series and ships two new version lines: 15.5.27 for the Maintenance LTS track and 16.3.8 for the Active LTS track.
On September 30, 2026, the Next.js team at Vercel published the official security release, following an advance notice on September 23 that named nine vulnerabilities. For technical reasons — delays in upstream dependencies — two of those issues, one critical and one high, were not fixed in time. The final release addresses seven vulnerabilities: one high, five medium, and one low severity. This article breaks down the facts, explains the risks, and gives concrete upgrade steps.
Table of Contents
Key Takeaways
- The Next.js September 2026 Security Release shipped on September 30, 2026 as Next.js 15.5.27 (Maintenance LTS) and 16.3.8 (Active LTS).
- Of the nine vulnerabilities originally announced, seven were finally fixed: 1 high, 5 medium, 1 low; two fixes (critical and high) were postponed due to upstream delays.
- The most severe fixed issue is an SSRF vulnerability in Image Optimization (CVE-2026-94483), which only affects projects with
images.remotePatternsconfigured. - Several cache-poisoning and information-disclosure bugs mainly affect self-hosted deployments, Webpack builds, and projects with Cache Components enabled.
- This release follows an out-of-band patch on September 22, 2026 for a critical RCE vulnerability (CVE-2026-94545) in the next/og ImageResponse API.
What happened in the Next.js September 2026 Security Release?
The disclosure followed the now-established coordinated pattern: on September 23, 2026, Vercel first gave advance notice of nine identified vulnerabilities without disclosing technical details, to avoid giving attackers a head start. That gave affected teams a week of lead time to prepare internally.
On September 30, the actual release followed with full advisories, CVE numbers, and patched packages. Two of the originally nine issues — one critical, one high severity — could not be finally closed by that date because the underlying fixes depended on external upstream dependencies that weren’t yet available. The Next.js team decided to ship the seven already-finished fixes on schedule rather than delaying the entire release.
In practice, this means: teams that update now close seven real attack vectors, but should keep watching the Next.js team’s communication on the two still-open issues. The release was independently confirmed by Netlify’s changelog, which serves as a verification point for teams hosting on Netlify.
The seven fixed vulnerabilities in detail
The fixes span several functional areas of Next.js, from image optimization to the dev server. The table below summarizes severity and core risk.
| No. | Vulnerability | Severity | CVE / GHSA |
|---|---|---|---|
| 1 | SSRF in Image Optimization | High | CVE-2026-94483 (GHSA-cjq9-62q9-8jv4) |
| 2 | Cache poisoning of SSG/ISR pages (self-hosted) | Medium | — |
| 3 | Cache poisoning via root-level catch-all pages | Medium | — |
| 4 | Info disclosure in metadata image routes | Medium | — |
| 5 | Cache leak in nested ‘use cache’ functions | Medium | — |
| 6 | Draft Mode leak via pending ‘use cache’ fill | Medium | — |
| 7 | Info disclosure via the dev server’s MCP endpoint | Low | CVE-2026-94486 (GHSA-39w2-rjm5-chcv) |
1. SSRF in Image Optimization (High). If images.remotePatterns is configured in a way that allows an attacker-controlled remote URL onto the allow list, the Image Optimization component can be made to send requests to arbitrary targets, including private IP ranges inside the internal network. If images.remotePatterns is not configured at all, there is no attack surface.
2. and 3. Cache poisoning. Two different mechanisms allow the shared response cache to be poisoned: one via SSG/ISR pages in the Pages Router on self-hosted deployments, the other via root-level catch-all pages combined with SSG/ISR. In the second case, a single unauthenticated, crafted request is enough to corrupt content for other users and trigger a persistent denial of service. Vercel-hosted apps are not affected by case 2.
4. Information disclosure in metadata image routes. Via a dynamicParams bypass, App Router routes such as opengraph-image or twitter-image can leak information — but only in apps built with Webpack rather than Turbopack.
5. Cache leak in nested ‘use cache’ functions. With Cache Components enabled, the cache key of an outer function can incorrectly omit a root parameter. The result: users receive content that was actually meant for a different parameter value.
6. Draft Mode leak. A still-“pending” cache fill under ‘use cache’ can leak Draft Mode preview content into regular, persisted responses — relevant for pages with Cache Components (or experimental.useCache) enabled.
7. Information disclosure via the MCP endpoint (Low). The next dev dev server does not verify the origin of incoming requests to its Model Context Protocol endpoint. If a developer visits a malicious website in the browser, that site can read the project’s file path, code snippets from error reports, the route inventory, and dev logs. Production deployments are not affected — only the local development environment.
Who is affected? Scope check for the Next.js September 2026 Security Release
Not every project is affected by all seven issues equally. A quick scope check helps with prioritization:
- Is
images.remotePatternsconfigured? If so, urgently check the SSRF issue (No. 1) — it’s the highest-severity fix in this release. - Self-hosted instead of Vercel? Then the cache-poisoning issues (No. 2, partly No. 3) are relevant.
- Root-level catch-all pages with SSG/ISR? Affects practically every hosting model, not just self-hosted.
- Built with Webpack instead of Turbopack? Then the metadata info disclosure (No. 4) needs attention.
- Cache Components or
experimental.useCacheactive? Check No. 5 and No. 6. next devused locally? Every developer machine is potentially exposed to No. 7, regardless of the production setup.
A blanket “everyone is affected” claim would be an exaggeration — most issues only apply under specific configurations. Still, one upgrade fixes all seven at once, regardless of which configuration is currently in use.
Recommended action: how to update now
The fix is technically simple. Depending on the version line in use, a single command is enough:
npm install next@15.5.27
for projects on the 15.5 line, or
npm install next@16.3.8
for projects on the 16.3 line. After installing, a redeploy is required for the patch to take effect in production — a dependency bump without a redeploy closes no vulnerability.
Recommended order for teams:
- Identify your version line (15.5 or 16.3) and run the matching command.
- Check your configuration for
images.remotePatterns, Webpack builds, and Cache Components usage to gauge urgency. - Test on staging, especially image optimization and cache behavior.
- Redeploy to production.
- For self-hosted setups: verify cache invalidation after the update to clear any already-poisoned cache entries.
- Update local development environments (
next dev) too, even though they carry no production risk.
Since two vulnerabilities — one critical, one high — remain open, technical leads should keep monitoring the official channels (nextjs.org/blog and the relevant hosting provider’s changelog) over the coming weeks.
Context: the September 2026 security update series
The September 30 security release doesn’t stand alone. Just eight days earlier, on September 22, 2026, the Next.js team had already published an out-of-band update: Next.js 16.3.6 and 15.5.26 fixed a critical remote code execution vulnerability (CVE-2026-94545, CVSS 9.5) in the next/og ImageResponse API. The root cause was improper escaping in the SVG output generated by the Satori library.
That means the Next.js ecosystem experienced two separate security events within a single month: an unplanned critical hotfix and a planned, comprehensive monthly release. For technical decision-makers, the lesson is clear: patch management processes for Next.js shouldn’t be built around a single annual or quarterly cadence — they need to account for short-notice out-of-band patches too. The fact that two fixes from the September 23 advance notice didn’t make it into the final September 30 release also shows that upstream dependencies remain a limiting factor even for a well-organized framework team.
Conclusion
For more context on how the Next.js ecosystem compares to other backend stacks, see our PHP vs. Node.js vs. MySQL comparison for backend beginners.The Next.js September 2026 Security Release closes seven concrete vulnerabilities, ranging from a high-severity SSRF issue in Image Optimization to a low-severity information leak in the dev server. None of the issues call for panic, but each deserves a sober review of your own configuration. In particular, images.remotePatterns, your hosting mode (self-hosted versus Vercel), the bundler you use (Webpack versus Turbopack), and your use of Cache Components determine which of the seven fixes are actually security-relevant for a given project.
The concrete next step is simple: run npm install next@15.5.27 or npm install next@16.3.8, redeploy, and walk through your own configuration against the scope criteria above. Given the preceding critical patch from September 22, it’s also worth auditing the Next.js version across your entire project portfolio once, so no deployment is left running outdated packages. Teams that act on this promptly reduce their attack surface to the documented minimum for this release and will be ready for the two still-pending fixes once the Next.js team ships them.
