On October 8, the Next.js team announced a security update outside the usual schedule, set for October 14. It fixes three vulnerabilities in third-party dependencies: two critical and one high severity. Two of them had already been identified in September, but the fix was held back to give time to coordinate disclosure with the maintainers of those libraries.
This is the third security patch cycle in roughly a month. If you run a Next.js project in production, it's worth checking your version today.
Out-of-band security patch with three upstream vulnerabilities (two critical, one high) scheduled for 10/14. Next.js 15 reaches end of life on 10/21. Update to the patch version for your line, deploy, and confirm the version running in production.
Recent timeline
- September 22: out-of-band release with versions 16.3.6 and 15.5.26, fixing a critical remote code execution issue in
next/og. According to Estont's analysis, the 15.x line was not affected by that issue. - September 30: versions 16.3.8 (active LTS) and 15.5.27 (maintenance). The official notice lists seven vulnerabilities: one high, five medium, and one low. Some third-party sources count nine, including one critical. For the exact affected configurations, read each advisory on the official site.
- October 14: out-of-band update for the three upstream vulnerabilities that were held back from September.
- October 21: Next.js 15 reaches end of life.
The count varies from source to source, but the advice is the same: be on at least 16.3.8 or 15.5.27 before today's update.
What upstream vulnerabilities are
An upstream vulnerability isn't in the framework's own code. It lives in a library Next.js relies on underneath, such as image processing, HTTP parsers, or cache and proxy components. The fix has to land in that library first and only then reach Next.js. That's why the announcement mentioned coordinating with the original authors, and why the date wasn't the usual one.
When this was written, the official October 14 notice didn't list the affected packages, the vulnerability identifiers, or the patched versions. If you see library names or CVE numbers elsewhere, check them against the official notice before relying on them.
Images: who is most exposed
Among the September fixes, one high-severity issue is an SSRF in Image Optimization, tracked as CVE-2026-94483. According to Netlify and daily.dev, it only affects apps that have images.remotePatterns configured. If your config doesn't set that field, your exposure there is lower, but the update is still recommended.
The cache poisoning issue in SSG and ISR pages affects self-hosted Pages Router apps. According to Netlify, apps hosted on Vercel are not affected by it.
What the Next.js 15 end of life changes
Next.js 15 reaches end of life on October 21, 2026. Until then, the line only gets critical and security fixes, no new features. After that date there's no guarantee of new patches. Any fix for an unsupported version would be a case-by-case decision by the team.
In practice, today's patch is likely one of the last for the 15 line. If your project is on a version older than 15.5, the recommendation is to migrate to the 16 line. According to endoflife.date, 16.4.0 was released on October 6 and is the most recent 16.x release it lists.
What to do in your project
1. Check the installed version
npm list next2. Record the current version before changing anything
Create a branch and note the version running in production. If something breaks, rolling back is one command.
git checkout -b nextjs-security-update3. Update to the patch version for your line
The patched versions for the October 14 notice aren't confirmed yet. When the official notice is out, use the version it lists. Until then, these are the general commands:
# 16 line (active LTS)
npm install next@latest eslint-config-next@latest
# 15.5 line (maintenance until 10/21)
npm install next@^15.5 eslint-config-next@^15.5Keep eslint-config-next on the same version as next. If you deploy on Netlify, also update the @netlify/plugin-nextjs adapter. Netlify recommends version 5.16.1 or later.
4. Update the lockfile and build
rm -rf .next
npm install
npm run buildDon't delete package-lock.json. It makes sure everyone on the team, and your deploy pipeline, installs the same versions. npm install updates the lock with the new versions. Changing only package.json isn't enough: the lock has to be committed too.
5. Test before shipping to production
In staging, go through the most exposed areas:
- Routes using
next/imageand the/api/ogroute, if you use them; - Server Actions and Server Functions;
- Middleware and routes behind authentication;
- Sensitive flows such as login and checkout, if you have them.
6. Deploy and confirm the version in production
After deploying, confirm that the new build is the one actually serving traffic. A deploy that didn't publish, or a stale cache, can leave a vulnerable version live even though the code is updated.
Update this post when the notice is out
This post was written before the full October 14 notice was published. Once the patched versions and identifiers are confirmed on the official Next.js site, the version details will be updated.