Greetings reader!

If you are reading this - it is likely because you have been scouring the web for details about the emerging Next.Js vulnerability that has everyone wondering... am I affected? Unless you are a glutton for the detailed technical write-ups... it is probably unclear. Ideally by the end of this read, readers of varying technical levels will be at least a bit more informed, and more importantly, they understand what they can do moving forward.

To get started - let me introduce myself. My name is Nick Aures and I am a Senior Penetration Tester here at Sprocket Security. I have been a Penetration Tester for around 7 years and spent almost 8 years in varying Information Technology roles ranging from Help Desk to Network Administrator. When joining Sprocket Security at the end of 2024, it was clear that I would have 1 major goal here... to take the methods I had been using for traditional Time Box Penetration Testing, and to find ways to scale them across a fleet of existing clients. It is worth noting that this is where our Attack Surface Management (ASM) platform provides great benefit to our clients and to our in-house Penetration Testers, like myself, who provide a Continuous Penetration Testing service! We (the testers) can quickly scoop assets out of ASM whom we know are likely to have this type of vulnerability or are at a minimum are good assets to target based on several signatures we look for in the ASM data.

WTB? (Why the Blog?)

Certain vulnerabilities tend to every so often make a little more noise in the cyber-media landscape than others. Moving into this final full week of March 2025, CVE-2025-29927 certainly has fallen into that category. The shortest possible explanation we can come up with here is:

- Affects Self-Hosted Next.js applications which are insecurely using Middleware

- The details and root cause are fairly technical; however the actual attack is NOT

- The general concept for the vulnerability is a "Middleware bypass"

- The outcome, if vulnerable, depends specifically on what the Middleware that has been bypassed is responsible for doing. In worst case scenarios so far, this appears to be bypassing Authentication checks.

In the presence of several pre-existing technical write-ups on the root cause of CVE-2025-29927, Sprocket Security can provide a different perspective. The "boots on the ground" perspective that is. Shortly after joining Sprocket Security as a client, clients will reach a the "Vulnerability Hunting" phase of their engagement. During this phase, our expert testers use all the tricks up their sleeves to help hack and remediate for our clients. However, given the Continuous nature of Sprocket Security's Penetration Tests, our testers also can take bleeding edge vulnerability details and attempt to apply them against the large and growing fleet of client assets that Sprocket Security helps protect. Rather than waiting several months for enough penetration tests to occur where statistically, maybe we find a vulnerable host, we can immediately look for this vulnerability across all in scope assets for all our clients! While we do not claim to have enough assets in our ASM platform to accurately represent the internet at-large, we do have thousands and thousands of assets to look at. This greatly reduces the time it takes for us as security professionals to get a better real-world understanding of a given vulnerability and/or its' corresponding exploit(s) when they emerge.

Vulnerability Hunter Exploit Notes

It has just been a couple of days since our testers have really been able to give this Next.js vulnerability a once-over to see how it applies to our client base from a Blackbox (blind) perspective. These are our initial discoveries and thoughts, broken into two sections:

1) Detection - Seemingly straight-forward

2) Exploitation - Not as simple

Detection

We built our detection phase out based on an excellent write-up on this vulnerability: Doing the Due Diligence: Analyzing the Next.Js Middleware Bypass (CVE-2025-29927)

We chose Assetnotes' detection technique - as their write-up explicitly mentions building a more reliable detection (check) - taking care to reduce the number of false positives and reduce/eliminate the chance for missed vulnerable hosts.

"The logic for the checks we have seen in the wild rely on the presence of x-middleware-rewrite, x-middleware-next, x-middleware-redirect inside the response headers. From our testing with various Next.js versions up to 14.2.24, the x-middleware-rewrite does not exist on a redirect, and x-middleware-next and x-middleware-redirect headers are not present on a redirect from the middleware layer...In addition to the lack of coverage in public checks for this issue covered above, there is also a great risk of false positives caused by the common development paradigm in Next.js applications to perform redirects in the middleware layer for locale-based versions of the pages being requested. By filtering these candidates out of the picture, we were able to squash a majority of false positives from being flagged.“

The Assetnote write-up goes on to mention that their team discovered they could use the x-nextjs-data: 1 HTTP request header to coerce a response from Next.js application that would leak the x-nextjs-redirect internal header. This is ultimately the detection technique... send in a x-nextjs-data: 1 HTTP request header and watch for the following:

IF HTTP response = 307 AND x-nextjs-redirect, x-middleware-rewrite or x-nextjs-rewrite HTTP response headers have a non-empty value - proceed to attempt exploitation.

Keep in mind that spraying this detection at a list of hosts is assuming the redirection we are looking for will occur from a request to the root of the web application /. In theory, if the Next.js application is hosted from a subdirectory for example, we could potentially increase our detection capabilities as well. Perhaps the root directory of a web server isn’t where the logic is hosted to trigger the behavior we are searching for. Easy enough for the most part so far, right?!

Exploitation

This is where things get interesting. It is easy enough to inject a header and then to monitor for an HTTP 307 response with specific non-null headers also in the response. But once we suspect we have a vulnerable host, what do we do? This seems to be where the technical write-ups don't elaborate as much. There are really two things we must consider at this stage based on our observations. The first is which payload to use with the x-middleware-subrequest HTTP header.

Initially in this write-up, Next.js and the corrupt middleware: the authorizing artifact, the researcher suggests using one of the following in relation to bypassing Middleware to gain access to the example route /dashboard/panel/admin:

pages/_middleware
pages/_middleware
pages/dashboard/_middleware
pages/dashboard/panel/_middleware
middleware
src/middleware
middleware:middleware:middleware:middleware:middleware
src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

The Assetnote write-up already mentioned builds on this by providing the following polyglot payload that is intended to reduce the number of requests sent to a target:

src/middleware:nowaf:src/middleware:src/middleware:src/middleware:src/middleware:middleware:middleware:nowaf:middleware:middleware:middleware:pages/_middleware


For the sake of being thorough and providing ourselves the best chance of finding vulnerable hosts in the ASM data, we compile all the above as potential exploitation payloads.

# Payload variants intended to cover different Next.js versions and layouts + Assetnote polyglot

payloads=(

"middleware"

"middleware:middleware:middleware:middleware:middleware"

"src/middleware"

"src/middleware:src/middleware:src/middleware:src/middleware:src/middleware"

"pages/_middleware"

"pages/dashboard/_middleware"

"pages/dashboard/panel/_middleware"

"src/middleware:nowaf:src/middleware:src/middleware:src/middleware:src/middleware:middleware:middleware:nowaf:middleware:middleware:middleware:pages/_middleware"

)


This of course, is a list of payloads that will essentially tell vulnerable Next.js applications to skip the Middleware checks and move on. What is still missing to put this all into a working exploit is to have a working route to attempt a bypass against (specifically in the use case of Middleware Authentication Check Bypasses). What might a protected endpoint be? Well, that is the less obvious part of this attack. But to give ourselves something to scan with to start, we decided on two routes that sounded like the could be potentially protected and common enough:

DEFAULT_ENDPOINTS=("/admin/login" "/dashboard/team/admin")

In just a short few minutes, we were successful in finding a live instance of this bypass technique "in the wild" using the approach we describe above - created based on the research by Rachid Allam and Assetnote. The working payload in the case of the first hit was:

x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

Indicating the application was running a more recent release of Next.js. More importantly, the response from the web application prior to adding the payload to the HTTP request was a 307 however with the bypass payload it was a 200!

To give credit to the Assetnote PolyGlot that just happened to be further down the list of payloads:

x-middleware-subrequest: src/middleware:nowaf:src/middleware:src/middleware:src/middleware:src/middleware:middleware:middleware:nowaf:middleware:middleware:middleware:pages/_middleware

...also was successful! 

[***] DIFFERENCE on [http://{REDACTED}.net/dashboard/team/admin](http://{REDACTED}.net/dashboard/team/admin) with payload: src/middleware:nowaf:src/middleware:src/middleware:src/middleware:src/middleware:middleware:middleware:nowaf:middleware:middleware:middleware:pages/_middleware (Baseline: 307, Exploit: 200)

Given the polyglot payload has proved effective and is simple to provide in an otherwise dynamic HTTP request, we are now at a point where scaling the bypass on a suspected vulnerable host is as easy as putting together a multi-pronged forced browsing (directory brute force) job. Pick your favorite dirb'ing tool (Feroxbuster has been my personal favorite in most cases for a while now), if it supports custom headers - or accomplish the same concept in BurpSuites' Intruder.

In the case below, note the lefthand side - we will just call the "regular request" side, and the right side is where the bypass header with the polyglot payload is added. In the case of this host, it was a Vercel hosted application - so it was prepared for the attack ahead of time (as per the Next.js disclosure). However, the notable difference in responses from "regular requests" and "exploit payload requests" shows the idea of a multi-pronged forced browsing attack and how it could help identify additional protected endpoint bypass candidates.

Takeaways

Once vulnerable hosts are identified using the techniques described above, using a combination of active recon, passive recon and fingerprinting can likely help you find protected endpoints. Once you have a protected endpoint to target and know the instance is vulnerable - it’s only a matter of a simple, slightly modified HTTP request to bypass the Middleware.

Security Engineers: There is seemingly no legitimate reason for HTTP requests containing the x-middleware-subrequest: header to come from the general public. If you are tasked with managing the web applications security infrastructure - look for places where you can inspect and drop incoming HTTP traffic based on specific HTTP headers. If you see the offending header in a request - it is safe to say it's probably an attempt to exploit this vulnerability - and it can be safely dropped.

SOC Defenders: Ensure the web servers you are tasked with monitoring have appropriate logging enabled. We have seen far too many web servers set up to only monitor default levels of information which often will miss things like HTTP POST body parameters and uncommon/custom HTTP headers. Monitor HTTP logs (ideally with SIEM or centralized logging and alarming) - and ensure IP addresses spraying the x-middleware-subrequest: HTTP header are considered hostile.

Pentesters: Let’s be honest - there is probably more to look at here still. Not all vulnerabilities are created equal, and some have more room for creativity than others. We simply wanted to contribute our initial thoughts to the community. Keep poking at these systems and see what falls out!

Developers: Keep in mind what you are doing with Middleware. Sometimes - when a vulnerability like this gets high levels of attention it opens the floodgates for research in the surrounding areas. We might see a lot more attention go to abuse of Middleware flaws in coming months!

Web Admins: Patch! The defense is simple in blocking suspicious incoming HTTP requests... however "defense in layers" is the way to go. Patching is the appropriate solution.

Conclusion

As a fun reminder - Sprocket Security conducts Penetration Tests at scale and continuously by implementing a hybrid automated/manual testing methodology and leveraging a comprehensive Attack Surface Management platform. This helps ensure our clients are in the best possible position by allowing our expert in-house testers to act quickly on emerging threats to determine which matter, specifically to your organization. Want to chat? Give us a ring!