App crashes on POST requests with `Origin: null` + `Content-Type: application/x-www-form-urlencoded` headers

[a9ex]

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/github/vercel/next.js/tree/canary/examples/reproduction-template

To Reproduce

1. Create a basic Next.js app (reproductible with the reproduction-template without changes)
2. Send a POST request to any page with these specific headers:
   • Origin: null
   • Content-Type: application/x-www-form-urlencoded

curl -X POST 'http://localhost:3000/' \
  -H 'Origin: null' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Sec-Fetch-Site: same-origin'

3. You'll get an Internal Server Error

Reproducible locally and on production sites

Current vs. Expected behavior

Current behavior :

Server crashes with

TypeError: Invalid URL
at new URL (node:internal/url:818:25)
at handleAction
at renderToHTMLOrFlightImpl

I think he's trying to create a new URL(“null”) that isn't handled correctly, because he doesn't expect to receive this value, even though it is valid.

Expected behavior:
Next.js should handle origin: null gracefully, as this is a valid value per RFC 6454 Section 7.3.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:29:54 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T8122
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 22.17.1
  npm: 10.9.2
  Yarn: N/A
  pnpm: 10.18.2
Relevant Packages:
  next: 16.0.0-canary.2 // Latest available version is detected (16.0.0-canary.2).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Error Handling, Headers

Which stage(s) are affected? (Select all that apply)

next dev (local), next start (local), Other (Deployed), Vercel (Deployed)

Additional context

Also reproduced on production sites with Next 15.3 and 15.4

To provide some context on how this bug was discovered:
Our users were complaining about 500 errors on some browsers (particularly Firefox) when visiting the site for the first time.

Our site is temporarily under a Cloudflare Challenge.
Once the challenge is successful, Cloudflare redirects to the site via a POST request with the challenge result in the body.

If the user goes to the site, they are redirected to their locale (e.g., / to /en).
What happens with the Cloudflare challenge is that there will be a POST / -> 307 Temporary Redirect
when the challenge is succeded, then a POST /en -> 500 Internal Server Error on Firefox

This happens because Firefox, as a security measure and in accordance with the RFC, will modify the header Origin: mywebsite.com to Origin: null during the second POST request that was redirected. Chromium browsers don't modify the header.

So I think that sites using a Cloudflare challenge, with a user who uses a Firefox browser, may encounter this problem.

This error occurs exclusively when these two headers are sent together in the request.