CVE202644578 is a high severity (CVSS 8.6) server side request forgery in the WebSocket upgrade handling of selfhosted Next.js. Affected versions from 13.4.13 up to but not including 15.5.16 and from 16.0.0 up to but not including 16.2.5. Fixed 15.5.16 and 16.2.5 (upgrade to the latest patch in your line). Vercelhosted applications are not affected. No authentication is required to exploit it.If you run Next.js on your own infrastructure, this advisory is a sameweek task, not a backlog item. This guide translates the advisory into decisions: are we affected, how urgent is it, what do we change and how do we prove it worked? It is written for engineering managers, platform teams and security leads who need a clear plan rather than a deep code walkthrough.

What the Advisory Says Happened

Selfhosted applications using the builtin Node.js server can be tricked, through specially crafted WebSocket upgrade requests, into proxying requests to arbitrary internal or external destinations. The consequence is exposure of internal services or sensitive cloud metadata endpoints. In plain terms an outsider can make your web server fetch things on the outsider's behalf, from inside your network and read the answer.Our own CVE 2026 44578 Next.js WebSocket SSRF vulnerability page covers the technical behaviour; this article focuses on the response.

CVE202644578 Affected Versions

The advisory defines affected ranges by release line.

• 13.4.13 through 15.5.15 (all versions starting at 13.4.13 and ending before 15.5.16). This includes every 14.x release and all 15.x releases before 15.5.16.

• 16.0.0 through 16.2.4 (all versions starting at 16.0.0 and ending before 16.2.5).

Versions older than 13.4.13 are not listed in the advisory as affected, but running a framework that old carries its own large set of unpatched issues, so an upgrade is warranted anyway.

Next.js Patched Versions

• 15.5.16 for the 15.x line.

• 16.2.5 for the 16.x line.

Some third party writeups mention higher numbers such as 15.5.18 and 16.2.6. Those are later releases in the same lines that roll up additional security fixes. One public project also recorded moving from 16.2.4 to 16.2.6 and noted that the newer release covers a separate middleware related followup. The practical rule is simple upgrade to the newest patch release of your current line and treat 15.5.16 and 16.2.5 as the minimum acceptable versions. If you are on 14.x, there is no 14.x fix listed in the advisory data we reviewed, so plan a move to a patched 15.x or 16.x release and verify against the official advisory.The web application hacking labs let you practise the attacker's perspective legally and the SQL injection lab shows how the same untrusted input steers a trusted component idea plays out in databases.

Are You Actually Exposed? A Triage Matrix

Not every Next.js deployment carries the same risk. Use this matrix to prioritise.

One security vendor sampled internet facing hosts and estimated that tens of thousands of directly exposed instances were vulnerable shortly after disclosure. Treat that as a rough estimate, but it reflects a real pattern: many teams expose the Node.js process on its default port without a proxy in front..For a second example of how we cover advisories, read our CVE202623918 writeup.

Why the CVSS Score Is 8.6

The score is worth understanding rather than quoting, because it influences how your organisation will rank this against other work.

• Attack vector network. Remote exploitation is possible.

• Attack complexity is low. A single crafted request is enough.

• Privileges required none. No account is needed.

• User interaction none.

• Scope changed. A flaw in the web server lets an attacker reach resources managed by a different component, such as internal services or the cloud control plane.

• Confidentiality high. Internal responses and potentially credentials can be read.

• Integrity and availability none. The forged request is readonly.

The absence of an integrity impact is why the score stops at 8.6 rather than reaching the critical band. Do not read "high, not critical" as "optional." Credentials obtained through metadata access can enable integrity and availability impacts elsewhere in your environment.

Patch Plan A Practical Sequence

Step 1 Build an inventory

List every application that depends on the framework. Search repositories, container images and deployment manifests. Do not rely on memory; forgotten internal dashboards and marketing microsites are classic blind spots.

Step 2 Classify the hosting model

For each application, record where and how it runs. The risky pattern is the builtin Node.js server accepting inbound traffic directly.

