Next.js 16.3.6 Critical ImageResponse Vulnerability: What to Patch Now
If your production application runs Next.js 16.2.0 through 16.3.5, treat the September 22 security update as an immediate patching task. Next.js says those versions are affected by a critical remote-code-execution issue in the Node.js __INLINE_CODE_0__ implementation from __INLINE_CODE_1__. The current fix is Next.js 16.3.6. Next.js 15.x is not affected by this RCE, although 15.5.26 includes related hardening.
There is also a second date to put on the engineering calendar: September 30, 2026. Next.js has announced another security release containing nine vulnerability fixes, including one critical issue. Teams should patch the known RCE now, then plan a second controlled update when 16.3.7 or 15.5.27 becomes available.
Is my Next.js application affected?
Your application is in the affected range if it runs Next.js __INLINE_CODE_0__. The vulnerability is in the Node.js implementation of __INLINE_CODE_1__ in __INLINE_CODE_2__. Next.js states that the Edge __INLINE_CODE_3__ implementation is not affected.
Check the installed version rather than relying only on __INLINE_CODE_0__:
npm ls next| Application state | September 22 RCE status | Immediate action |
|---|---|---|
| Next.js 16.2.0 to 16.3.5 | Affected | Upgrade to 16.3.6 now |
| Next.js 16.3.6 | Patched for this issue | Verify deployment and monitor |
| Next.js 15.5.x | Not affected by this RCE | 15.5.26 provides related hardening |
| Edge __INLINE_CODE_0__ | Not affected | Keep dependencies current |
| Unsupported older major | Outside current LTS policy | Plan a supported-version upgrade |
Next.js currently lists 16.x as Active LTS and 15.x as Maintenance LTS. Versions 14.x and earlier are outside the normal support policy. See the Next.js support policy.
What caused the vulnerability?
The issue is tied to server-side image generation using the Node.js __INLINE_CODE_0__ implementation.
According to the September 22 Next.js advisory, improper escaping in SVG output generated by the upstream Satori dependency could, under specific conditions, combine with vulnerabilities in other upstream dependencies and lead to remote code execution.
That detail helps triage exposure, but it should not become a reason to postpone patching. The safer operational question is not only "Do we knowingly use __INLINE_CODE_0__?" but also "Is an affected Next.js version present in a deployed application?"
How should you patch Next.js 16.2 or 16.3?
Upgrade affected Next.js 16 applications to at least 16.3.6, rebuild from the patched dependency state, run focused regression tests, and deploy the new artefact.
npm install next@16.3.6For teams on the Next.js 15 Maintenance LTS line:
npm install next@15.5.261. Confirm the production version
Record the version running in production, staging, preview deployments and separately deployed rendering services. Check the lockfile used by the production build.
2. Search for image-generation paths
Search the repository for:
ImageResponse
next/og
opengraph-image
twitter-imageThese routes deserve extra regression testing. Generated Open Graph and social images can be easy to overlook because they are not ordinary UI pages.
3. Keep the security diff narrow
Install the patched Next.js version with the project's normal package manager, review the dependency diff and commit the lockfile. Avoid bundling unrelated dependency upgrades into an emergency patch unless required.
4. Test the likely failure points
At minimum, test:
- application build and startup;
- server-rendered routes;
- dynamic Open Graph and social images;
- authentication and middleware;
- API or route handlers;
- caching and revalidation behaviour;
- production error monitoring after deployment.
If generated images contain user-controlled or database-derived text, include realistic Unicode, punctuation and long-string cases.
5. Verify the deployed artefact
A patched repository does not protect an old production build. For containers, rebuild the image. For serverless deployments, confirm the new build reached production. Then verify the installed version again.
Should I remove ImageResponse instead?
Upgrading is the correct fix. Next.js fixed the issue by updating upstream dependencies in 16.3.6.
Temporarily disabling an exposed image-generation endpoint may reduce risk while an emergency deployment is prepared, but it is not a substitute for the patch.
If routine framework patches are unusually risky because a project lacks reproducible builds or regression tests, that is a maintainability problem worth fixing. Softotic's web app development service and custom software development service cover production hardening as well as feature work.
Why is there another Next.js security release on September 30?
Next.js has separately announced a September 30 release covering nine vulnerabilities: one critical, two high, five medium and one low.
The September 23 advance notice says versions 16.3.7 and 15.5.27 are planned alongside full advisories and upgrade instructions.
As of September 24, the detailed affected-version information for those nine issues is not public. Do not guess which features are affected.
The sensible sequence is:
- Patch 16.2.0-16.3.5 to 16.3.6 now.
- Do not leave the disclosed RCE open while waiting for September 30.
- Reserve a rapid review and deployment path for September 30.
- Read the advisories when published.
- Upgrade to the appropriate patched release.
- Re-run focused regression tests and verify the production artefact.
A practical Next.js patch checklist
- Identify every deployed Next.js application and installed version.
- Flag versions from 16.2.0 through 16.3.5.
- Search for __INLINE_CODE_0__, __INLINE_CODE_1__, __INLINE_CODE_2__ and __INLINE_CODE_3__.
- Upgrade affected Next.js 16 applications to 16.3.6.
- Review and commit the lockfile diff.
- Run build, route, image-generation and authentication tests.
- Rebuild containers or serverless artefacts.
- Verify the Next.js version in the deployed build.
- Monitor application errors after release.
- Schedule a September 30 review for 16.3.7 or 15.5.27.
What about Next.js 14 and older?
Next.js 14.x and earlier are outside the framework's current normal LTS support policy. That does not automatically mean they are affected by this specific September 22 issue. It means teams should not assume they receive the same routine security maintenance as supported release lines.
For a business-critical older application, plan the upgrade around dependency inventory, framework breaking changes, automated regression coverage, staging, caching verification and rollback capability. Custom software modernisation is usually safer as incremental upgrades than as one large rewrite.
How can teams make the next security patch easier?
Make framework version visibility and small dependency releases routine. The technical patch is often easier than discovering which applications are affected and whether an upgrade is safe.
A useful minimum process is:
- Track framework security announcements.
- Maintain an inventory of production applications and major framework versions.
- Use lockfiles and reproducible builds.
- Keep smoke tests for critical flows.
- Test generated metadata and social images, not only visible pages.
- Separate routine dependency updates from feature releases where practical.
- Verify deployed versions after security releases.
The goal is to make urgent upgrades boring: a known owner, a small diff, repeatable tests and a verifiable deployment.
FAQs
Is Next.js 16.3.5 vulnerable?
Yes. The official advisory says versions __INLINE_CODE_0__ are affected. Upgrade to 16.3.6 or later.
Is Next.js 15 vulnerable to this RCE?
No, according to the September 22 advisory. Next.js 15.x is not affected by this specific RCE, though 15.5.26 includes related hardening.
Is Edge ImageResponse affected?
No. The affected implementation is the Node.js version of __INLINE_CODE_0__.
Should I wait for Next.js 16.3.7?
Not if you run 16.2.0 through 16.3.5. Patch the disclosed RCE with 16.3.6 now, then assess the September 30 release when its advisories are published.
Need help patching a production Next.js application?
If a Next.js application is difficult to upgrade because of dependency conflicts, fragile builds or limited test coverage, contact Softotic. We can isolate the smallest safe patch path, test affected flows and help move the project back onto a maintainable release process.