GHSA-FVMW-CJ7J-J39Q
Vulnerability from github – Published: 2025-11-19 20:09 – Updated: 2025-11-27 08:15Summary
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
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:
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)
- Create a minimal Astro project with Cloudflare adapter (
output: 'server'). - Deploy to Cloudflare Pages or Workers.
- Request the image endpoint with the following payload:
https://yoursite.com/_image?href=data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxzY3JpcHQ+YWxlcnQoJ3pvbWFzZWMnKTwvc2NyaXB0Pjwvc3ZnPg==
(Base64 decodes to: <svg xmlns="http://www.w3.org/2000/svg"><script>alert('zomasec')</script></svg>)
- The endpoint returns a 302 redirect to the
data:URL → browser executes the<script>→alert()fires.
Impact
- Reflected/Strored XSS (depending on application usage)
- Session hijacking (access to cookies, localStorage, etc.)
- Account takeover when combined with CSRF
- Data exfiltration to attacker-controlled servers
- Bypasses image.domains / image.remotePatterns configuration entirely
Safe vs Vulnerable Behavior
Other Astro adapters (Node, Vercel, etc.) typically proxy and rasterize SVGs, stripping JavaScript. The Cloudflare adapter currently redirects to remote resources (including data: URLs), making it uniquely vulnerable.
References
- Vulnerable function: https://github.com/withastro/astro/blob/main/packages/internal-helpers/src/remote.ts
- Similar data: URL bypass in WordPress: CVE-2025-2575
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "astro"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.15.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-65019"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-19T20:09:12Z",
"nvd_published_at": "2025-11-19T17:15:53Z",
"severity": "MODERATE"
},
"details": "**Summary** \nA Cross-Site Scripting (XSS) vulnerability exists in Astro when using the **@astrojs/cloudflare** adapter with `output: \u0027server\u0027`. The built-in image optimization endpoint (`/_image`) uses `isRemoteAllowed()` from Astro\u2019s 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.\n\n**Affected Versions** \n- `@astrojs/cloudflare` \u2264 12.6.10 (and likely all previous versions) \n- Astro \u2265 4.x when used with `output: \u0027server\u0027` and the Cloudflare adapter\n\n**Root Cause \u2013 Vulnerable Code** \nFile: `node_modules/@astrojs/internal-helpers/src/remote.ts`\n\n```ts\nexport function isRemoteAllowed(src: string, ...): boolean {\n if (!URL.canParse(src)) {\n return false;\n }\n const url = new URL(src);\n\n // Data URLs are always allowed \n if (url.protocol === \u0027data:\u0027) {\n return true;\n }\n\n // Non-http(s) protocols are never allowed\n if (![\u0027http:\u0027, \u0027https:\u0027].includes(url.protocol)) {\n return false;\n }\n // ... further http/https allow-list checks\n}\n```\n\nIn the **Cloudflare adapter**, the `/_image` endpoint contains logic similar to:\n\n```ts\n\tconst href = ctx.url.searchParams.get(\u0027href\u0027);\n\tif (!href) {\n\t\t// return error \n\t}\n\n\tif (isRemotePath(href)) {\n\t\tif (isRemoteAllowed(href, imageConfig) === false) {\n\t\t\t// return error\n\t\t} else {\n //redirect to return the image \n\t\t\treturn Response.redirect(href, 302);\n\t\t}\n\t}\n```\n\nBecause `data:` URLs are considered \u201callowed\u201d, a request such as: \n`https://example.com/_image?href=data:image/svg+xml;base64,PHN2Zy... (base64-encoded malicious SVG)` \n\ntriggers a **302 redirect directly to the `data:` URL**, causing the browser to render and execute the malicious JavaScript inside the SVG.\n\n**Proof of Concept (PoC)** \n\n1. Create a minimal Astro project with Cloudflare adapter (`output: \u0027server\u0027`).\n2. Deploy to Cloudflare Pages or Workers.\n3. Request the image endpoint with the following payload:\n\n```\nhttps://yoursite.com/_image?href=data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxzY3JpcHQ+YWxlcnQoJ3pvbWFzZWMnKTwvc2NyaXB0Pjwvc3ZnPg==\n```\n\n (Base64 decodes to: `\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\u003cscript\u003ealert(\u0027zomasec\u0027)\u003c/script\u003e\u003c/svg\u003e`)\n\n4. The endpoint returns a **302 redirect** to the `data:` URL \u2192 browser executes the `\u003cscript\u003e` \u2192 `alert()` fires.\n\n**Impact** \n- Reflected/Strored XSS (depending on application usage) \n- Session hijacking (access to cookies, localStorage, etc.) \n- Account takeover when combined with CSRF \n- Data exfiltration to attacker-controlled servers \n- Bypasses `image.domains` / `image.remotePatterns` configuration entirely \n\n**Safe vs Vulnerable Behavior** \nOther Astro adapters (Node, Vercel, etc.) typically **proxy and rasterize** SVGs, stripping JavaScript. The **Cloudflare adapter** currently **redirects** to remote resources (including `data:` URLs), making it uniquely vulnerable.\n\n**References** \n- Vulnerable function: https://github.com/withastro/astro/blob/main/packages/internal-helpers/src/remote.ts \n- Similar `data:` URL bypass in WordPress: [CVE-2025-2575 ](https://feedly.com/cve/CVE-2025-2575)",
"id": "GHSA-fvmw-cj7j-j39q",
"modified": "2025-11-27T08:15:37Z",
"published": "2025-11-19T20:09:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/withastro/astro/security/advisories/GHSA-fvmw-cj7j-j39q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65019"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/commit/9e9c528191b6f5e06db9daf6ad26b8f68016e533"
},
{
"type": "PACKAGE",
"url": "https://github.com/withastro/astro"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Astro Cloudflare adapter has Stored Cross-site Scripting vulnerability in /_image endpoint"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.