BugVault

Room Description

https://dashboard.webverselabs-pro.com/events/bugvault

Briefing

You registered on BugVault three months ago. Reports triaged. Payouts pending. Researcher profile live. The admin panel sits behind a login wall and a Next.js middleware guard — no admin account, no escalation path, no obvious way in. You've been reading CVE advisories. You know what frameworks this stack uses. The question is whether this deployment ever patched the one that matters.

Initial Analysis

Now, this is a little bit silly, but I have done this exact same vulnerability challenge for Intigriti's monthly challenge bit, and I have a writeup for it already.

https://minatours-notes.gitbook.io/blog/ctfs/hackdonalds-intigriti-ctf

Either way, let's hop straight into it. We have a bug bounty platform with several active hunters and a leaderboard.

There are five active programs currently and we can open them up to see details, but this is just information, nothing to do here.

And of course, we have to check out the leaderboard.

Finding the bug

From the requests we can see that the application is basically trying to log us in all the time.

Let's check the Next.js version since we know the vulnerability is related to this framework.

To do this we can use whatweb or wappalyzer, I use wappalyzer's extension.

Off to research we go!

https://projectdiscovery.io/blog/nextjs-middleware-authorization-bypass

All versions of Next.js from 11.1.4 through 13.5.6, 14.x before 14.2.25, and 15.x before 15.2.3 are affected by this vulnerability.

We know the version this web app is on is definitely vulnerable now. So let's follow along the technical analysis.

The reason why we are seeing login attempts for any of the resources we open is the following:

A common implementation pattern is using middleware for authorization, which involves protecting certain paths based on specific conditions. For example, when a user attempts to access a protected route like /dashboard/admin, the middleware intercepts the request, checks if the user's session cookies are valid and if they have the necessary permissions. If the conditions are met, the middleware forwards the request; otherwise, it redirects the user to a login page.

Okay, we aren't sure what the protected route is that we would need to bypass the auth check for, as the login page is accessible, and this exploit won't log us in, rather just give us access to protected resources. Let's try to see if there's an /admin endpoint.

Ooh, there is! And we would have known it if we started with enumerating since we can see it in /robots.txt as well.

Exploitation

Exploiting this is pretty straightforward, we now have our protected resource, and we know what the vulnerability is. I will rip this off directly from projectdiscovery.

The vulnerability mechanism

The vulnerability in CVE-2025-29927 stems from a design flaw in how Next.js processes the x-middleware-subrequest header. This header was originally intended for internal use within the Next.js framework to prevent infinite middleware execution loops.When a Next.js application uses middleware, the runMiddleware function is called to process incoming requests. As part of its functionality, this function checks for the presence of the x-middleware-subrequest header. If this header exists and contains a specific value, the middleware execution is skipped entirely, and the request is forwarded directly to its original destination via NextResponse.next().

The vulnerability lies in the fact that this header check can be exploited by external users. By adding the x-middleware-subrequest header with the correct value to a request, an attacker can completely bypass any middleware-based protection mechanisms. Here's how the vulnerability works at the code level:javascript

This code snippet shows that if the x-middleware-subrequest header value, when split by the colon character (:), includes the middlewareInfo.name value, the middleware is bypassed entirely.

Basically, we can input any value for the X-Middleware-Subrequest header and we bypass the auth check.

We can use the extension ModHeader to do this attack, or Burp, or cURL or anything really.

Then we just try to access /admin and bypass the auth check in place since we do have the header present.