Server-Side Request Forgery in getsentry sentry-javascript Next.js tunneling

sentry-javascript provides Sentry SDKs for JavaScript. An unsanitized input of Next.js SDK tunnel endpoint allows sending HTTP requests to arbitrary URLs and reflecting the response back to the user. This issue only affects users who have Next.js SDK tunneling feature enabled. The problem has been fixed in version 7.77.0.

• Vendor getsentry, product sentry-javascript, specifically package sentry/nextjs: affected in >= 7.26.0, < 7.77.0.
• Only deployments with the Next.js SDK tunneling feature enabled are affected under the advisory's stated condition; deployments not using that feature are outside the described exposure condition.
• The advisory identifies patched versions as >= 7.77.0. The status of branches or variants not represented in this evidence remains unknown.

This is a Server-Side Request Forgery (SSRF, CWE-918) flaw in the Next.js SDK tunnel endpoint. When tunneling is enabled, attacker-controlled input at the tunnel endpoint is not sufficiently sanitized, causing the server to send an HTTP request to an arbitrary URL and return the received response to the user.

The confirmed high-level flow is:

1. A network request reaches a tunnel endpoint exposed by the application.
2. An attacker-controlled destination value is processed without sufficient sanitization.
3. The server-side component requests the arbitrary destination and reflects the response to the client.

The record characterizes the condition as network reachable, requiring no authenticated privileges, having low complexity, and requiring user interaction. The practical scope depends on the services reachable from the server. The available evidence does not specify the exact input parameter, endpoint path, or complete validation logic; the fixing pull request only describes stricter validation of tunnel target parameters.

The flaw is reachable over the network through the application's tunnel endpoint, but only when the Next.js SDK tunneling feature is enabled. The record states that authenticated privileges are not required and that complexity is low, while user interaction is required.

The supplied record sets public_exploit to false, meaning that it does not identify a public exploit; this is not proof that exploitation has never occurred. The available evidence does not establish the real-world exploitation status.

When exploited, the server can send a request to an attacker-selected destination instead of only to the intended service. This may extend access to internal networks, cloud metadata services, or other ports visible from the server.

Returning the destination's content to the client can also create conditions for client-side vulnerabilities such as XSS or CSRF in a trusted domain, depending on how the application and browser process the response. Confidentiality and integrity consequences may be significant if an internal destination returns sensitive data or accepts a request with side effects. The impact does not automatically include every resource in the environment and is constrained by the server's network access, privileges, and trust boundaries. The record does not identify a direct availability impact.

The flaw can change the application's effective network reach because the server may connect to destinations that an external client cannot access directly.

Possible consequences include:

• Querying or reading services on internal networks that the server can reach.
• Reading cloud metadata endpoints for AWS, Azure, or Google Cloud when the environment permits access.
• Supporting local or remote port scanning from the server's network position.
• Creating opportunities for XSS or CSRF in the trusted domain because the response is reflected to the user.

The practical impact depends on network reachability, available credentials, and the system's trust relationships. The record does not identify a direct service availability impact.

1. Upgrade sentry/nextjs to 7.77.0 or to a release explicitly identified by the vendor as patched. Check the lockfile and deployed artifact to verify that the upgraded version is actually running, rather than only changing the manifest.
2. If an upgrade cannot be completed immediately, disable tunneling by removing the tunnelRoute option from the Sentry Next.js SDK configuration in next.config.js or next.config.mjs, as specified by the vendor workaround.
3. After the change, verify that the tunneling feature is disabled and that the tunnel endpoint is no longer active through application routing or the reverse proxy.
4. Review other deployments using the same package or configuration so that one fixed instance does not leave another instance in the affected range.

1. Inventory lockfiles, manifests, and deployed artifacts to determine whether the application uses the sentry/nextjs package, then compare the resolved version with the affected branch.
2. Inspect the Next.js configuration, especially next.config.js and next.config.mjs, for the tunnelRoute option and determine whether the tunneling feature is enabled.
3. Identify the actual tunnel endpoint exposed through application routing or a reverse proxy. Do not treat the absence of a route in one configuration file as proof that the application is safe.
4. As a precautionary review, inspect application and egress logs when they record target URLs or outbound destinations for requests to the tunnel endpoint. Look for internal destinations, cloud metadata endpoints, or URLs outside the expected application flow.
5. Review responses from the tunnel endpoint to determine whether content retrieved from an outbound destination is returned to clients. This is a precautionary behavioral check, not a vendor-confirmed IOC. Do not treat the absence of log evidence as proof that the flaw is not present.