CVE-2025-66478 on nextjs 14.*

[mattkauffman23]

Summary

One of my apps is running version 14.2 which isn't listed as being vulnerable. Overnight we started receiving requests that I believe are attempts at this exploit. (Not sharing payload but they look like RCE attempts). I don't believe they're successful but the errors they're triggering are restarting our servers. Any recommendations on hardening older nextjs versions?

Cannot read properties of null (reading 'digest')
mechanism
onunhandledrejection
handled
false
/app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js at line 13:19722
node:async_hooks in AsyncLocalStorage.run at line 338:14
/app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js in e_ at line 12:141421
/app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js at line 12:138763
node:internal/process/task_queues in process.processTicksAndRejections at line 95:5

Additional information

No response

Example

No response

[ibrahimpelumi6142]

It looks like you’re getting hit by the same RCE payload scans that are going around right now, even though 14.2 is not in the officially affected range.

The Next.js security advisory says the RSC exploit affects:

• Next 15.x
• Next 16.x
• 14.3 canary builds

So 14.2 shouldn’t be vulnerable to the exploit itself.
But scanners don’t care about the version — they just spray payloads at every public endpoint, and that can still trigger weird runtime errors if your app hits an unexpected code path.

The "Cannot read properties of null (reading 'digest')" error usually means the request crashed somewhere in the RSC or auth/crypto pipeline because the incoming payload is malformed. If your process manager restarts on unhandled rejections, it will look like the “attacks are restarting the server.”

A few things you can do:

1. Update within the 14.x line

   Stay on 14.2, but make sure you’re on the latest patch. You get fixes without jumping into 15/16.

2. Put a WAF or rules in front
   Cloudflare / AWS / Vercel Edge Rules can block obviously malicious payloads before they reach Node. This makes a huge difference during exploit waves.

3. Add limits + defensive checks

   Rate-limit anonymous POSTs and enforce body size limits so large payloads don’t reach RSC internals.

4. Stop unhandled promise rejections from crashing the app

   Even adding a simple handler to log instead of crash can stabilize things while you investigate.

process.on('unhandledRejection', (err) => {
  console.error('Unhandled rejection:', err);
});

6. Monitor the specific endpoint being hit

   If you can log the route, you can sometimes isolate the part of your app that throws when it receives unexpected input.

So in short: your version is not actually vulnerable, but the exploit traffic can still cause crashes if bad inputs hit brittle parts of the runtime. Hardening the edge and tightening error handling usually stops the restarts.

[ibrahimpelumi6142]

Let me know if this helps or if you’re still seeing issues.
If it solves the problem, feel free to mark it as the accepted answer so others can find it. 🙌

[FSSRepo]

On my VPS server I have my Next.js 15.3 apps, and yesterday I noticed that someone from Ukraine was mining cryptocurrencies and also managed to access my SSH.

[ibrahimpelumi6142]

If someone was able to run a crypto miner and accessed SSH, the server is fully compromised. Best fix is to rebuild the server, rotate all keys, disable password login, and harden SSH/firewall. Cleaning the existing machine isn’t safe.

[mattkauffman23]

Hey @ibrahimpelumi6142 . I put in your suggestion to do:

process.on('unhandledRejection', (err) => {
  console.error('Unhandled rejection:', err);
});

Deployed recently but no restarts since I got it in. Provisionally looking good so far. Thanks for your help!

[ibrahimpelumi6142]

Glad it helped! If anything changes or you still see unusual behavior, feel free to update the thread.

[mattkauffman23]

Hmm unfortunately got a restart. I see the log above but a few ms later I also see:

This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:

I did have to guard the handler above to not run in edge for my middleware since process.env is not available there, but I don't think that the problem happened in middleware because I did get the log for "'Unhandled rejection:'".

[ibrahimpelumi6142]

It looks like this is a different async error than the one caught by the unhandledRejection handler. When you see that specific message, it usually means another promise somewhere in the app rejected without a try/catch or .catch() and that can still trigger a restart even if the previous issue was handled.

Also worth noting: anything running in the Edge runtime won’t use process.on(...), so async errors in middleware or edge routes need their own try/catch blocks. Adding an uncaughtException handler on the Node side can help surface the exact stack trace:

process.on('uncaughtException', (err) => {
  console.error('Uncaught exception:', err);
});

This won’t fix the underlying bug by itself, but it will reveal the exact source of the unhandled rejection so you can patch it properly.

[pingdum]

I also suddenly encountered the following error:

Error: Unexpected end of form at e.exports._final (/app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:2:457) at callFinal (node:internal/streams/writable:698:12) at prefinish (node:internal/streams/writable:710:7)

Error: Failed to find Server Action "x". This request might be from an older or newer deployment. Original error: Cannot read properties of undefined (reading 'workers')
    at rT (/app/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:16:1766)

It also reports an error in app-page.runtime.prod.js. Could this be the same issue as the one mentioned above?
This problem only started appearing in the last day or two.