Project-CVE-2026-75604

Python-based exploitation framework for CVE-2026-75604, enabling authorized pentesters to validate Next.js Windows cache traversal vulnerabilities with reverse shell and webshell deployment, target verification, and proxy support.

According to the official Next.js security release:

• The issue affects Windows-hosted Next.js servers using the relevant Pages Router/App Router configuration without Cache Components.
• Linux and macOS deployments are not affected by this specific vulnerability.
• There is no known configuration-only workaround for affected Windows-hosted deployments; upgrading is required.
• Fixed releases include Next.js 15.5.24 and 16.3.3.

Safe Assessment

The included --check-only mode should be treated as a technology fingerprinting check, not proof that a host is vulnerable.

It may look for indicators such as:

• A X-Powered-By response header referencing Next.js
• __next content markers in the returned page
• Publicly accessible Next.js static assets

A positive result only suggests that the target may use Next.js. It does not establish:

• The installed Next.js version
• Whether the server runs Windows
• Whether the affected router/cache configuration is enabled
• Whether the server is vulnerable
• Authorization to perform any further testing

For production environments, validate exposure through asset inventory, deployment configuration, package-lock files, SBOMs, or an approved vulnerability-scanning process—not by attempting payload delivery.

Remediation

1. Upgrade Next.js immediately

For Next.js 15.5 deployments:

For Next.js 16.3 deployments:

After upgrading, rebuild and redeploy the application using your normal CI/CD process.

2. Confirm the deployed version

Check the version tracked by your dependency manifest:

Also confirm that the deployed artifact/container uses the updated dependency rather than relying only on a local development environment.

3. Prioritize Windows-hosted deployments

Immediately identify self-hosted Next.js applications running on:

• Windows Server
• Windows virtual machines
• Windows containers
• On-premises IIS/Node.js hosting environments using Windows filesystems

Treat exposed, internet-facing systems as highest priority.

4. Apply temporary exposure reduction

Until patching and redeployment are complete:

• Restrict public access to affected services where operationally possible
• Place the application behind a WAF or reverse proxy
• Limit inbound access to approved IP ranges or VPN users
• Use least-privileged service accounts for Node.js processes
• Ensure the application process cannot write to deployment directories or execute arbitrary child processes
• Maintain tested backups and an incident-response plan

These are temporary risk-reduction measures, not substitutes for upgrading.

Detection and Response

Investigate for possible exploitation if an affected Windows-hosted service was internet-accessible before patching.

Review:

• Web-server, reverse-proxy, CDN, and WAF logs for abnormal encoded traversal patterns
• Requests containing suspicious backslash, dot-segment, or double-encoded path sequences
• Unexpected requests to cache-related or internal application paths
• Newly created or changed .js, .cmd, .bat, .ps1, .exe, or .dll files
• Unexpected child processes spawned by node.exe
• Outbound network connections from the Next.js host, especially to unfamiliar IP addresses or high-numbered ports
• New scheduled tasks, services, startup entries, local users, or modified application files

If compromise is suspected:

1. Isolate the host from the network.
2. Preserve logs and volatile evidence.
3. Rotate secrets that may have been accessible to the application.
4. Rebuild the server from a trusted image rather than trusting in-place cleanup.
5. Patch Next.js before returning the service to production.
6. Review server and application access logs for the incident window.

References

• Next.js August 2026 Security Release
• CVE-2026-75604
• Vercel Open Source Bug Bounty Program

Disclaimer

This repository is provided for educational and defensive-security purposes. Do not use it to gain unauthorized access, deploy malicious code, establish shells, exfiltrate data, or disrupt services.