CVE-2026-27829: 
JavaScript vulnerability analysis and mitigation

CVE-2026-27829 is a Server-Side Request Forgery (SSRF) vulnerability in Astro's image pipeline that allows bypassing image.domains / image.remotePatterns domain allowlist restrictions when the inferSize option is used. It affects @astrojs/node versions 9.0.0 through 9.5.3 (npm package). The vulnerability was published by the Astro maintainer (matthewp) on February 23, 2026, and patched in version 9.5.4. The CVSS v3.1 base score is 6.5–7.2 (Moderate/Medium), depending on scope interpretation (GitHub Advisory, Astro Security Advisory).

The root cause is a missing domain validation check (CWE-918: Server-Side Request Forgery) in Astro's inferRemoteSize function within packages/astro/src/assets/utils/remoteProbe.ts. When inferSize: true is passed to getImage(), the framework fetches the remote image at render time to determine its dimensions, but prior to the fix, it did not call isRemoteAllowed() to validate the URL against the configured image.domains or image.remotePatterns allowlist. Additionally, HTTP redirects were not blocked (redirect: 'manual' was absent), enabling redirect-based SSRF chaining. An attacker who can influence the image URL — for example, through CMS-managed content or user-supplied data passed to getImage() — can trigger server-side fetches to arbitrary hosts (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker to cause the Astro server to make HTTP requests to arbitrary internal or external hosts, bypassing the developer-configured domain allowlist. This enables SSRF attacks against internal network services (e.g., databases, admin panels) and cloud metadata endpoints (e.g., http://169.254.169.254/ on AWS/GCP/Azure), potentially leading to information disclosure of sensitive credentials or configuration data. Integrity and availability are also marginally impacted, as the server can be directed to consume resources fetching from attacker-controlled or unintended hosts (GitHub Advisory, Astro Security Advisory).

A public proof-of-concept (PoC) is included in the official GitHub Security Advisory, demonstrating exploitation by passing http://127.0.0.1:8888/internal-api as the image src with inferSize: true to bypass an allowlist configured for localhost:9000 only. No evidence of in-the-wild exploitation has been reported as of the advisory date. The EPSS score is approximately 0.038% (23rd percentile), indicating low near-term exploitation probability. The vulnerability is not listed in the CISA KEV catalog. No threat actor attribution is available (GitHub Advisory, Astro Security Advisory).

1. Identify a vulnerable target: Locate an Astro site running @astrojs/node versions 9.0.0–9.5.3 in server-side rendering (output: 'server') mode that uses getImage() with inferSize: true and accepts user- or CMS-supplied image URLs.
2. Identify the internal target: Determine the address of an internal service or cloud metadata endpoint to probe (e.g., http://169.254.169.254/latest/meta-data/ for AWS IMDSv1, or http://127.0.0.1:<port>/internal-api).
3. Inject the malicious URL: Supply the internal service URL as the image src value through the controllable input (e.g., a CMS field, API parameter, or query string) that is passed to getImage({ src: 'http://169.254.169.254/latest/meta-data/', inferSize: true }).
4. Trigger a page render: Request the Astro page that renders the image component, causing the server to fetch the attacker-specified URL at render time without allowlist validation.
5. Observe the response: The internal service receives the HTTP GET request from the Astro server. Depending on the application's error handling and response reflection, the attacker may infer service availability or extract data from response metadata (e.g., image dimensions parsed from the response body) (GitHub Advisory, Astro Security Advisory).

• Network: Outbound HTTP GET requests from the Astro server process to internal IP ranges (e.g., 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata endpoints (169.254.169.254) not matching configured image.domains or image.remotePatterns.
• Network: Outbound requests to cloud metadata URLs such as http://169.254.169.254/latest/meta-data/ or http://metadata.google.internal/ originating from the Node.js server process.
• Logs: Astro server access logs showing requests to pages that use inferSize: true with image URLs pointing to non-allowlisted or internal hosts.
• Logs: Internal service logs (e.g., HTTP servers on loopback interfaces) recording unexpected GET requests from the Astro server's IP address.
• Process: Unusual outbound network connections from the node process hosting the Astro application to internal network addresses or metadata endpoints.

Upgrade @astrojs/node to version 9.5.4 or later, which implements proper isRemoteAllowed() validation in inferRemoteSize() and blocks HTTP redirects (redirect: 'manual') across all image fetch paths (Patch Commit, GitHub Advisory). If immediate upgrade is not possible, disable the inferSize option for all remote images as a temporary workaround. Additionally, validate all user- or CMS-supplied image URLs at the application level before passing them to getImage(), and ensure image.domains / image.remotePatterns are configured as restrictively as possible.

The vulnerability was reported by an external researcher credited as pHo9UBenaA and published by Astro maintainer matthewp on February 23, 2026. A brief post appeared on Bluesky via the CVE tracking account, and the vulnerability was picked up by automated CVE aggregators including Vulners, CVEFeed, and VulDB shortly after disclosure. No significant independent researcher commentary or major media coverage has been identified beyond standard CVE tracking (GitHub Advisory).