Next.js Security Vulnerabilities: What to Do

If you are running Next.js in production, security updates should be treated as part of your normal maintenance routine. In July 2026, Next.js published a security release covering multiple High and Medium severity issues, including an SSRF vulnerability in Server Actions. Then, in August, another security release fixed two Critical vulnerabilities, including unauthenticated remote code execution in the Image Optimization API and an RCE affecting Windows-hosted servers.

That does not mean every Next.js application is vulnerable to every issue. The actual impact depends on your Next.js version, router, deployment environment, configuration, and the features your application uses.

And there is another important point: there is currently no solid evidence that the recent increase in reported Next.js vulnerabilities was caused by AI-assisted development. AI and "vibe coding" can make it easier to produce code quickly, but the security advisories themselves do not establish AI as the cause. The safer approach is to assume that fast development increases the need for automated dependency and security checks.

---

What happened with the Next.js SSRF vulnerability?​

One of the July 2026 vulnerabilities was CVE-2026-64649, a High severity Server-Side Request Forgery issue affecting certain Next.js applications using Server Actions.

The vulnerable versions included:

• 14.1.1 through versions before 15.5.21
• 16.0.0 through versions before 16.2.11

The vulnerability applies when Server Actions forward or redirect requests and an attacker can influence Host-related headers. Under the affected deployment conditions, the server can be made to send an outbound request to an attacker-controlled host.

The important detail is that this is not simply "SSRF gives the attacker JavaScript execution."

The advisory describes an SSRF condition. It does not say that exploiting this CVE automatically gives an attacker arbitrary code execution, access to all secrets, or the ability to inject JavaScript into every affected application. Those outcomes would require additional vulnerabilities, insecure configuration, or another successful attack path.

---

SSRF vs. Injection: What is the difference?​

They are different classes of vulnerabilities.
SSRF (Server-Side Request Forgery) happens when an attacker can influence a server into making a network request that the attacker should not be able to make directly.
For example, a vulnerable application might be tricked into requesting an attacker-controlled URL or an internal service.
Injection is a broader category in which attacker-controlled data is interpreted as part of another language, command, query, or instruction.

Examples include:

• SQL injection
• Command injection
• JavaScript injection
• Template injection

So, SSRF and injection are not the same thing.

An SSRF vulnerability can sometimes become much more serious when it is combined with another weakness. For example, an attacker may use SSRF to reach an internal service that contains another vulnerability. But that additional step should not be assumed unless there is evidence that the specific application is vulnerable.

---

Why can SSRF be difficult to notice?​

SSRF happens on the server side.
A normal security review may focus heavily on:

• Source-code changes
• Browser JavaScript
• Authentication
• Cloud configuration
• Firewall rules
• CDN configuration
• Dependency alerts

But a vulnerability can still exist in the way the application processes an incoming request at runtime.
This is especially important for applications using custom servers, reverse proxies, or complicated hosting architectures.
For CVE-2026-64649, the vulnerable configuration involved applications where the incoming Host-related information was not properly fixed to a trusted value. The official advisory specifically notes that managed hosting environments that pin the host upstream are not affected in the same way, while custom-server deployments can be affected.

---

What about ClickFix attacks?​

ClickFix is a separate attack technique and should not be confused with the Next.js SSRF vulnerability.
In a ClickFix-style attack, a malicious website or compromised page can display fake verification instructions and convince the victim to copy and execute a command.

The important security lesson is simple:
Never ask users to paste commands into a terminal just because a website tells them to.
A compromised website can potentially display arbitrary client-side content, so a fake "Verify you are human" prompt is not proof that the command is safe.
An SSRF vulnerability in Next.js does not automatically turn a website into a ClickFix attack. These are different attack mechanisms, although a compromised application could potentially be used as a delivery platform for malicious content.

---

Do you still need to upgrade to Next.js 16.2.11?​

If you are still running a version affected by the July 2026 vulnerabilities, 16.2.11 was the patched version for the 16.2 branch. The July release also provided 15.5.21 for the 15.5 maintenance branch.
However, there is an important update if you are reading this now.

Next.js released another security update on August 25, 2026. The current patched versions for those August issues are:

