CVE-2026-29772 in astro
Summary
by MITRE • 03/24/2026
Astro is a web framework. Prior to version 10.0.0, Astro's Server Islands POST handler buffers and parses the full request body as JSON without enforcing a size limit. Because JSON.parse() allocates a V8 heap object for every element in the input, a crafted payload of many small JSON objects achieves ~15x memory amplification (wire bytes to heap bytes), allowing a single unauthenticated request to exhaust the process heap and crash the server. The /_server-islands/[name] route is registered on all Astro SSR apps regardless of whether any component uses server:defer, and the body is parsed before the island name is validated, so any Astro SSR app with the Node standalone adapter is affected. This issue has been patched in version 10.0.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/29/2026
This vulnerability resides within Astro web framework's Server Islands functionality, specifically targeting the POST handler implementation that processes request bodies without adequate size restrictions. The flaw exists in versions prior to 10.0.0 where the framework buffers and parses entire request bodies as JSON without enforcing any limits on payload size. This design oversight creates a critical memory exhaustion vulnerability that can be exploited through carefully crafted malicious inputs. The vulnerability is particularly concerning because the affected route /_server-islands/[name] is automatically registered in all Astro SSR applications regardless of component usage, making virtually any application using the Node standalone adapter susceptible to exploitation.
The technical mechanism behind this vulnerability involves the inherent memory allocation characteristics of V8's JSON parsing engine. When JSON.parse() processes input data, it creates V8 heap objects for each element within the parsed structure, leading to significant memory amplification effects. Attackers can exploit this by crafting payloads consisting of numerous small JSON objects that achieve approximately 15x memory amplification from wire bytes to actual heap bytes consumed. This means that a relatively small network payload can trigger massive memory allocation within the Node.js process, ultimately exhausting the available heap space and causing the server process to crash. The vulnerability is further exacerbated by the order of operations within the framework where the request body is parsed before the island name validation occurs, eliminating any opportunity for early rejection of malicious requests.
The operational impact of this vulnerability extends beyond simple service disruption to potentially enable more sophisticated attack vectors. Since the vulnerability affects all Astro SSR applications using the Node standalone adapter, it represents a widespread risk across deployed applications. The unauthenticated nature of the exploit means that any external party can trigger the memory exhaustion without requiring valid credentials or access privileges. This makes it particularly dangerous in production environments where continuous availability is critical. The crash resulting from heap exhaustion can lead to complete service unavailability, requiring manual intervention to restart affected processes and potentially causing denial of service for legitimate users.
The root cause of this vulnerability aligns with CWE-770, which addresses allocation of resources without limits or with inadequate limits, and represents a classic example of memory exhaustion through algorithmic complexity attacks. From an ATT&CK perspective, this vulnerability maps to T1499.004, which covers resource exhaustion via memory exhaustion, and potentially T1190, which involves exploitation of vulnerabilities in web applications. The issue has been successfully addressed in Astro version 10.0.0 through the implementation of proper request body size limiting mechanisms. Organizations should immediately upgrade to this patched version and implement additional monitoring for suspicious request patterns. Implementing rate limiting and request size restrictions at the reverse proxy level can provide additional defense-in-depth measures while the framework-level fix is being deployed across all affected applications.