{"answers":{"affected":"2 open source packages ship an affected version, including @astrojs/node. It affects 1 product.","exploited":"It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-29772 exists.","fix":"Upgrade @astrojs/node to 10.0.0 or later.","what":"CVE-2026-29772 is a medium-severity denial of service vulnerability in withastro astro, published on 24 Mar 2026. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-29772 and fix it if it is affected.\n\nWhat it is: CVE-2026-29772 is a medium-severity denial of service vulnerability in withastro astro, published on 24 Mar 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-29772 exists.\n\nAffected packages and fixed versions:\n- @astrojs/node (npm): affected all versions; fixed in 10.0.0\n- @astrojs/node (npm): affected all versions; fixed in 10.0.0\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-29772/ (Markdown: https://insights.sbomify.com/CVE-2026-29772/index.md)","id":"CVE-2026-29772","markdown":"https://insights.sbomify.com/CVE-2026-29772/index.md","name":"CVE-2026-29772","record":{"aliases":["GHSA-3rmj-9m5h-8fpv"],"analysis":{"component_type":"web_application","fix_type":"upgrade","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":false,"product_category":"Astro web framework","requires_auth":"none","summary":"Unauthenticated attackers can crash Astro SSR servers by sending large JSON payloads to Server Islands endpoints, causing memory exhaustion.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"GitHub_M","cpe":[{"product":"\\@astrojs\\/node","vendor":"astro"}],"cvss":{"score":5.9,"severity":"medium","source":"cna","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[{"id":"CWE-770","name":"Allocation of Resources Without Limits or Throttling"}],"description":"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.","ecosystems":["npm"],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"weaponised"},"has_fix":true,"headline":"Astro: Memory exhaustion DoS due to missing request body size limit in Server Islands","id":"CVE-2026-29772","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":"npm","product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":2,"n_references":1,"next":{"headline":"kubewarden-controller cross-namespace data exfiltration via deprecated host callback binding","id":"CVE-2026-29773"},"packages":[{"ecosystem":"npm","fixed":["10.0.0"],"introduced":["0"],"last_affected":[],"package":"@astrojs/node","purl":null,"source":"GHSA-3rmj-9m5h-8fpv"},{"ecosystem":"npm","fixed":["10.0.0"],"introduced":["0"],"last_affected":[],"package":"@astrojs/node","purl":"pkg:npm/%40astrojs/node","source":"GHSA-3rmj-9m5h-8fpv"}],"prev":{"headline":"Netmaker: Denial of Service via Server Shutdown Endpoint","id":"CVE-2026-29771"},"products":["astro"],"published":"2026-03-24","related":[{"cvss_score":6.9,"headline":"Astro has Full-Read SSRF in error rendering via Host: header injection","id":"CVE-2026-25545","kev_date_added":null,"published":"2026-02-24"},{"cvss_score":6.5,"headline":"Astro is vulnerable to SSRF due to missing allowlist enforcement in remote image inferSize","id":"CVE-2026-27829","kev_date_added":null,"published":"2026-02-26"},{"cvss_score":5.9,"headline":"Astro has memory exhaustion DoS due to missing request body size limit in Server Actions","id":"CVE-2026-27729","kev_date_added":null,"published":"2026-02-24"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"poc","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-03-24","vendors":["withastro"]},"summary":"Unauthenticated attackers can crash Astro SSR servers by sending large JSON payloads to Server Islands endpoints, causing memory exhaustion.","url":"https://insights.sbomify.com/CVE-2026-29772/"}