Explore all React2Shell and framework vulnerability guides →
A rewrite rule can look like routing configuration while deciding which external service your server contacts. Next.js published GHSA-p9j2-gv94-2wf4 on July 21, 2026 concerning destination hostnames derived from request-controlled values. Reviewing this issue requires looking at how a destination is constructed, not merely whether the application has rewrite rules.
SSRF and open redirect are distinct outcomes
The advisory describes arbitrary-host routing when a dynamic value enters an external destination hostname, despite a configured hostname suffix. In rewrites, server-side proxying creates an SSRF risk; similarly constructed redirects create an open redirect risk. The affected ranges are Next.js 12.0.0 through versions before 15.5.21, and 16.0.0 through versions before 16.2.11. Fixed releases listed are 15.5.21 and 16.2.11.
Audit destinations, not just route names
Collect the rewrite and redirect configuration used by the deployed build. For every external destination, identify which parts are constant and which parts vary with a request. Trace variables back to their source, including captured route values and query-derived configuration. A familiar service name in the middle of a string is not enough to establish that the resulting destination is constrained.
- Record whether the browser is redirected or the application server makes the outbound request. These behaviors need different validation evidence.
- Identify tenant and regional routing rules whose destination is assembled dynamically.
- Ask the owner to describe the intended destination set in plain language, such as three named service hosts.
- Compare that intended set with the implementation. Review whether a server-controlled mapping can express the business requirement without accepting arbitrary hostname components.
Reduce ambiguity in multi-tenant routing
A tenant identifier should represent an application concept with a defined set of valid values. Treat its conversion into an upstream address as an explicit decision. Keep the mapping close to the code that owns the routing behavior and document how new destinations are approved. This makes reviews easier than requiring each reviewer to reason about a long string assembled in several places.
Also review which credentials accompany outbound requests and whether the upstream service needs them. Avoid distributing broad service credentials through shared routing helpers simply for convenience. These design questions are useful beyond this advisory, but they do not replace installing the vendor's patch.
Verify the patch with controlled destinations
Upgrade to a supported release containing applicable security fixes and rebuild the deployed configuration. Use an environment and destination you control to validate normal routing behavior. Confirm that each supported tenant or region still reaches its intended service and that invalid identifiers fail in a controlled way. Do not use unrelated third-party systems or internal infrastructure as experimental targets.
Save the resolved package version, deployment identifier and reviewed routing rules with the ticket. If a rule was removed or redesigned, record the replacement behavior so a later developer does not reintroduce the original pattern to restore a missing feature. Keep scan evidence separate from configuration evidence, with a clear statement of what each establishes.
Run MyPentest against an authorized website for its supported security checks. Specific detection of GHSA-p9j2-gv94-2wf4 is not confirmed here. Establish this advisory's applicability from the official version ranges and your destination-construction review; a clean general scan does not prove SSRF absent.