Uncaught exception in the withastro Astro Node adapter can terminate the server

Astro is a web framework for content-driven websites. Prior to 11.1.3, the @astrojs/node adapter builds a request URL from the Host header, and a malformed port can make that URL invalid. The recovery path reuses the same malformed host and throws an uncaught TypeError: Invalid URL before routing begins. In the default standalone configuration, the request returns an HTTP 500 response and the server continues running, but when staticHeaders is enabled the synchronous handler does not catch the exception and the Node process terminates. Proxies and CDNs that reject malformed Host headers prevent this path from reaching the origin. The issue affects availability only and does not expose data or permit code execution. This issue is fixed in version 11.1.3.

• The npm package @astrojs/node in withastro Astro is affected through version 11.1.2; the CVE record expresses the same boundary as < 11.1.3.
• The confirmed fixed release is 11.1.3.
• Both the default standalone configuration and deployments with staticHeaders enabled should be checked; staticHeaders changes the impact, not the affected version boundary.

The affected component is the @astrojs/node adapter, which builds a request URL from the attacker-controlled Host header. A Host value containing a malformed port, such as multiple hostname and port pairs or an out-of-range port, can produce an invalid URL and raise TypeError: Invalid URL before routing begins. The recovery path reuses the malformed host and fails again, leaving the exception uncaught under CWE-248. In the default standalone configuration, the error becomes an HTTP 500 response and the server continues running; with staticHeaders enabled, the exception reaches a synchronous handler that does not catch it and can terminate the Node process. Actual reachability depends on whether the request passes through proxies or CDNs that may reject malformed Host headers before forwarding it to the origin.

The issue can be triggered remotely over the network with a hand-crafted request containing a malformed Host header. The supplied record indicates that authentication and user interaction are not required, but the request must pass any proxy, CDN, or header-validation layer that may reject the malformed value. With the default standalone configuration, the usual result is an HTTP 500 response; with staticHeaders, the Node process can terminate. The supplied record does not identify a public exploit and does not provide enough evidence to conclude that exploitation has not occurred.

A request with a malformed Host header can fail before any route is executed. In standalone, the server continues running after returning HTTP 500; with staticHeaders, the uncaught exception can terminate the Node process and make the affected service unavailable. The documented impact is limited to availability and does not include data disclosure, data modification, or code execution. Exploitability also depends on whether the malformed header reaches the origin or is rejected by a proxy or CDN.

The operational impact is concentrated on web-service availability:

• In the default standalone configuration, the malformed request receives HTTP 500 while the server continues running, so the impact may be limited to failed requests.
• With staticHeaders enabled, the Node process can terminate, causing service interruption until the deployment's normal process-recovery mechanism restores service.
• The record provides no evidence of data disclosure, data modification, or code execution.
• Proxies and CDNs that reject malformed Host headers can reduce origin reachability, but they are not a substitute for updating the dependency.

1. Upgrade @astrojs/node to version 11.1.3, the release confirmed to contain the fix.
2. If an upgrade cannot be completed immediately, configure the reverse proxy or CDN to reject malformed Host headers before requests reach the origin. This reduces reachability of the vulnerable path but is not a replacement for the fix.
3. Prioritize deployments with staticHeaders enabled because an uncaught exception in that configuration can terminate the Node process.
4. After updating, verify the dependency version in the deployed artifact and review startup or runtime logs to confirm that the running process uses the fixed package.

1. Inventory dependency and runtime metadata to identify deployments using @astrojs/node.
2. Determine which deployments use the default standalone configuration and which enable staticHeaders, because the failure mode differs between them.
3. As a precaution, review application and process logs for TypeError: Invalid URL, uncaught exceptions, or HTTP 500 responses associated with requests carrying unusual Host values.
4. Check reverse proxy and CDN policies to determine whether malformed Host headers are rejected before requests reach the origin.
5. Do not treat the absence of matching log entries as proof of safety, because an intermediary may have blocked the request or the relevant error may not have been logged.