Explore all React2Shell and framework vulnerability guides →
A developer using Windows and a website running on a Windows server are different facts. Next.js published GHSA-p293-qw3h-jr36 on August 25, 2026 for unauthenticated remote code execution on Windows-hosted servers. The first useful question for an application owner is where the deployed server actually runs.
What the vendor advisory says
The affected ranges are Next.js 13.4 through versions before 15.5.24, and 16.0 through versions before 16.3.3. The issue concerns Pages and App Router applications without Cache Components when the server uses a Windows filesystem. The listed patched versions are 15.5.24 and 16.3.3. The vendor reports no known workaround for affected Windows-hosted applications and recommends an immediate upgrade.
Identify the real hosting environment
Read the hosting configuration, deployment manifest or service inventory instead of inferring the operating system from a repository path. A build machine may differ from the runtime machine. A container may differ from its host. Where infrastructure is managed by another team, request the relevant runtime and filesystem details with the deployment identifier rather than asking for a general platform description.
- List production, staging, previews and customer-specific installations that operate as running servers.
- For each environment, record the owner, server runtime, filesystem context and resolved Next.js package version.
- Document the application's routing and caching configuration, then compare that evidence with the precise advisory conditions.
- Keep unknown environments in the assessment until their owners confirm the facts. Lack of infrastructure access is not evidence that an environment is unaffected.
Plan an upgrade that reaches every server
Use a supported release containing applicable fixes, taking later advisories into account. Updating the package on one developer machine will not change a long-running production process. Build a fresh artifact through the usual release pipeline and ensure each server or replica receives it. During a rolling deployment, verify that old instances have drained before marking the rollout complete.
For a Windows deployment, include ordinary path-sensitive application features in the regression review: file uploads, generated reports, static file delivery and temporary storage. Confirm that service startup and restart behavior still work under the production service account. These are operational checks for the release, not attempts to reproduce remote code execution.
Separate patch completion from incident investigation
Close the remediation ticket with installed-version evidence and the running release identifier. If suspicious activity prompted the review, maintain a separate incident record with timestamps, available logs and affected assets. A successful upgrade answers whether a new artifact was deployed; it cannot explain all activity that took place before the change.
An inventory that includes runtime details helps future advisories reach the right owners quickly. Keep those fields current when an application moves between hosting providers, container platforms or server types. Record a reason when an advisory is considered outside scope, so the conclusion can be revisited if the deployment architecture changes.
Use MyPentest to run supported security checks on your authorized website. Detection of this specific Windows-hosted Next.js advisory is not confirmed here. A public scan may not establish the server filesystem or package version, so combine scan findings with hosting evidence and the official advisory.