
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: <= 11.1.2
Patched in 11.1.3
Details
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.
The effect depends on the adapter configuration:
standalone): the request returns 500 Internal Server Error and the server continues running.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.
@astrojs/node <= 11.1.2.
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.
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.
Reported by @Celggar.
EPSS, exploit probability
Low0.36%
estimated chance of real-world exploitation in the next 30 days, higher than 30.5% of every CVE FIRST.org scores
Refreshed 11/15/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
More npm advisories
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.