In early 2025, a critical security vulnerability (CVE-2025-29927) was discovered in Next.js middleware that allowed attackers to bypass authorization controls entirely. This vulnerability affected organizations using Next.js middleware for authentication validation, exposing sensitive data and functionality to unauthorized users.

The vulnerability was particularly dangerous because middleware is often the first line of defense in web applications, handling authentication, logging, and security filtering. When this layer can be bypassed, all downstream security controls become ineffective.

Understanding the Vulnerability

At its core, the vulnerability existed in how Next.js middleware processed the x-middleware-subrequest header. This header was designed for internal use by the framework, but when included in external requests with specific values, it caused the middleware execution to be skipped entirely.

The security flaw allowed attackers to add a simple header to their HTTP requests:

                
x-middleware-subrequest: 1
                

With this header present, requests would bypass all middleware-based authorization checks, allowing access to protected routes and resources that should have required authentication.

The Demo App

Our demo app is a minimal reproduction of the middleware vulnerability that affected older versions of Next.js. It simulates how the Next.js server processes requests through middleware and highlights how certain request headers can unintentionally bypass security checks. The core of the vulnerability lies in the logic that evaluates the x-middleware-subrequest header, which was originally introduced to prevent middleware from running recursively.

The mock-nextjs-middleware.js file defines a class that mimics the middleware behavior found in vulnerable versions of Next.js. It contains two flawed checks: one that skips middleware execution if certain legacy values are found in the x-middleware-subrequest header, and another that skips based on a maximum recursion depth. If either condition is met, the middleware is not executed — meaning authorization logic is entirely bypassed.

The vulnerable-app.js file creates a simple HTTP server that protects the /admin route using this middleware. When a request hits that route, the server runs it through the middleware. If the middleware is skipped due to the vulnerability, the request is allowed to proceed directly to sensitive content without verifying any authentication headers. This behavior demonstrates how an attacker could exploit the middleware logic to access protected endpoints without credentials.

Designing Tests to Catch the Vulnerability

Automated security testing could have identified this vulnerability before it became an issue in production. Let's explore how to design effective tests using Jest and Supertest to validate middleware security.

Test Case Design Philosophy

The most effective security tests follow these principles:

• Test for what shouldn't happen - Focus on negative testing (attempts to break security) rather than just confirming intended behavior
• Target known bypass techniques - Include tests for common security bypass patterns like header manipulation
• Validate the complete request flow - Ensure that protected resources remain inaccessible without proper authentication

The Supertest/Jest Implementation

Our test file uses supertest to simulate HTTP requests against the vulnerable server and jest as the testing framework. It starts by importing the required modules — the server we want to test and the supertest library that allows us to easily perform HTTP operations in our tests.

                
const request = require("supertest");
const server = require("./vulnerable-app");
                

Within the test suite, we define a variable app that will hold our supertest instance. In the beforeAll hook, we initialize this instance with the server so we can reuse it in each test. After the tests are done, we make sure to close the server in the afterAll hook to free up resources and avoid port conflicts.

                
describe("Next.js Middleware Security Tests", () => {
  let app;
                      
  beforeAll(() => {
    app = request(server);
  });
                      
  afterAll((done) => {
    server.close(done);
  });
                

The first test verifies the middleware's basic protection mechanism. It sends a GET request to the /admin route without any authentication header. The expected behavior is for the middleware to block access and respond with a 401 Unauthorized status and a corresponding error message.

                
test("Protected endpoint should require authentication", async () => {
  const response = await app.get("/admin");
                  
  expect(response.status).toBe(401);
  expect(response.body).toHaveProperty("error", "Unauthorized");
});
                

The next part of the suite targets the core of the vulnerability. It tests whether middleware can be bypassed using crafted x-middleware-subrequest headers. These headers are known to influence the middleware's decision to execute or skip. Each payload in the bypassPayloads array represents a potential bypass vector, either by mimicking old middleware paths or by exploiting the recursion depth check. The test iterates over each payload, sends it in a request to /admin, and checks if the middleware still blocks the request. A failure here would indicate that unauthorized access was incorrectly allowed.

                
describe("Middleware bypass vulnerability tests", () => {
  const bypassPayloads = [
    "middleware",
    "pages/_middleware",
    "middleware:middleware:middleware:middleware:middleware",
    "src/middleware:src/middleware:src/middleware:src/middleware:src/middleware",
  ];
                  
  test.each(bypassPayloads)(
    "Protected endpoint should not be accessible with x-middleware-subrequest: %s",
    async (payload) => {
      const response = await app
        .get("/admin")
        .set("x-middleware-subrequest", payload);
                  
        // In a secure app, this would pass because response would be 401
        expect(response.status).toBe(401);
        expect(response.body).toHaveProperty("error", "Unauthorized");
      }
    );
  });
                

Finally, the last test checks that a properly authenticated request behaves as expected. By adding a valid Authorization header, it confirms that the middleware allows the request to proceed, and the response contains the protected admin content. This validates that legitimate users are not blocked when they provide the necessary credentials.

                
  test("Authenticated requests should be allowed", async () => {
    const response = await app
      .get("/admin")
      .set("Authorization", "Bearer valid-token");
                  
    expect(response.status).toBe(200);
    expect(response.body).toHaveProperty(
      "message",
      "Admin area - sensitive content"
    );
  });
});
                

Best Practices to Prevent Similar Vulnerabilities

Protecting your application against middleware bypass vulnerabilities requires a multi-faceted approach that combines rigorous testing with defensive programming patterns. Development teams should implement comprehensive security testing that covers both positive and negative scenarios - don't just verify that authorized users can access protected resources, but explicitly confirm that unauthorized users cannot. Testing should include header manipulation checks for all request properties that might affect security decisions, with these tests automated within your CI/CD pipeline to catch regressions with every code change.

Understanding your framework's internal security mechanisms is equally important. Take time to review how your framework processes special headers or request properties that could impact the security flow. Stay current with security advisories for all components in your tech stack, and implement additional validation layers rather than relying solely on framework-provided security controls.

A robust defense-in-depth strategy significantly reduces vulnerability risks. Layer your security controls instead of depending exclusively on middleware for authorization. Always revalidate authorization in your API handlers or controllers, even if middleware checks have already run. Follow least privilege principles by ensuring each endpoint only has access to the resources it absolutely needs to function.

Additional security measures include:

• Performing regular penetration testing to reveal subtle vulnerabilities professional testing teams can identify
• Implementing dynamic application security testing (DAST) to find issues that static analysis might miss
• Leveraging community knowledge by sharing and learning from security testing patterns in your framework's community
• Sanitizing and validating all incoming request data, including headers, parameters, and body content
• Implementing proper logging and monitoring to detect potential bypass attempts
• Conducting regular security reviews of middleware configuration and implementation
• Creating security champions within development teams to promote secure coding practices

Conclusion

The Next.js middleware vulnerability highlights a critical lesson: even well-established frameworks can contain security flaws in their core functionality. What separates resilient systems from vulnerable ones is often the quality and comprehensiveness of their testing strategies.

By implementing automated security tests that specifically validate authorization controls against bypass attempts, development teams can identify vulnerabilities before they reach production environments. The small investment in creating these tests pays enormous dividends in preventing potential data breaches and maintaining user trust.

Additional reads:

• Next.js Vulnerability Explanation