Next.js SDK Security Advisory - CVE-2023-46729
We released a critical security advisory today for Sentry’s Next.js SDK. In the SDK versions 7.26.0-7.76.0 (inclusive), when the tunnelRoute option is enabled, this vulnerability allows malicious actors to forge requests and responses from your Next.js application (this is commonly understood as Server-side Request Forgery - SSRF).
We have no evidence that this vulnerability was exploited. We have issued a fix for this vulnerability and issued a security advisory (links below).
This vulnerability does not affect any of the other Sentry SDK’s.
Versions 7.26.0 to 7.76.0 of the Sentry Next.js SDK did not properly validate a parameter being passed to a Next.js rewrite. This issue, fixed in version 7.77.0, allows for an attacker to send arbitrary requests and responses from the Next.js server, including reflecting responses back to a user.
If you are using any version between and including versions 7.26.0 and 7.76.0 of the Sentry Next.js SDK (@sentry/nextjs package), please update the Sentry Next.js SDK to version 7.77.0 or higher immediately. If upgrading the SDK is currently not possible for you, removing the
tunnelRoute option from the Sentry SDK configuration (usually located in the next.config.js or next.config.mjs files) will also fix the vulnerability.
We have reached out to common Next.js platforms that support Next.js rewrites to block traffic that could contain malicious payloads and to set up monitoring for these requests.
If you are hosting your application on Vercel, the exploit is mitigated on an infrastructure level by blocking traffic with malicious payloads. To date, we are not aware of any traffic that has been blocked that would have been a successful exploitation attempt, or that we think would have led to a discovery of this vulnerability.
- (Mon, Oct 30, 2023 at 23:50 UTC) One of our customers reported a bug they received through their bug bounty program to our official security channel email@example.com.
- (Tues, Oct 31, 2023 at 10:15 UTC) We reached out to Vercel to disclose the technical background of this issue to find a solution to eliminate the problem on the infrastructure side.
- (Tues, Oct 31, 2023 at 10:30 UTC) Version 7.77.0 of the SDK was released which included a fix to the vulnerability: https://www.npmjs.com/package/@sentry/nextjs/v/7.77.0
- (Tues, Oct 31, 2023 at 13:00 UTC) Together with Vercel, we found a way to mitigate and work on a strategy to roll this out to potentially affected customers.
- (Wed, Nov 1, 2023 at 13:00 UTC) Vercel rolled out a mechanism in production that will block malicious rewrites.
- (Thurs, Nov 2, 2023 at 13:30 UTC) Completed investigation looking for evidence of abuse of the vulnerability
- (Fri, Nov 3, 2023 at 23:30 UTC) Notification of upcoming advisory sent to SDK users who appeared to have tunneling enabled.
- (Thurs, Nov 9, 2023 at 20:00 UTC) Security advisory published. Notification sent to all SDK users of advisory.
We recommend that you scan your logs for malicious requests to determine whether you were targeted using this vulnerability. Malicious requests would contain a URL query parameter with the key
o and a value that contains a slash (
/) character. You could use the following regex for querying for these requests:
Next, you can narrow down the search for attacks by looking for references to your internal services or external servers inside the
o URL query parameter (internal or external domains, IP addresses).
If you find such requests, you should consider yourself or your users targeted by this vulnerability.
Am I vulnerable?
You and your users are exposed to this vulnerability if you have the Sentry Next.js SDK (
@sentry/nextjs on npm) installed on the version range >=7.26.0, <7.77.0 and have the
tunnelRoute option set inside the SDK configuration. The location of your SDK configuration depends on your setup but is usually found inside the
How can I fix the vulnerability?
We recommend upgrading the Sentry Next.js SDK (
@sentry/nextjs dependency) to version 7.77.0 or higher. Version 7.77.0 includes a fix that will prevent this vulnerability from being exploitable.
Is there a way for users to fix or remediate the vulnerability without upgrading the SDK?
If upgrading the SDK is currently not possible for you, removing or making the
tunnelRoute option undefined in your SDK configuration will also fix this vulnerability. The location of your SDK configuration depends on your setup but is usually found inside the
An alternative mitigation strategy is to completely block incoming traffic to the vulnerable route when an
o query parameter is present that contains a slash (
/) character or
%2F which is the URL encoded version of the slash character. The vulnerable route is any route configured inside the
tunnelRoute Next.js option.
How can I check if this vulnerability was exploited?
Checking logs for requests to the vulnerable endpoint (the one configured with the “tunnelRoute” option) which has a URL query parameter with key
o with a value that does not exclusively contain numeric values. As an example, if you configured your “tunnelRoute” option to be
/monitoring, you could look for malicious requests to the
/monitoring endpoint containing a bad URL parameter with the following regular expression:
If there are any requests that match this pattern, further narrowing down the search by looking for strings in the
o URL parameter that look like references to internal services or external servers (internal or external domains, IP addresses).
Requests of this kind should be considered indication of being targeted by this vulnerability.
What can I do to protect my customers and myself?
After fixing the vulnerability by upgrading the SDK or with the measures outlined above, we strongly recommend invalidating and rotating all authentication data you have issued as they could have been targeted by an attacker.
What exactly was the vulnerability?
When using the
tunnelRoute option, the Sentry Next.js SDK created a Next.js rewrite that used an unsanitized URL parameter to create the rewrite target. The target was intended to always point ingestion domain
oXXX.ingest.sentry.io, however the unsanitized URL parameter could be used to escape this URL and point the rewrite to an arbitrary domain. The only limitation is that the rewrite target will always use the
What is the worst case scenario for this kind of vulnerability?
Additionally, if the vulnerable service runs within a private network an attacker could make requests through the vulnerable service as if they were inside the private network.
How did you try to determine whether this vulnerability was abused?
Next.js will forward all URL parameters, even when they are not defined in the rewrite. This means that we are able to scan for unsuccessful exploitation attempts that were correctly routed to
ingest.sentry.io in our request logs.
We checked all of our logs reaching back to June, 6 2023 to see if anyone tinkered with the exposed parameters. Direct successful attempts would have gone unnoticed since the requests would have gone past Sentry infrastructure.
We could not find log entries that we think would have led to successful exploitation.
We also worked with platforms like Vercel to implement infrastructure-level logging for requests that might contain a malicious pattern.
How did you determine what customers may be affected?
Since Next.js forwards all URL parameters to the rewritten URL, we were able to scan our logs for requests that contain the tunnel URL parameters. Since these tunnel URL parameters contain an organization ID, we were able aggregate the organization IDs and considered all of the correlating customers as potentially affected.
Are any other SDKs or Sentry products affected by this vulnerability?
We are only aware of the Sentry Next.js SDK to be affected by this vulnerability. We have checked our other SDKs for similar functionality and vulnerabilities but have not found them to be vulnerable.