Step 3 Check installed versions

Look at the lockfile and, where possible, the running artefact. A lockfile can lag behind what is deployed and a container image can embed an older version than the repository suggests.

Step 4 Upgrade

Move to the latest patch release in your line. Run your test suite, pay attention to custom server code and any rewrite configuration and deploy through your normal pipeline. Rebuild container images from scratch so the new dependency actually lands in the image.

Step 5 Verify

Confirm the running version after deployment. Where policy allows, repeat a nondestructive check in a disposable environment you own to confirm the old behaviour is gone. Avoid testing against systems you do not control.

Step 6 Record the evidence

Capture the version, date and verification result for audit and for incident response readiness.

Temporary Mitigations If You Cannot Patch Today

Patching is the only complete fix. If an immediate upgrade is impossible, layer these controls to reduce exposure while you schedule it.

1. Put a hardened reverse proxy in front of the application. Mainstream options such as nginx, Caddy and HAProxy normally reject or rewrite absoluteform request lines for ordinary traffic. This removes the precondition the attack depends on.

2. Reject scheme prefixed request targets explicitly. Add a rule at the proxy or web application firewall that refuses requests whose target begins with http// or https//. This matches the exploit signature closely and rarely affects legitimate clients.

3. Do not block WebSocket upgrades wholesale. Doing so breaks realtime features. The vulnerability depends on the combination of an upgrade header and an absoluteform target, not on upgrades alone.

4. Restrict egress. Use firewall or security group rules so the application host cannot reach internal subnets or metadata addresses it does not need.

5. Enforce hardened metadata access. On cloud platforms that support session token based metadata access, require it. Because the flaw can only issue GET requests, this blocks the most damaging outcome.

6. Remove unnecessary role permissions. If an instance role is ever leaked, a narrow role limits the blast radius.

These steps are compensating controls, not substitutes. Each one has gaps and attackers adapt.

SelfHosted Next.js Security Deployment Patterns Compared

The advisory is easier to apply when you map it to the way your team actually deploys. The builtin Node.js server shows up in several common patterns and the exposure differs for each.

A virtual machine running the framework directly. This is the simplest setup and the riskiest when the application port is open to the internet. The Node.js process receives raw client bytes, including unusual request lines. Add a proxy, close the application port to the public and upgrade.

A container published directly to the internet. Containers do not change the logic. If the container's port is mapped to a public interface, the process inside is the first thing the attacker meets. Rebuild the image on a patched version rather than patching a running container in place, so the fix survives the next restart.

A Kubernetes workload behind an ingress controller. Most ingress controllers normalise request lines, which reduces exposure, but behaviour varies by controller and configuration. Do not assume; confirm with your platform team and still upgrade the framework.

A platform as a service deployment. Managed platforms that terminate connections at their edge and reject absoluteform targets before they reach your process are reported as protected. Ask your provider to confirm in writing how upgrade requests are handled.

An internal application. Internal does not mean safe. Any compromised workstation, malicious insider, or other internal foothold can reach it. Rank it below internetfacing systems, but do not exclude it.

Impact Scenarios Your Leadership Will Ask About

Executives rarely ask about CWE numbers; they ask "what could actually happen?" Here are the realistic scenarios, ordered from most to least severe.

Credential theft from cloud metadata. On a platform whose metadata service answers a simple GET, a vulnerable and directly exposed server can leak temporary role credentials. Those credentials may grant access to storage, databases, or other services, depending on the role.

Reconnaissance of internal services. Even without credentials, an attacker can map which internal hosts answer on port 80 and read banner pages, status endpoints and administrative interfaces that were assumed to be unreachable from outside.

Access to unauthenticated internal tools. Many organisations run internal dashboards without authentication because they are "only reachable internally." SSRF breaks that assumption.

Stepping stone for follow on attacks. Information from internal responses helps an attacker craft further steps, including attacks that require a foothold.

