# CVE-2026-27729: Astro has memory exhaustion DoS due to missing request body size limit in Server Actions

> Unauthenticated attackers can crash Astro server actions by sending oversized requests, causing memory exhaustion and denial of service.

- **Severity:** Medium 5.9 (`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 24 Feb 2026
- **Updated:** 26 Feb 2026
- **Also known as:** GHSA-jm64-8m5q-4qh8

## What is CVE-2026-27729?

CVE-2026-27729 is a medium-severity denial of service vulnerability in withastro astro, published on 24 Feb 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

Astro is a web framework. In versions 9.0.0 through 9.5.3, 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. 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. The vulnerability allows unauthenticated denial of service against SSR standalone deployments using server actions. A single oversized request crashes the server process, and repeated requests cause a persistent crash-restart loop in containerized environments. Version 9.5.4 contains a fix.

Weakness: CWE-770 (Allocation of Resources Without Limits or Throttling)

## Which versions are affected by CVE-2026-27729?

2 open source packages ship an affected version, including @astrojs/node. It affects 1 product.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@astrojs/node` | npm | From 9.0.0 | 9.5.4 |
| `@astrojs/node` | npm | From 9.0.0 | 9.5.4 |

Products: Astro \@Astrojs\/Node.

## How do I fix CVE-2026-27729?

Upgrade @astrojs/node to 9.5.4 or later.

## Is CVE-2026-27729 being exploited?

It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-27729 exists.

## Other vulnerabilities in withastro astro

- [CVE-2026-25545](https://insights.sbomify.com/CVE-2026-25545/): Astro has Full-Read SSRF in error rendering via Host: header injection (medium 6.9)
- [CVE-2026-27829](https://insights.sbomify.com/CVE-2026-27829/): Astro is vulnerable to SSRF due to missing allowlist enforcement in remote image inferSize (medium 6.5)
- [CVE-2026-29772](https://insights.sbomify.com/CVE-2026-29772/): Astro: Memory exhaustion DoS due to missing request body size limit in Server Islands (medium 5.9)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-27729 and fix it if it is affected.

What it is: CVE-2026-27729 is a medium-severity denial of service vulnerability in withastro astro, published on 24 Feb 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-27729 exists.

Affected packages and fixed versions:
- @astrojs/node (npm): affected from 9.0.0; fixed in 9.5.4
- @astrojs/node (npm): affected from 9.0.0; fixed in 9.5.4

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-27729/ (Markdown: https://insights.sbomify.com/CVE-2026-27729/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-27729
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-27729
- OSV: https://osv.dev/vulnerability/CVE-2026-27729

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-27729/
Summaries are generated and may contain mistakes; the official description above is the record.