# CVE-2026-27829: Astro is vulnerable to SSRF due to missing allowlist enforcement in remote image inferSize > Attackers can bypass image domain restrictions to force the server to fetch arbitrary URLs, enabling SSRF against internal services. - **Severity:** Medium 6.5 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L`) - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 26 Feb 2026 - **Updated:** 26 Feb 2026 - **Also known as:** GHSA-cj9f-h6r6-4cx2 ## What is CVE-2026-27829? CVE-2026-27829 is a medium-severity server-side request forgery vulnerability in withastro astro, published on 26 Feb 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. ### Official description Astro is a web framework. In versions 9.0.0 through 9.5.3, a bug in Astro's image pipeline allows bypassing `image.domains` / `image.remotePatterns` restrictions, enabling the server to fetch content from unauthorized remote hosts. Astro provides an `inferSize` option that fetches remote images at render time to determine their dimensions. Remote image fetches are intended to be restricted to domains the site developer has manually authorized (using the `image.domains` or `image.remotePatterns` options). However, when `inferSize` is used, no domain validation is performed — the image is fetched from any host regardless of the configured restrictions. An attacker who can influence the image URL (e.g., via CMS content or user-supplied data) can cause the server to fetch from arbitrary hosts. This allows bypassing `image.domains` / `image.remotePatterns` restrictions to make server-side requests to unauthorized hosts. This includes the risk of server-side request forgery (SSRF) against internal network services and cloud metadata endpoints. Version 9.5.4 fixes the issue. Weakness: CWE-918 (Server-Side Request Forgery) ## Which versions are affected by CVE-2026-27829? 2 open source packages ship an affected version, including @astrojs/node. It affects 1 product. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `@astrojs/node` | npm | From 9.0.0 | 9.5.4 | | `@astrojs/node` | npm | From 9.0.0 | 9.5.4 | Products: Astro \@Astrojs\/Node. ## How do I fix CVE-2026-27829? Upgrade @astrojs/node to 9.5.4 or later. ## Is CVE-2026-27829 being exploited? It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-27829 exists. ## Other vulnerabilities in withastro astro - [CVE-2026-25545](https://insights.sbomify.com/CVE-2026-25545/): Astro has Full-Read SSRF in error rendering via Host: header injection (medium 6.9) - [CVE-2026-29772](https://insights.sbomify.com/CVE-2026-29772/): Astro: Memory exhaustion DoS due to missing request body size limit in Server Islands (medium 5.9) - [CVE-2026-27729](https://insights.sbomify.com/CVE-2026-27729/): Astro has memory exhaustion DoS due to missing request body size limit in Server Actions (medium 5.9) ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2026-27829 and fix it if it is affected. What it is: CVE-2026-27829 is a medium-severity server-side request forgery vulnerability in withastro astro, published on 26 Feb 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-27829 exists. Affected packages and fixed versions: - @astrojs/node (npm): affected from 9.0.0; fixed in 9.5.4 - @astrojs/node (npm): affected from 9.0.0; fixed in 9.5.4 Task: 1. 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. 2. 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. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2026-27829/ (Markdown: https://insights.sbomify.com/CVE-2026-27829/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2026-27829 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-27829 - OSV: https://osv.dev/vulnerability/CVE-2026-27829 --- From sbomify Insights: https://insights.sbomify.com/CVE-2026-27829/ Summaries are generated and may contain mistakes; the official description above is the record.