| Affected_by_vulnerabilities |
| 0 |
| url |
VCID-4nsb-h2qe-tug9 |
| vulnerability_id |
VCID-4nsb-h2qe-tug9 |
| summary |
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. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2025-64757, GHSA-x3h8-62x9-952g
|
| risk_score |
1.6 |
| exploitability |
0.5 |
| weighted_severity |
3.1 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-4nsb-h2qe-tug9 |
|
| 1 |
| url |
VCID-8x71-29mv-2qfp |
| vulnerability_id |
VCID-8x71-29mv-2qfp |
| summary |
Atro CSRF Middleware Bypass (security.checkOrigin)
A bug in Astro’s CSRF-protection middleware allows requests to bypass CSRF checks. |
| references |
|
| fixed_packages |
| 0 |
| url |
pkg:npm/astro@4.16.17 |
| purl |
pkg:npm/astro@4.16.17 |
| is_vulnerable |
true |
| affected_by_vulnerabilities |
| 0 |
| vulnerability |
VCID-4nsb-h2qe-tug9 |
|
| 1 |
| vulnerability |
VCID-a19r-4mhu-syhd |
|
| 2 |
| vulnerability |
VCID-gmum-ebwt-f3at |
|
| 3 |
| vulnerability |
VCID-j5k1-5dfe-8udj |
|
| 4 |
| vulnerability |
VCID-jcqr-tk29-xbat |
|
| 5 |
| vulnerability |
VCID-k4f1-y5qy-9ka4 |
|
| 6 |
| vulnerability |
VCID-qcs7-nt67-7qe5 |
|
| 7 |
| vulnerability |
VCID-qt1f-1dkr-y3gs |
|
| 8 |
| vulnerability |
VCID-rjus-p7ga-fugs |
|
| 9 |
| vulnerability |
VCID-w3zj-e7u2-2fh1 |
|
| 10 |
| vulnerability |
VCID-wvqv-3kwm-1uba |
|
|
| resource_url |
http://public2.vulnerablecode.io/packages/pkg:npm/astro@4.16.17 |
|
|
| aliases |
CVE-2024-56140, GHSA-c4pw-33h3-35xw
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-8x71-29mv-2qfp |
|
| 2 |
| url |
VCID-a19r-4mhu-syhd |
| vulnerability_id |
VCID-a19r-4mhu-syhd |
| summary |
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. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2026-41067, GHSA-j687-52p2-xcff
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-a19r-4mhu-syhd |
|
| 3 |
| url |
VCID-gmum-ebwt-f3at |
| vulnerability_id |
VCID-gmum-ebwt-f3at |
| summary |
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: |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2025-65019, GHSA-fvmw-cj7j-j39q
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-gmum-ebwt-f3at |
|
| 4 |
| url |
VCID-k4f1-y5qy-9ka4 |
| vulnerability_id |
VCID-k4f1-y5qy-9ka4 |
| summary |
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. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2025-66202, GHSA-whqg-ppgf-wp8c
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-k4f1-y5qy-9ka4 |
|
| 5 |
| url |
VCID-qcs7-nt67-7qe5 |
| vulnerability_id |
VCID-qcs7-nt67-7qe5 |
| summary |
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. |
| references |
| 0 |
|
| 1 |
| reference_url |
https://github.com/withastro/astro |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
6.1 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N |
|
| 1 |
| value |
6.4 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N |
|
| 2 |
| value |
MODERATE |
| scoring_system |
generic_textual |
| scoring_elements |
|
|
|
| url |
https://github.com/withastro/astro |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
|
| fixed_packages |
| 0 |
|
| 1 |
| url |
pkg:npm/astro@5.13.2 |
| purl |
pkg:npm/astro@5.13.2 |
| is_vulnerable |
true |
| affected_by_vulnerabilities |
| 0 |
| vulnerability |
VCID-4nsb-h2qe-tug9 |
|
| 1 |
| vulnerability |
VCID-a19r-4mhu-syhd |
|
| 2 |
| vulnerability |
VCID-gmum-ebwt-f3at |
|
| 3 |
| vulnerability |
VCID-j5k1-5dfe-8udj |
|
| 4 |
| vulnerability |
VCID-jcqr-tk29-xbat |
|
| 5 |
| vulnerability |
VCID-k4f1-y5qy-9ka4 |
|
| 6 |
| vulnerability |
VCID-rjus-p7ga-fugs |
|
| 7 |
| vulnerability |
VCID-tkwe-8ejd-mfb6 |
|
| 8 |
| vulnerability |
VCID-w3zj-e7u2-2fh1 |
|
| 9 |
| vulnerability |
VCID-wvqv-3kwm-1uba |
|
|
| resource_url |
http://public2.vulnerablecode.io/packages/pkg:npm/astro@5.13.2 |
|
|
| aliases |
CVE-2025-55303, GHSA-xf8x-j4p2-f749
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-qcs7-nt67-7qe5 |
|
| 6 |
| url |
VCID-qt1f-1dkr-y3gs |
| vulnerability_id |
VCID-qt1f-1dkr-y3gs |
| summary |
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. |
| references |
|
| fixed_packages |
| 0 |
| url |
pkg:npm/astro@4.16.18 |
| purl |
pkg:npm/astro@4.16.18 |
| is_vulnerable |
true |
| affected_by_vulnerabilities |
| 0 |
| vulnerability |
VCID-4nsb-h2qe-tug9 |
|
| 1 |
| vulnerability |
VCID-a19r-4mhu-syhd |
|
| 2 |
| vulnerability |
VCID-gmum-ebwt-f3at |
|
| 3 |
| vulnerability |
VCID-j5k1-5dfe-8udj |
|
| 4 |
| vulnerability |
VCID-jcqr-tk29-xbat |
|
| 5 |
| vulnerability |
VCID-k4f1-y5qy-9ka4 |
|
| 6 |
| vulnerability |
VCID-qcs7-nt67-7qe5 |
|
| 7 |
| vulnerability |
VCID-rjus-p7ga-fugs |
|
| 8 |
| vulnerability |
VCID-w3zj-e7u2-2fh1 |
|
| 9 |
| vulnerability |
VCID-wvqv-3kwm-1uba |
|
|
| resource_url |
http://public2.vulnerablecode.io/packages/pkg:npm/astro@4.16.18 |
|
| 1 |
| url |
pkg:npm/astro@5.0.8 |
| purl |
pkg:npm/astro@5.0.8 |
| is_vulnerable |
true |
| affected_by_vulnerabilities |
| 0 |
| vulnerability |
VCID-4nsb-h2qe-tug9 |
|
| 1 |
| vulnerability |
VCID-a19r-4mhu-syhd |
|
| 2 |
| vulnerability |
VCID-gmum-ebwt-f3at |
|
| 3 |
| vulnerability |
VCID-j5k1-5dfe-8udj |
|
| 4 |
| vulnerability |
VCID-jcqr-tk29-xbat |
|
| 5 |
| vulnerability |
VCID-k4f1-y5qy-9ka4 |
|
| 6 |
| vulnerability |
VCID-qcs7-nt67-7qe5 |
|
| 7 |
| vulnerability |
VCID-rjus-p7ga-fugs |
|
| 8 |
| vulnerability |
VCID-w3zj-e7u2-2fh1 |
|
| 9 |
| vulnerability |
VCID-wvqv-3kwm-1uba |
|
|
| resource_url |
http://public2.vulnerablecode.io/packages/pkg:npm/astro@5.0.8 |
|
|
| aliases |
CVE-2024-56159, GHSA-49w6-73cw-chjr
|
| risk_score |
4.0 |
| exploitability |
0.5 |
| weighted_severity |
8.0 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-qt1f-1dkr-y3gs |
|
| 7 |
| url |
VCID-rjus-p7ga-fugs |
| vulnerability_id |
VCID-rjus-p7ga-fugs |
| summary |
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. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2025-64765, GHSA-ggxq-hp9w-j794
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-rjus-p7ga-fugs |
|
| 8 |
| url |
VCID-w3zj-e7u2-2fh1 |
| vulnerability_id |
VCID-w3zj-e7u2-2fh1 |
| summary |
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. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2025-61925, GHSA-5ff5-9fcw-vg88
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-w3zj-e7u2-2fh1 |
|
| 9 |
| url |
VCID-wvqv-3kwm-1uba |
| vulnerability_id |
VCID-wvqv-3kwm-1uba |
| summary |
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)**. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2025-64764, GHSA-wrwg-2hg8-v723
|
| risk_score |
4.0 |
| exploitability |
0.5 |
| weighted_severity |
8.0 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-wvqv-3kwm-1uba |
|
|
|---|