CVE-2026-29772: 
JavaScript vulnerability analysis and mitigation

CVE-2026-29772 is a memory exhaustion Denial of Service (DoS) vulnerability in Astro's Server Islands POST handler, caused by the absence of a request body size limit during JSON parsing. The /_server-islands/[name] route is registered on all Astro SSR applications using the Node standalone adapter, regardless of whether any component uses server:defer, and the body is parsed before the island name is validated. Affected versions are @astrojs/node >= 9.0.0 and < 10.0.0 (specifically demonstrated on Astro 5.18.0 with @astrojs/node 9.5.4). The vulnerability was published on March 24, 2026, with a patch released the same day. It carries a CVSS v3.1 base score of 5.9 (Moderate) per the GitHub Security Advisory, or 7.5 (High) per NVD (GitHub Advisory, Astro Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling). In packages/astro/src/core/server-islands/endpoint.ts (lines 55–56), the POST handler calls await request.text() to buffer the entire request body into memory with no size cap, then passes the result directly to JSON.parse() with no element count or depth limit. Because JSON.parse() allocates a V8 heap object for every array or object element in the input, a payload of many small empty JSON objects (e.g., [{},{},{},...,{}]) achieves approximately 15x memory amplification from wire bytes to heap bytes — an 8.6 MB request can generate over 180 MB of heap allocation, exceeding typical Node.js heap limits. Critically, the body is parsed before the island name parameter is validated, so no knowledge of valid island names is required; any path under /_server-islands/ triggers the vulnerable code path without authentication (Astro Advisory, GitHub Advisory).

Successful exploitation results in complete availability loss for the affected Astro server process — the Node.js process is OOM-killed and does not recover automatically. In containerized environments with memory limits and restart policies, repeated requests cause a persistent crash-restart loop, denying service to all users indefinitely. There is no confidentiality or integrity impact; the vulnerability is purely a DoS condition. The attack surface is broad: any Astro SSR application using the Node standalone adapter is affected by default, even if no server island components are used (Astro Advisory).

A public proof-of-concept exploit (crash.py) is included in the official security advisory, consisting of a Python script that sends a crafted JSON payload of 3 million empty objects (~8.6 MB) to the /_server-islands/x endpoint to crash the server. No authentication, valid island name, or special privileges are required. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.012–0.026% (low probability of exploitation in the next 30 days), and the vulnerability is not listed in the CISA KEV catalog (Astro Advisory, GitHub Advisory).

1. Reconnaissance: Identify internet-facing Astro SSR applications using the Node standalone adapter (versions @astrojs/node 9.0.0–9.x). These can be found via HTTP response headers, JavaScript framework fingerprinting tools, or Shodan/Censys searches for Astro-specific response patterns.
2. Confirm endpoint availability: Send a GET or POST request to /_server-islands/x (or any arbitrary name) on the target. The route is registered by default on all affected SSR apps, so a response (even an error) confirms the endpoint exists.
3. Craft the malicious payload: Generate a JSON array of 3 million empty objects: payload = '[' + ','.join(['{}'] * 3_000_000) + ']'. This produces an ~8.6 MB payload that expands to 180+ MB on the V8 heap.
4. Send the exploit request: POST the payload to /_server-islands/<any_name> with Content-Type: application/json. The server buffers and parses the full body before any validation occurs.
5. Achieve DoS: The Node.js process exhausts its heap and is OOM-killed. In containerized environments with restart policies, repeat the request to maintain a persistent crash-restart loop (Astro Advisory).

• Network: Inbound HTTP POST requests to /_server-islands/<any_string> with large request bodies (approaching or exceeding several MB); Content-Type: application/json headers on requests to this endpoint from unexpected sources.
• Logs: Node.js process crash logs or OOM kill signals in system/container logs (e.g., Killed or OOMKilled in Docker/Kubernetes event logs); sudden absence of Astro server access logs following a large POST to /_server-islands/.
• Process: Unexpected termination of the Node.js Astro server process; rapid container restart cycles in orchestrated environments (e.g., Kubernetes pod restart count increasing rapidly).
• System: Memory usage spike to process heap limit immediately before crash, visible in container metrics or Node.js process monitoring (Astro Advisory).

The primary fix is to upgrade @astrojs/node to version 10.0.0 or later, which enforces a request body size limit in the Server Islands POST handler. For deployments where immediate patching is not possible, implement request body size limits at the reverse proxy or load balancer layer (e.g., client_max_body_size in nginx, or equivalent settings in AWS ALB/Cloudflare) to prevent oversized JSON payloads from reaching the Astro application. Additionally, consider rate-limiting or blocking POST requests to the /_server-islands/ path at the network perimeter if the feature is not in use (Astro Advisory, GitHub Advisory).