CVE-2024-34351: the Next.js Server Actions SSRF, who is affected and how to fix it

What CVE-2024-34351 is, in plain words

A Server Action is a function marked 'use server' that a form or a button in your Next.js app calls over HTTP. Many of them end with redirect('/dashboard') or redirect('/login'). Before 14.1.1, Next.js did not just send that redirect back to the browser. When the target started with /, the server fetched the next page itself, so it could return its content in the same response. It built the address of that fetch from the Host header of the incoming request.

The Host header is written by whoever sends the request. Change it, and your server fetches from a host the sender picked instead of from itself. That is server-side request forgery (SSRF): a stranger makes your server send requests on their behalf, from inside your network. The fix, merged in pull request 62561, makes that fetch use the internal hostname of the running server and ignore request headers.

Adam Kues and Shubham Shah of Assetnote found the flaw and published their research on 9 May 2024, the day the advisory went out. They showed that by putting a server they control in the middle and chaining a redirect, they could read the full response of an address of their choice, cloud metadata endpoints included. That is a full-read SSRF: the caller sees what your server sees.

Severity and exploitation status

GitHub, which issued the CVE as the numbering authority, scores it 7.5, high, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N: reachable over the network, no account, no user action, high impact on confidentiality. NVD's own analysis gives the same 7.5 with C:N/I:H/A:N, rating integrity high instead. The two read the flaw from opposite ends, reading data or sending forged requests, and in practice it does both. The weakness is CWE-918.

CVE-2024-34351 is not in CISA's Known Exploited Vulnerabilities catalog (the release of 6 November 2026). CISA's triage on the CVE record, dated 10 May 2024, marks exploitation as none and the attack as automatable. We found no primary source reporting a breach through it. The technique has been public with a working example since the day of disclosure, though, and FIRST's EPSS model gives it about a 5.5% chance of exploitation attempts in the next 30 days, higher than about 93% of scored CVEs (6 November 2026; the score moves daily).

Who is affected

On top of an affected version, the advisory lists three conditions, and all of them must hold:

• Next.js 13.4.0 to 14.1.0. The first fixed version is 14.1.1, released on 29 February 2024. The advisory's range covers every 13.x release from 13.4.0, including the late 13.5.x patches up to 13.5.11: no 13.x release has the fix.
• Self-hosted. next start on a VPS, a standalone Docker image, a Node server behind nginx, Caddy or a load balancer. The advisory says many hosting providers, Vercel included, route requests by the Host header, and that the Next.js team does not believe apps routed that way are affected: a request naming a foreign host never reaches your app.
• Server Actions in use. Look for 'use server' in your code. Before 14.0, which made them stable, Server Actions were experimental and only ran with experimental: { serverActions: true } in next.config.js.
• A Server Action that redirects to a relative path starting with `/`, such as redirect('/login') after a form submit. The researchers' example is exactly that: a search action that sends signed-out users to the login page.

An app generated with an AI tool between mid-2023 and early 2024 most likely started in this range. If it later moved to a VPS or a Docker host and was never upgraded, it is the exact profile this CVE hits. Our Next.js security guide covers the other flaws those apps tend to carry.

How to check your Next.js version

package.json shows a range like ^14.0.4, which says little. The installed version is what counts, and the lockfile records it. Run one of these in the project folder:

# The version actually installed
npm ls next
pnpm list next
yarn why next
npx next --version

# Or read it straight from the lockfile
grep -A1 '"node_modules/next"' package-lock.json
grep -E '^  /?next@' pnpm-lock.yaml
grep -A1 -E '^"?next@' yarn.lock

Then check whether the risky pattern exists in your code:

# Files that declare Server Actions
grep -rlE "['\"]use server['\"]" app src lib 2>/dev/null

# Redirects to a path starting with /
grep -rnE "redirect\(['\"\`]/" app src lib 2>/dev/null

How to check your live app

The version tells you the flaw is in your code. Whether a stranger can reach it depends on what sits in front of your server. Check that your server refuses requests that name a host other than yours, against your own domain only:

# Through your public domain
curl -s -o /dev/null -w "%{http_code}\n" -H "Host: not-my-domain.invalid" https://your-app.example/

# Straight to the Node port, if it might be open
curl -s -o /dev/null -w "%{http_code}\n" -H "Host: not-my-domain.invalid" http://YOUR_SERVER_IP:3000/

