GHSA-qh8j-hqjv-7m4x: Npm/@astrojs/node vulnerability
Summary
In the Astro Node adapter, a request whose Host header contains a malformed port (for example example.com:65536 or example.com:8080:8080) produced an invalid request URL. The fallback intended to recover from an unparseable URL reused the same malformed host, so it failed again and raised an uncaught TypeError: Invalid URL while the request was being built, before any route ran.
Impact
The effect depends on the adapter configuration:
- Default configuration (standalone): the request returns 500 Internal Server Error and the server continues running. - With the opt-in staticHeaders: true option: the throw reaches a synchronous HTTP handler that does not catch it, becoming an uncaughtException that terminates the process.
This is an availability-only issue. It does not expose data or allow code execution. Triggering it requires sending a hand-crafted Host header, and many proxies and CDNs reject malformed hosts before they reach the origin.
Affected versions
@astrojs/node <= 11.1.2.
Patches
Fixed in @astrojs/node 11.1.3. When the incoming host cannot be parsed, the request URL now degrades to a host the server controls, so the request is handled instead of throwing. Hosts carrying more than a single hostname:port pair are also rejected during host validation.
Workarounds
Upgrade to @astrojs/node 11.1.3 or later. Deployments that terminate malformed Host headers at a reverse proxy or CDN are not reachable through this path.
Credits
Reported by @Celggar.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@astrojs/nodeto a version that resolves this vulnerability.Fixed in 11.1.3 - Upgrade
Upgrade
@astrojs/nodeto a version that resolves this vulnerability.Fixed in 11.1.3
Event History
Frequently Asked Questions
When can this lead to a process crash rather than a failed request?
A process crash occurs only when the Astro Node adapter is configured with the opt-in staticHeaders: true option. In the default standalone configuration, the malformed request instead receives a 500 Internal Server Error and the server continues running.
What must an attacker be able to do to trigger the issue?
They must send a request with a deliberately malformed Host header, such as one containing an invalid or repeated port. Proxies and CDNs may prevent exploitation if they reject malformed Host headers before forwarding requests to the origin.
How can I determine whether an installation is affected?
Installations using @astrojs/node version 11.1.2 or earlier are affected. Deployments using staticHeaders: true have the higher availability impact because a triggering request can terminate the process.
What is the remediation if the adapter is in use?
Upgrade @astrojs/node to version 11.1.3, which handles an unparseable incoming host by using a server-controlled host for the request URL. If upgrading cannot happen immediately, avoid enabling staticHeaders: true and ensure upstream infrastructure rejects malformed Host headers.