Default error handler throws ERR_INVALID_URL on an unparsable Host header

[sergiooak]

Environment

• nitropack: 2.13.4 (latest)
• h3: 1.15.11
• Node.js: 22.17.0
• preset: node-server
• Reproduced on Windows 11. The same error also appears on a Linux production deployment.

Reproduction

https://github.com/sergiooak/nitro-host-header-error-handler

npm install
npm run build
node .output/server/index.mjs
# then, in another shell:
curl -s -H 'Host: a b' http://127.0.0.1:3000/x

Describe the bug

The default error handler builds the request URL from the raw Host header. When the header is not a valid URL authority, new URL() throws inside the handler, and the throw is not caught there.

Flow:

1. A request arrives with a Host header that new URL() cannot parse, for example a value containing a space.
2. The route does not match, so Nitro runs the default error handler to render the 404.
3. defaultHandler calls getRequestURL(event, { xForwardedHost: true, xForwardedProto: true }).
4. getRequestURL runs new URL(path, \${protocol}://${host}`)with the rawHost. new URL()throwsTypeError [ERR_INVALID_URL]`.
5. The throw escapes the error handler as a rejected promise. trapUnhandledNodeErrors catches it and logs the full stack. The client gets a 404 with a reduced body. The process stays up.

Every request with such a Host logs one full stack trace.

Root cause:

• h3 getRequestURL builds the URL from the unvalidated Host header (getRequestHost returns event.node.req.headers.host).
• Nitro defaultHandler (src/runtime/internal/error/prod.ts) calls getRequestURL with no try/catch, so a throw in the error handler is not contained.

Additional context

Which Host values trigger it: new URL('http://' + host) throws for authority values containing characters such as a space, [, ], <, %, or ::. It does not throw for " or /. Vulnerability scanners commonly send values like "></A></ADDRESS>"><script>alert(document.domain)</script><ADDRESS><A "/xss"', which throws because of the space.

Suggested fix: wrap the getRequestURL call in defaultHandler in try/catch and fall back to event.path, or validate the host in getRequestURL. The same class of bug was handled in @hono/node-server (CVE-2024-32652).

Production note: on a node-server deployment behind PM2, under sustained scanning we saw the service degrade until it stopped responding. A plain pm2 restart did not recover it; only pm2 delete plus a fresh start did. We have not isolated that exact mechanism in the minimal reproduction, which only shows the throw, the logged unhandled rejection, and the degraded response, with the process staying up. We are flagging it because an unauthenticated request reaches the error handler and every hit logs a full stack trace, which compounds at scanner volume.

Logs

TypeError: Invalid URL
 at new URL (node:internal/url:818:25)
 at getRequestURL (.output/server/chunks/_/nitro.mjs:763:10)
 at defaultHandler (.output/server/chunks/_/nitro.mjs:4117:15)
 at defaultNitroErrorHandler (.output/server/chunks/_/nitro.mjs:4107:17)
 at errorHandler (.output/server/chunks/_/nitro.mjs:4171:13)
 at Object.onError (.output/server/chunks/_/nitro.mjs:4407:14)
 at Server.toNodeHandle (.output/server/chunks/_/nitro.mjs:1847:27)
 at process.processTicksAndRejections (node:internal/process/task_queues:105:5) {
 code: 'ERR_INVALID_URL',
 input: '/x',
 base: 'http://a b'
}

[sergiooak]

Some context on how I ran into this, in case it helps with triage.

I didn't find it by fuzzing on purpose. An automated bot was crawling my server looking for endpoints, and a lot of its requests came with junk Host headers, the same kind of XSS probe I put in the repro. On a plain Nitro app that just means one logged stack trace per hit and a broken 404, which is what the reproduction shows.

In production it went further. The app was a node-server build behind PM2, with error logging writing every hit to disk. Under the bot's volume the service degraded until it stopped answering, and a plain pm2 restart didn't bring it back. I had to pm2 delete and start it again from the ecosystem file.

I can't prove the exact chain that took it down, so I'm not claiming a single request crashes the process. But an unauthenticated bot doing routine scanning was enough to knock over a real deployment, and the entry point was the error handler throwing on the Host header. That's why I think it's worth hardening, even if the minimal repro only shows the logged rejection.

[meta-syntax]

I tried to reproduce this on the current main (v3), and it does not reproduce there — this looks specific to the v2 stack (nitropack 2.x + h3 v1).

Tested with a minimal fixture using nitro from main, both nitro dev and a node-server production build:

curl -s -i -H 'Host: a b' http://127.0.0.1:3000/x

Both return a regular 404 JSON response, and the ERR_INVALID_URL throw does not happen — nothing is logged to the server console.

(In dev, the response body includes a stack, but that is the dev error renderer's normal output for the handled 404, not an unhandled rejection.)

{
 "error": true,
 "status": 404,
 "message": "Cannot find any route matching [GET] http://_invalid_/x"
}

The reason: in v3 the request URL is no longer built from the raw Host header.
The srvx Node adapter validates the host and replaces invalid values with a placeholder before the URL is constructed:

// srvx/dist/adapters/node.mjs
if (host && !HOST_RE.test(host)) host = "_invalid_";

So the throw path described here only exists in v2 (h3 v1 getRequestURL calling new URL() with the unvalidated header).

[sergiooak]

Ok, thanks for testing that so quickly @meta-syntax , and for the explanation of what changed under the hood...

So the fix is a side effect of the srvx-based Node adapter rather than something explicit for this Host header case.
Since v3 is still beta and v2 is what's actually running in production for most people right now, is a backport of that host validation to h3 v1 / nitropack 2.x on the table?

[meta-syntax]

Just to be clear, I'm not a maintainer, so whether a backport is on the table isn't my call.

That said, v2-targeted PRs from outside contributors don't seem to have been getting much review activity for the past couple of months, so I'm not sure how a backport would move even if one was sent.

The change itself looks small enough that I'd be happy to send a backport PR if a maintainer signals it's wanted.