• 16.3.3
• 15.5.24

The August release addressed two Critical vulnerabilities. One involves unauthenticated RCE through AVIF image optimization, while the other can lead to unauthenticated RCE on affected Windows-hosted servers.
So, do not stop at 16.2.11 if a newer supported security release applies to your project.
Check the current Next.js security advisories and choose the patched version appropriate for your supported release line and deployment environment.

---

What should you do if your application is already running Next.js?​

Start with the simplest and most important step: identify your exact version.
Then upgrade to a currently supported patched release rather than applying an old security fix and stopping there.
For example, if your project is using the 16.3 release line, the August 2026 security release requires at least:

npm install next@16.3.3

After upgrading, rebuild and redeploy the application.
Do not blindly run a major-version upgrade in production without testing it first. Review the release notes and test your application in a staging environment when the version jump is significant.

---

Run npm audit​

Next, check the rest of your dependency tree.

npm audit

You can also ask npm to apply compatible fixes automatically:

npm audit fix

Keep in mind that npm audit fix cannot automatically resolve every vulnerability. Some issues require a package upgrade, a configuration change, or manual investigation. npm also recommends regularly running audits or integrating them into CI.

For a production application, review the audit output instead of blindly using:

npm audit fix --force

The --force option can introduce major-version changes, so it should be treated as a deliberate dependency upgrade rather than a routine security command.

---

Configure Server Actions correctly​

If your architecture uses Server Actions behind a reverse proxy or another frontend domain, review serverActions.allowedOrigins.
Next.js uses origin and host checks for Server Actions, and the documentation provides allowedOrigins for applications where legitimate requests come through additional trusted origins.

For example:

const nextConfig = {
experimental: {
serverActions: {
allowedOrigins: ['app.example.com'],
},
},
};

module.exports = nextConfig;

Only add origins that you actually trust.
Do not use allowedOrigins as a substitute for authentication and authorization. Next.js recommends treating Server Actions like public-facing API endpoints and checking whether the current user is actually allowed to perform the requested operation.

---

Validate Host headers at the edge​

For the July SSRF issue, the important mitigation is not a client-side domain whitelist.
If your deployment architecture allows clients to influence the Host or X-Forwarded-Host headers reaching your Next.js server, validate or pin those headers at the trusted edge or proxy.
The official advisory also documents __NEXT_PRIVATE_ORIGIN as an additional workaround for applicable versions, using the application's real origin.

For example:

__NEXT_PRIVATE_ORIGIN=[URL]https://www.example.com[/URL]

Use this only when it matches your actual deployment architecture and the documented workaround applies to your version.

---

Use Dependabot instead of relying on memory​

If your project is hosted on GitHub, enable Dependabot security updates.
Dependabot can detect vulnerable dependencies and create pull requests with security updates, which is much safer than relying on someone remembering to check every package manually.
This becomes even more useful for AI-assisted development.
If you are using an AI coding assistant to create features quickly, your security process should become more automated, not less.

A practical workflow is:

1. Developer or AI creates a change.
2. Tests run automatically.
3. Dependency scanning runs.
4. Security scanners inspect the change.
5. The pull request is reviewed.
6. The application is deployed only after the checks pass.

Tools such as OSV-Scanner, Trivy, and GitHub's security features can be incorporated into CI depending on your stack.

---

Why are there so many Next.js vulnerabilities lately?​

There are several possible reasons, and it is important not to assume one explanation without evidence.
Next.js is a large and widely used framework with a substantial attack surface. It contains server-side rendering, Server Actions, routing, middleware/proxy behavior, image processing, caching, request handling, and integrations with other components.

Security research also changes over time. When researchers investigate a popular framework more deeply, they may discover multiple issues within related areas.

Next.js also announced in July 2026 that it was moving toward a more formal and more regular security-release process. The July release contained four High and five Medium severity vulnerabilities, while the following August release addressed two Critical vulnerabilities.

That does not by itself prove that the framework suddenly became less secure. It does show that security maintenance is an active part of the project's current development cycle.

As for AI: AI-assisted coding may increase the amount of code being produced and can introduce insecure patterns when generated code is not reviewed. But there is not enough evidence in the Next.js advisories to conclude that AI is the reason these vulnerabilities were discovered or increased.

