Fixed version of @astrojs/node: 11.1.3 (Source: GitHub Advisory Database, GHSA-qh8j-hqjv-7m4x (September 30, 2026))
A backup plan that reuses the broken input is not a backup
Engineers build fallbacks so one bad input does not take a service down. This advisory shows how a fallback can fail. If it leans on the same bad input as the main path, it breaks in the same way.
The flaw sits in the Node adapter for Astro, a web framework. The GitHub Advisory Database published the details on September 30, 2026. The advisory is tracked as CVE-2026-102984.
What happened
Every web request carries a Host header. It tells the server which site name the visitor asked for. The Astro Node adapter uses that header to build the full address of the request.
The advisory says a header with a malformed port produced an invalid address. Its examples are example.com:65536 and example.com:8080:8080. The adapter had a recovery step for addresses it could not parse. But that step took the same broken host value as its input. It hit the same problem and failed a second time.
The outcome was an unhandled error, TypeError: Invalid URL. It surfaced during request setup, ahead of any route or page code.
How one header becomes an outage
The damage depends on configuration. By default, in standalone mode, the request gets a 500 Internal Server Error. The server keeps running.
Turn on the optional staticHeaders: true setting and the picture changes. The error lands in a plain synchronous HTTP handler, and that handler has no code to catch it. The error becomes an uncaughtException, and the process ends.
That difference matters for anyone who owns uptime. The same bad request is a single failed page in one setup. In the other, it ends the server process that serves every visitor.
What this does not mean
The advisory describes the problem as one of availability only. Data is not exposed, and attackers cannot run their own code through it.
An attacker has to send a Host header built by hand. The advisory notes that many proxies and CDNs turn away malformed hosts before the request gets to the origin server. Where a reverse proxy or CDN terminates such headers, this route to the flaw is closed.
The process-ending exposure is narrow. It applies to servers running the Node adapter with the staticHeaders option, reachable by requests that no proxy filters. Default setups are not immune: they still return a 500 error for the malformed request.
How the fix works
Version 11.1.3 changes what happens when the incoming host cannot be read. The request address is now built from a host the server itself controls, so the request is handled and nothing is thrown. Host validation also now refuses any value that holds more than one hostname:port pair.
This is the principle behind the patch. A fallback should rest on something the attacker does not supply.
Where Astro shows up in WebPulse data
WebPulse detected Astro on 81 of the 2,491 sites where it identified a platform, in a September 2026 scan of the Tranco top 10,000 domains. That is 3.3% of detected sites.
The scan cannot tell which of those sites use the Node adapter, which version they run, or whether they set staticHeaders. Treat the figure as a sign of Astro's presence in the sample. It does not measure exposure to this flaw.
What to ask your team
First, does any of our software use @astrojs/node? If so, which version? The advisory says to upgrade to 11.1.3 or later.
Second, is staticHeaders: true turned on? That is the setting where one request can end the process.
Third, does a reverse proxy or CDN sit in front, and does it reject malformed Host headers? Ask for confirmation rather than an assumption.
Fourth, if a process does exit, what brings it back, and who is told? The lesson here is broader than Astro. Ask which of your own fallbacks trust the same input as the path they protect.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
