Astro is a modern web framework that supports server actions to handle POST requests with JSON or FormData bodies. In versions 9.0.0 through 9.5.3, Astro's server actions do not enforce any default limit on the size of incoming request bodies. The entire request body is buffered into memory without throttling or size restrictions, which can lead to memory exhaustion on the server. Specifically, the Node adapter in 'standalone' mode creates an HTTP server that lacks built-in protection against large request bodies. An attacker can send a single oversized POST request to a valid server action endpoint, which is discoverable from HTML form attributes on public pages, without requiring authentication. This causes the server process to consume excessive memory, leading to a crash. In containerized deployments, the crashed process is automatically restarted, but repeated oversized requests cause a persistent crash-restart loop, resulting in a denial of service. The vulnerability is categorized under CWE-770 (Allocation of Resources Without Limits or Throttling). The issue was publicly disclosed on February 24, 2026, and fixed in Astro version 9.5.4. No known exploits are reported in the wild at this time. The CVSS v3.1 score is 5.9, with vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, indicating network attack vector, high attack complexity, no privileges or user interaction required, unchanged scope, no confidentiality or integrity impact, but high availability impact.

This vulnerability primarily impacts the availability of web applications built with Astro versions 9.0.0 to 9.5.3 that use server actions and are deployed in standalone SSR mode, especially in containerized environments. An attacker can cause a denial of service by sending a single large POST request, crashing the server process. In containerized setups, this leads to a crash-restart loop, causing persistent downtime and degraded service availability. Organizations relying on Astro for public-facing websites or APIs may experience service interruptions, loss of customer trust, and potential revenue impact. Since no authentication is required and action endpoints are discoverable, the attack surface is broad. Although there is no direct confidentiality or integrity impact, the disruption of service can affect business operations and user experience. The medium severity rating reflects the significant availability impact combined with the requirement for high attack complexity, which may limit exploitation to skilled attackers or automated tools capable of crafting large requests.

To mitigate this vulnerability, organizations should upgrade all affected Astro deployments to version 9.5.4 or later, where the issue is fixed. Until upgrades can be applied, implement strict request body size limits at the HTTP server or reverse proxy level (e.g., NGINX, Apache, or cloud WAF) to prevent oversized POST requests from reaching the Astro server. Configure rate limiting and request throttling to reduce the risk of repeated exploitation attempts causing crash-restart loops. Monitor server logs and container health metrics for signs of memory exhaustion or frequent restarts. If possible, avoid using the Node adapter in standalone mode for SSR deployments or deploy additional middleware that enforces body size limits. Conduct security testing to identify any other endpoints that may lack request size restrictions. Finally, educate development teams about secure resource allocation practices and the importance of limiting input sizes to prevent similar vulnerabilities.