---

Don't rely on Cloudflare or a clean Git history​

A clean Git history does not prove that a production application is secure.
Neither does:

• A clean Cloudflare dashboard
• No visible security alert
• A clean pull request
• Passing unit tests
• Passing a basic dependency scan

Security problems can exist in runtime behavior, dependencies, deployment configuration, request handling, or third-party components.
The August 2026 AVIF vulnerability is a good example of why dependency chains matter: the Next.js advisory identifies a vulnerability in the underlying libheif library used through sharp for image optimization.
Your application does not have to contain malicious code for a vulnerable dependency to become a security problem.

---

Add security checks to your CI pipeline​

A basic CI pipeline can check dependencies before deployment.
For example:

npm ci
npm audit --audit-level=high
npm test
npm run build

The exact commands should match your project.
The important idea is to make security checks part of the development workflow instead of waiting until someone sees a new CVE on social media.

You can also combine dependency scanning with tools such as:

• GitHub Dependabot
• OSV-Scanner
• Trivy
• Other SCA and container-scanning tools appropriate for your stack

The goal is not to install every security tool available. The goal is to make important security failures visible before they reach production.

---

Keep observability in place​

Security is not only about preventing an attack.
You also need to know what happened if something goes wrong.

Make sure you have centralized logs and useful observability for:

• HTTP requests
• Authentication events
• Failed authorization attempts
• Unexpected Server Action requests
• Application errors
• Deployment events
• Dependency and security alerts
• Unusual outbound requests

This makes incident investigation much easier.
A platform such as HeronSignal can also be used for centralized monitoring and observability if it fits your infrastructure.

---

A practical Next.js security checklist​

If you are running Next.js in production, check these items now:

• Check your exact Next.js version.
• Upgrade to a currently supported patched release.
• Review the Next.js security advisories for your version and deployment model.
• Run npm audit.
• Update vulnerable dependencies.
• Enable Dependabot security updates if you use GitHub.
• Review Server Actions and authenticate users inside the action.
• Review serverActions.allowedOrigins if you use reverse proxies or multiple trusted origins.
• Make sure untrusted clients cannot control Host-related headers reaching your application.
• Review next/image and remote image configuration.
• Pay particular attention to Windows-hosted deployments and AVIF optimization because of the August 2026 Critical advisories.
• Add dependency and security scanning to CI.
• Keep centralized logs and observability.
• Test security updates before deploying them to production.

The biggest lesson is not "Next.js is insecure."

The practical lesson is that a modern web framework is part of your security boundary, so keeping it patched is just as important as keeping your operating system, database, containers, and dependencies patched.

And if you are using AI to build your application quickly, automate the boring security checks around that workflow. Let AI help you write code faster, but do not let speed replace dependency updates, testing, code review, and production monitoring.

---

Frequently Asked Questions​

-------------------

Is CVE-2026-64649 a Next.js RCE vulnerability?​

No. CVE-2026-64649 is a High severity SSRF vulnerability affecting certain Server Action deployments. The official advisory describes attacker-controlled Host-related headers causing the server to send outbound requests to a malicious host. It does not state that the CVE itself provides automatic arbitrary code execution.

Is Next.js 16.2.11 still the latest security version?​

No. 16.2.11 was the patched release for the July 2026 security issues in the 16.2 line. Next.js subsequently released 16.3.3 on August 25, 2026 to address two Critical vulnerabilities.

Does using Cloudflare protect my Next.js application from these vulnerabilities?​

Not automatically. A CDN or WAF can provide additional security controls, but application and framework vulnerabilities still need to be patched and correctly configured.

Should I use npm audit on every project?​

Yes. It is a useful baseline for identifying known dependency vulnerabilities. For production projects, running it regularly and integrating appropriate security checks into CI can reduce the chance of missing a known vulnerable dependency.

Can AI coding tools cause security vulnerabilities?​

AI-generated code can contain insecure patterns, just like human-written code can. However, the available Next.js security advisories do not establish AI as the cause of the recent Next.js vulnerabilities. Treat AI-generated code as code that still needs normal testing, review, dependency scanning, and security validation.