CVE-2026-27729
Unrestricted Request Body DoS in Astro Server Actions
Publication date: 2026-02-24
Last updated on: 2026-02-25
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| astro | @astrojs/node | From 9.0.0 (inc) to 9.5.4 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-27729 is a memory exhaustion Denial of Service (DoS) vulnerability in the Astro web framework, specifically affecting server actions in versions 9.0.0 through 9.5.3. The issue arises because Astro server actions do not impose any default limit on the size of incoming request bodies. When a large POST request is sent to a valid server action endpoint, the entire request body (JSON or FormData) is buffered fully into memory without size restrictions.'}, {'type': 'paragraph', 'content': "This can exhaust the server's heap memory, causing the Node.js process to crash, especially in memory-constrained environments. Astro's Node adapter running in standalone mode creates an HTTP server that lacks any built-in protection against large request bodies. In containerized deployments, the crashed process is automatically restarted, but repeated oversized requests cause a persistent crash-restart loop, resulting in continuous denial of service."}, {'type': 'paragraph', 'content': 'The vulnerability is exploitable without authentication because action names are discoverable from HTML form attributes on public pages. A single oversized request is sufficient to crash the server process.'}] [1]
How can this vulnerability impact me? :
This vulnerability can cause a denial of service by crashing the Astro server process when it receives a single large POST request to a server action endpoint. The server exhausts its memory by buffering the entire request body without limits.
In memory-constrained or containerized environments, this leads to the server process crashing and restarting repeatedly, creating a persistent crash-restart loop that makes the service unavailable.
Because the attack requires no authentication and action names are publicly discoverable, an attacker can remotely cause service disruption without any privileges.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for unusually large POST requests sent to Astro server action endpoints, which can cause the server process to crash due to memory exhaustion.'}, {'type': 'paragraph', 'content': 'Since action names are discoverable from HTML form attributes on public pages, you can identify valid server action endpoints by inspecting the HTML forms.'}, {'type': 'paragraph', 'content': 'To detect exploitation attempts or the vulnerability on your system, you can monitor server logs for crashes or restart loops, especially after receiving large POST requests.'}, {'type': 'paragraph', 'content': 'Suggested commands include using network traffic analysis tools like tcpdump or Wireshark to capture and filter large POST requests to your server action endpoints.'}, {'type': 'list_item', 'content': 'Use curl or similar tools to test server action endpoints with large payloads to see if the server crashes, e.g.:'}, {'type': 'list_item', 'content': 'curl -X POST -H "Content-Type: application/json" --data-binary @large_payload.json http://yourserver/action-endpoint'}, {'type': 'list_item', 'content': 'Monitor server logs for out-of-memory errors or process crashes after such requests.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the Astro framework to version 9.5.4 or later, where the vulnerability is fixed by enforcing a default 1 MB limit on the size of server action request bodies.
This fix prevents memory exhaustion by rejecting requests with bodies larger than 1 MB, returning an HTTP 413 (Payload Too Large) response.
If upgrading immediately is not possible, consider implementing external request size limits at the HTTP server or reverse proxy level to block oversized POST requests to server action endpoints.
Additionally, monitor your server for repeated crashes and restart loops caused by large requests and block offending IP addresses if necessary.