#Fix Failed to find Server Action "x" spam (probably due to the CVE trying to be abused)

1 messages · Page 1 of 1 (latest)

dry oasis
#

So lately I updated to the latest version of nextjs.

How can I fix this spam:

Error: Failed to find Server Action "x". This request might be from an older or newer deployment.
Read more: https://nextjs.org/docs/messages/failed-to-find-server-action
    at ignore-listed frames
Error: Failed to find Server Action "x". This request might be from an older or newer deployment.
Read more: https://nextjs.org/docs/messages/failed-to-find-server-action
    at ignore-listed frames
Error: Failed to find Server Action "x". This request might be from an older or newer deployment.
Read more: https://nextjs.org/docs/messages/failed-to-find-server-action
    at ignore-listed frames
Error: Failed to find Server Action "x". This request might be from an older or newer deployment.
Read more: https://nextjs.org/docs/messages/failed-to-find-server-action
    at ignore-listed frames
Error: Failed to find Server Action "x". This request might be from an older or newer deployment.
Read more: https://nextjs.org/docs/messages/failed-to-find-server-action

Thats most likely caused by automated bots trying to abuse the CVE.

bleak dirgeBOT
#

Hi @dry oasis. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

You can’t fully “turn off” that log in Next.js today, but based on the linked issues there are a few realistic mitigations and clarifications:

  1. Understand that this log is expected with scanners / CVE probes
    Maintainers have confirmed that these Failed to find Server Action "x" errors are often caused by automated scanners attempting to exploit recent CVEs against the Server Actions endpoint. [HTTP 500 malformed; Cache poisoning QoS]
    In those cases, the 500s and errors are noisy but not indicative of your app being broken.

  2. Version‑skew / deployment‑mismatch is another legitimate cause
    The same error also appears when an old client talks to a newer (or older) deployment, or when encryption keys / build IDs don’t line up, especially on self‑hosted setups. [Client version skew]

    • For self‑hosting, you can “opt‑out” of strict version‑skew protection by reusing the same NEXT_SERVER_ACTIONS_ENCRYPTION_KEY across builds, set at build time, so action IDs remain valid between deployments. [Client skew comments]
    • Example from the issue (Docker build):
      RUN --mount=type=secret,id=NEXT_SERVER_ACTIONS_ENCRYPTION_KEY \
  NEXT_SERVER_ACTIONS_ENCRYPTION_KEY=$(cat /run/secrets/NEXT_SERVER_ACTIONS_ENCRYPTION_KEY) \
  turbo run build --filter=app
``` [[Client skew docker](<https://github.com/vercel/next.js/issues/75541>)]
#

  1. You cannot handle/short‑circuit Server Actions directly in middleware
    Some users tried to intercept these requests in middleware to avoid the error, but it’s explicitly not supported to handle Server Actions directly there. [Client skew middleware]
    So middleware is not a reliable way to suppress the log.

  2. Filtering / de‑noising logs is the practical workaround
    Since the framework itself currently always logs this error when the action ID is invalid, the practical mitigation (for bot / CVE spam) is to filter these specific messages at your logging layer (e.g., ignore lines that contain Failed to find Server Action "x"), while still investigating any legitimate occurrences that correlate with real user traffic.

  3. Keep Next.js up to date
    Several of the CVE‑related behaviors have been adjusted in recent 15.x/16.x releases. Some QoS and security‑related changes (e.g. header stripping for CVE‑2024‑46982) were only released in newer majors and not backported. [Cache poisoning QoS; Version confusion / CVE fix]

Because the issues don’t document a supported way to disable that specific error log inside Next.js itself, the combination of:

  • ensuring consistent NEXT_SERVER_ACTIONS_ENCRYPTION_KEY and build IDs (to avoid legit version‑skew errors), and
  • filtering the known error pattern at your log sink for bot/CVE spam,

is the best documented approach in the available sources.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: