CVE-2026-102984
highpriority · track · 0EPSS 0.004 · 30 %ileUSEPSS · scored 2026-10-27
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.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–high · 4.6–8.2
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (1)
Products and version ranges known to be affected.
advisories (1)
Vendor and ecosystem advisories describing this.
- GHSA-qh8j-hqjv-7m4xAstro: Malformed port in the Host header can crash the Node adapter2026-09-30ghsa · osvUS
## 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.
sources
Which sources assert this record, and when.
references (4) nvd
External citations — patches, advisories, analysis.
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan