Astro is a modern web framework that supports server-side rendering (SSR) and server actions, which automatically parse incoming request bodies (JSON or FormData) by buffering them entirely into memory. Versions 9.0.0 through 9.5.3 of Astro contain a vulnerability (CVE-2026-27729) where no default size limit is imposed on these request bodies. This lack of throttling or resource allocation limits (CWE-770) allows an attacker to send a single large POST request to a valid server action endpoint, causing memory exhaustion and crashing the server process. The vulnerability is particularly impactful in deployments using Astro's Node adapter in standalone mode, which creates an HTTP server without any built-in body size protection. Since server action names are discoverable from HTML form attributes on public pages, attackers can identify valid endpoints without authentication. In containerized environments, the server process automatically restarts after a crash, but repeated oversized requests cause a persistent crash-restart loop, effectively denying service. The vulnerability does not affect confidentiality or integrity but severely impacts availability. The issue was addressed in Astro version 9.5.4 by introducing request body size limits or other resource throttling mechanisms. No known exploits are reported in the wild as of the publication date.

This vulnerability can cause denial of service by crashing the server process handling SSR requests, leading to downtime and degraded user experience. Organizations running Astro-based SSR applications, especially in containerized or memory-constrained environments, risk persistent service interruptions due to crash-restart loops triggered by oversized POST requests. The attack requires no authentication and can be launched remotely over the network, increasing its risk profile. While it does not compromise data confidentiality or integrity, the availability impact can disrupt business operations, customer access, and potentially damage reputation. The ease of discovering valid server action endpoints from public pages lowers the barrier for attackers. Enterprises relying on Astro for critical web services or high-traffic sites may face operational instability and increased incident response costs until patched.

Upgrade all affected Astro deployments to version 9.5.4 or later, which includes fixes that impose request body size limits and prevent memory exhaustion. If immediate upgrade is not feasible, implement reverse proxy or web application firewall (WAF) rules to restrict the maximum allowed request body size for POST requests targeting server action endpoints. Monitor server logs for repeated large POST requests and implement rate limiting to reduce the risk of crash-restart loops. In containerized environments, configure health checks and restart policies to avoid rapid crash loops that degrade service availability. Additionally, consider obfuscating or restricting access to server action endpoints to reduce their discoverability from public HTML forms. Conduct regular security testing and monitoring to detect anomalous request patterns indicative of exploitation attempts.