Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 <=…
Recommended action: Upgrade to 11.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact With trailingSlash: 'always' configured, the @astrojs/node standalone server's static file handler appends a trailing slash to request paths and issues a 301 redirect. Paths beginning with /\ (slash-backslash) were not recognized as internal paths, so the handler would echo the raw path back in the Location header. Because browsers treat \ as / per the WHATWG URL specification, the resulting redirect could resolve to an external host. Preconditions: - trailingSlash: 'always' must be set (non-default; the default is 'ignore') - The request path must not have a file extension in its final segment - An attacker must deliver the crafted link to a user Patches Fixed by treating backslash-prefixed paths the same as //-prefixed paths in isInternalPath(), so they are no longer rewritten with a trailing slash. Workarounds Use the default trailingSlash: 'ignore' setting, which does not issue trailing-slash redirects in the static file handler. References - WHATWG URL spec: backslash…
Recommended action: Upgrade to 11.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Requesting a static JS/CSS resource from the astro path with an incorrect or malformed if-match header returns a 500 error with a one-year cache lifetime instead of 412 in some cases. As a result, all subsequent requests to that file — regardless of the if-match header — will be served a 5xx error instead of the file until the cache expires. Sending an incorrect or malformed if-match header should always return a 412 error without any cache headers, which is not the current behavior. Affected Versions - astro@5.14.1 - @astrojs/node@9.4.4 Proof of Concept Run the following command: If a 5xx error is not returned, inspect the resources via the browser's web inspector and select another CSS/JS file to request until a 5xx error is returned. The behavior generally defaults to a 5xx response. Note that all static files are immutable, so the cache must be purged or disabled to reproduce reliably. A response similar to the following is expected from CloudFront: The above is not the…
Recommended action: Upgrade to 10.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Astro's Server Islands POST handler buffers and parses the full request body as JSON without enforcing a size limit. Because JSON.parse() allocates a V8 heap object for every element in the input, a crafted payload of many small JSON objects achieves ~15x memory amplification (wire bytes to heap bytes), allowing a single unauthenticated request to exhaust the process heap and crash the server. The /server-islands/[name] route is registered on all Astro SSR apps regardless of whether any component uses server:defer, and the body is parsed before the island name is validated, so any Astro SSR app with the Node standalone adapter is affected. Details Astro automatically registers a Server Islands route at /server-islands/[name] on all SSR apps, regardless of whether any component uses server:defer. The POST handler in packages/astro/src/core/server-islands/endpoint.ts buffers the entire request body into memory and parses it as JSON with no size or depth limit: The request body…
Recommended action: Upgrade to 10.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Astro server actions have no default request body size limit, which can lead to memory exhaustion DoS. A single large POST to a valid action endpoint can crash the server process on memory-constrained deployments. Details On-demand rendered sites built with Astro can define server actions, which automatically parse incoming request bodies (JSON or FormData). The body is buffered entirely into memory with no size limit — a single oversized request is sufficient to exhaust the process heap and crash the server. Astro's Node adapter (mode: 'standalone') creates an HTTP server with no body size protection. In containerized environments, the crashed process is automatically restarted, and repeated requests cause a persistent crash-restart loop. Action names are discoverable from HTML form attributes on any public page, so no authentication is required. PoC <details Setup Create a new Astro project with the following files: package.json: astro.config.mjs: src/actions/index.ts:…
Recommended action: Upgrade to 9.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A bug in Astro's image pipeline allows bypassing image.domains / image.remotePatterns restrictions, enabling the server to fetch content from unauthorized remote hosts. Details Astro provides an inferSize option that fetches remote images at render time to determine their dimensions. Remote image fetches are intended to be restricted to domains the site developer has manually authorized (using the image.domains or image.remotePatterns options). However, when inferSize is used, no domain validation is performed — the image is fetched from any host regardless of the configured restrictions. An attacker who can influence the image URL (e.g., via CMS content or user-supplied data) can cause the server to fetch from arbitrary hosts. PoC <details Setup Create a new Astro project with the following files: package.json: astro.config.mjs — only localhost:9000 is authorized: internal-service.mjs — simulates an internal service on a non-allowlisted host (127.0.0.1:8888):…
Recommended action: Upgrade to 9.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Server-Side Rendered pages that return an error with a prerendered custom error page (eg. 404.astro or 500.astro) are vulnerable to SSRF. If the Host: header is changed to an attacker's server, it will be fetched on /500.html and they can redirect this to any internal URL to read the response body through the first request. Details The following line of code fetches statusURL and returns the response back to the client: https://github.com/withastro/astro/blob/bf0b4bfc7439ddc565f61a62037880e4e701eb05/packages/astro/src/core/app/base.ts#L534 statusURL comes from this.baseWithoutTrailingSlash, which is built from the Host: header. prerenderedErrorPageFetch() is just fetch(), and follows redirects. This makes it possible for an attacker to set the Host: header to their server (eg. Host: attacker.tld), and if the server still receives the request without normalization, Astro will now fetch http://attacker.tld/500.html. The attacker can then redirect this request to…
Recommended action: Upgrade to 9.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of astro, the image optimization endpoint in projects deployed with on-demand rendering allows images from unauthorized third-party domains to be served. Details On-demand rendered sites built with Astro include an /image endpoint which returns optimized versions of images. The /image endpoint is restricted to processing local images bundled with the site and also supports remote images from domains the site developer has manually authorized (using the image.domains or image.remotePatterns options). However, a bug in impacted versions of astro allows an attacker to bypass the third-party domain restrictions by using a protocol-relative URL as the image source, e.g. /image?href=//example.com/image.png. Proof of Concept 1. Create a new minimal Astro project (astro@5.13.0). 2. Configure it to use the Node adapter (@astrojs/node@9.1.0 — newer versions are not impacted): 3. Build the site by running astro build. 4. Run the server, e.g. with astro preview. 5.…
Recommended action: Upgrade to 9.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Following https://github.com/withastro/astro/security/advisories/GHSA-cq8c-xv66-36gw, there's still an Open Redirect vulnerability in a subset of Astro deployment scenarios. Details Astro 5.12.8 fixed a case where https://example.com//astro.build/press would redirect to the external origin //astro.build/press. However, with the Node deployment adapter in standalone mode and trailingSlash set to "always" in the Astro configuration, https://example.com//astro.build/press still redirects to //astro.build/press. Proof of Concept 1. Create a new minimal Astro project (astro@5.12.8) 2. Configure it to use the Node adapter (@astrojs/node@9.4.0) and force trailing slashes: 3. Build the site by running astro build. 4. Run the server, e.g. with astro preview. 5. Append //astro.build/press to the preview URL, e.g. <http://localhost:4321//astro.build/press 6. The site will redirect to the external Astro Build origin. Example reproduction 1. Open this StackBlitz reproduction. 2. Open the…
Recommended action: Upgrade to 9.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.