<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-01T05:19:05.242839+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-102984</id>
    <title>fkie_cve-2026-102984</title>
    <updated>2026-10-01T05:19:05.269365+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-102984"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-qh8j-hqjv-7m4x</id>
    <title>GHSA-qh8j-hqjv-7m4x — Astro: Malformed port in the Host header can crash the Node adapter</title>
    <updated>2026-10-01T05:19:05.269447+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: @astrojs/node</p>
<p>## Summary</p>
<p>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.</p>
<p>## Impact</p>
<p>The effect depends on the adapter configuration:</p>
<p>- 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.</p>
<p>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.</p>
<p>## Affected versions</p>
<p>`@astrojs/node` &lt;= 11.1.2.</p>
<p>## Patches</p>
<p>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.</p>
<p>## Workarounds</p>
<p>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 thi…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-qh8j-hqjv-7m4x"/>
  </entry>
</feed>
