astrojs-node

## Summary The `/_image` endpoint used by the `@astrojs/node` adapter checks that a requested local image is inside the build output directory before reading it from disk. That check compared paths case-insensitively. On case-sensitive filesystems (such as Linux), a directory whose path differs from the output directory only by letter case is a different directory, but it passed the check. For example, with the client output directory at `/srv/app/dist/client/`, a request such as: ```text /_image?href=/../../DIST/client/secret.png&w=32&f=png ``` resolved to `/srv/app/DIST/client/secret.png

CVE: CVE-2026-126364

## 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

CVE: CVE-2026-102984

### 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

CVE: CVE-2026-59730

### Summary 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 Conce

CVE: CVE-2026-41322

### Summary 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,

CVE: CVE-2026-29772

## Summary 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

CVE: CVE-2026-27829

## Summary 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

CVE: CVE-2026-27729

### Summary 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

CVE: CVE-2026-25545

### Summary 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`](https://docs.astro.build/en/reference/configuration-reference/#imagedomains)

CVE: CVE-2025-55303

### Summary 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 pr

CVE: CVE-2025-55207