This test does not touch a Server Action, so it only shows whether the door is open. Keybrum proves the flaw itself, by its behaviour rather than by guessing from a version. It finds the Server Action ids in the JavaScript your app ships, calls one with a Host header that points at a unique callback address Keybrum owns, and waits. If your server fetches that address, the callback records the request, and that request is the proof. The address your server is pointed at is always Keybrum's own, never an internal one, and the attack only runs on apps whose owner proved ownership.

A miss does not clear you. The flaw needs an action that redirects, and the action Keybrum calls may not be one, so keep the version check as the ground truth.

How to fix CVE-2024-34351

1. 1

   Upgrade to a supported release, not just 14.1.1

   14.1.1 is the first fixed version, but later CVEs reach it, such as the middleware bypass CVE-2025-29927, fixed on the 14 line only in 14.2.25. The Next.js support policy keeps a major in maintenance for two years after its release; 14.0 shipped on 26 October 2023, so 14.x is past that window, and the policy now lists only 16.x and 15.x as supported. Today's patches are 16.4.5, or 15.5.29 on Next.js 15, which gets security releases until 31 January 2027.

2. 2

   If the jump is too big for today

   Install [email protected], the last 14.x release (December 2025). It contains this fix and stays on your major version. Treat it as a stopgap: Next.js says it patches versions outside its support policy only in rare circumstances, so future flaws may never be fixed there.

3. 3

   Rebuild and redeploy from the lockfile

   Commit the updated lockfile, rebuild the Docker image or the server bundle without cache, deploy, and run npm ls next in the build environment to confirm the version that actually runs.

4. 4

   Pin the Host header at your proxy

   The advisory lists no official workaround, and this does not replace the upgrade. It removes the forged header before it reaches Next.js, for this flaw and for the next one that trusts Host. If the app answers on several domains, give each one its own server block.

server {
    listen 443 ssl;
    server_name app.example.com;
    # ssl_certificate and ssl_certificate_key lines here

    # Close the connection on requests that name another host
    if ($host != app.example.com) {
        return 444;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
        # Send your own domain, never the Host header the client chose
        proxy_set_header Host app.example.com;
    }
}

What to do after upgrading

• The deployed version is 14.1.1 or later, checked in the running build, not only in package.json.
• The lockfile went through the Next.js CVE checker again, since 14.1.1 still carries later Next.js CVEs.
• The proxy pins Host and the Node port is closed to the internet, so the next Host bug lands on a closed door.
• If you ran an affected version self-hosted, your proxy and app logs were searched for requests whose Host header is not your domain, and for outbound calls from your server to hosts it never talks to.
• If those logs show hits, the secrets the server could reach were rotated: cloud keys, internal API tokens, database passwords on internal endpoints.
• Every Server Action checks the session itself. Their ids ship in your JavaScript, so treat each one as a public endpoint.

Related CVEs: Server Actions, Host headers and SSRF

• CVE-2024-34350, published the same day and also starting at 13.4.0: HTTP request smuggling on routes that use rewrites, Next.js 13.4.0 to 13.5.0, fixed in 13.5.1 (GHSA-77r5-gw3j-2mpf). Any release with the CVE-2024-34351 fix also carries this fix.
• [CVE-2026-94483](/cve/cve-2026-94483): SSRF in the image optimizer, Next.js 16.0.0 to 16.3.7, fixed in 16.3.8. The same Assetnote research shows a separate risk there: a remotePatterns entry in next.config.js that allows every hostname lets anyone make the optimizer fetch any address, internal ones included.
• [CVE-2026-27978](/cve/cve-2026-27978): the Server Actions CSRF check could be bypassed with Origin: null, Next.js 16.0.1 to 16.1.6, fixed in 16.1.7.
• [CVE-2025-55182](/cve/cve-2025-55182), React2Shell: remote code execution through React Server Components, the machinery Server Actions run on.
• [CVE-2025-29927](/cve/cve-2025-29927): skipping middleware with one header, the other Next.js flaw that hits self-hosted apps hardest.

The common thread: Server Actions and the App Router turn ordinary-looking functions into public HTTP endpoints, and every header that reaches them is chosen by the caller. The vibe coding security risks guide explains why generated apps lean on these features without the checks around them.

Timeline