The mitigating factors are equally concrete: the request is readonly, the destination port is effectively limited to 80 and some cloud metadata designs are resistant. These facts reduce but do not eliminate risk and they vary per environment.

Common Mistakes When Responding to This Advisory

Teams that handled the disclosure well avoided a few recurring errors.

• Patching the repository but not the deployment. Updating the dependency file achieves nothing until a new build is deployed. Verify the running version, not the intended one.

• Trusting a reverse proxy without testing it. Different proxies and configurations treat unusual request lines differently. A rule you have never tested is a hope, not a control.

• Blocking all WebSocket traffic. This breaks legitimate features and creates pressure to roll the change back, which leaves you unprotected.

• Forgetting preview and staging environments. Attackers scan for every reachable host, not just the production domain.

• Skipping postpatch review of credentials. If an exposed, unpatched instance sat on the internet for weeks, review whether its cloud role or any secrets stored on the host could have been reached and rotate them if there is any doubt.

Communicating the Advisory Internally

A short, accurate message saves time. A template that works well

• What An unauthenticated SSRF in selfhosted Next.js, CVSS 8.6.

• Who is affected Applications on the builtin Node.js server running versions in the listed ranges.

• What we are doing: Inventorying, upgrading to the latest patch in each line and adding proxy and egress controls.

• Deadline Directly exposed instances first, then everything else.

• How we will know it is done Version evidence plus a verification note per application.

Building LongTerm Resilience Beyond This CVE

This advisory will not be the last of its kind. Frameworks ship security fixes constantly and May 2026 included several Next.js advisories in the same batch. A resilient programme has habits, not just reactions.

• Subscribe to the framework's security announcements and to your dependency scanning alerts.

• Pin and review upgrades on a cadence, so patching a framework is routine rather than an emergency.

• Keep reverse proxies in front of application servers as a standard pattern.

• Treat egress as a security control, not an afterthought.

• Train developers to recognise SSRF patterns, including those that arise from framework behaviour rather than application features.

For a structured set of baseline practices, see our guide to web security best practices. For a handson way to understand why seemingly small guard conditions matter, try the source code review lab, where you read vulnerable code and find the defect yourself. 

Conclusion

The CVE202644578 security advisory boils down to a clear decision rule if you selfhost Next.js on the builtin Node.js server and run a version in the affected ranges, upgrade to a patched release now, starting with instances reachable from untrusted networks. Use the interim controls (a hardened reverse proxy, scheme prefixed target rejection, restricted egress and hardened metadata access) only as a bridge. Afterwards, keep the evidence, tighten your patch cadence and invest in the skills and habits that make the next advisory a routine upgrade rather than a scramble.For a second example of how we cover advisories, read our CVE202623918 writeup and explore everything else on the AppSecMaster home page.

Frequently Asked Questions (FAQs)

Which Next.js versions are affected by CVE202644578?

Selfhosted deployments from 13.4.13 up to but not including 15.5.16 and from 16.0.0 up to but not including 16.2.5, are affected. This includes 14.x and earlier 15.x releases. Vercelhosted applications are not affected.

Which Next.js versions fix CVE202644578?

Next.js 15.5.16 and 16.2.5 contain the fix. Later patch releases in the same lines include additional security fixes, so the safest approach is to upgrade to the newest patch release in your line and confirm against the official advisory.

How severe is CVE202644578?

It is rated High with a CVSS 3.1 base score of 8.6. It is exploitable over the network without authentication or user interaction, with high confidentiality impact and a changed scope, though no integrity or availability impact.

Can I mitigate CVE202644578 without upgrading?

Partially. Place a hardened reverse proxy in front of the app, reject request targets starting with a scheme, restrict outbound traffic and enforce hardened metadata access. These reduce exposure but do not replace upgrading to a patched version.

Does CVE202644578 affect every Next.js application?

No. It affects selfhosted applications using the builtin Node.js server. Vercelhosted deployments are not affected and serverless platforms that do not expose raw upgrade handling were reported as unaffected. Check how your own application is actually deployed.