CVE-2026-27729: withastro astro · Unthrottled Resource Allocation
Affects withastro astroSource CVE Database V5
Not known to be exploited · CVSS 5.9 Medium : upgrade to 9.5.4 when convenient.
Data as of 29 Oct 2026, 19:04 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 41% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 9.5.4
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 24 Feb 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Upgrade withastro astro to 9.5.4.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| withastroastro | Affected
| Fixed in
|
npmastropkg:npm/astroOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
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.
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.
References
- github.com/withastro/astro/security/advisories/GHSA-jm64-8m5q-4qh8 (opens in a new tab)
- github.com/withastro/astro/pull/15564 (opens in a new tab)
- github.com/withastro/astro/commit/522f880b07a4ea7d69a19b5507fb53a5ed6c87f8 (opens in a new tab)
- github.com/withastro/astro/releases/tag/%40astrojs%2Fnode%409.5.4 (opens in a new tab)