Skip to main content
VulnerabilityPublished Updated

CVE-2026-27729: withastro astro · Unthrottled Resource Allocation

Affects withastro astroSource CVE Database V5

0
Compare

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

CVSS 3.1 base score
5.9Medium
How severe the flaw is on the 0–10 CVSS scale.
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:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Feb 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
withastroastroAffected
  • >=9.0.0 <9.5.4
Fixed in
  • 9.5.4
npmastropkg:npm/astroOther threatsAffected
  • >=9.0.0 <9.5.4
Fixed in
  • 9.5.4

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

Community reviews

Loading reviews…