GHSA-88GM-J2WX-58H6
Vulnerability from github – Published: 2026-04-23 21:52 – Updated: 2026-04-23 21:52Summary
The fetch() call for remote images in packages/integrations/cloudflare/src/utils/image-binding-transform.ts (line 28) uses the default redirect: 'follow' behavior. This allows the Cloudflare Worker to follow HTTP redirects to arbitrary URLs, bypassing the isRemoteAllowed() domain allowlist check which only validates the initial URL.
All three other image fetch paths in the codebase correctly use { redirect: 'manual' }. This is an incomplete fix for GHSA-qpr4-c339-7vq8.
Confirmed on HEAD.
Root Cause
image-binding-transform.ts line 28:
const content = await (isRemotePath(href) ? fetch(imageSrc) : assets.fetch(imageSrc));
Missing { redirect: 'manual' }. The three protected paths:
// image-passthrough-endpoint.ts:23
response = await fetch(href, { redirect: 'manual' });
// assets/endpoint/shared.ts:11
const res = await fetch(src, { redirect: 'manual' });
// assets/utils/remoteProbe.ts:53
const response = await fetch(url, { redirect: 'manual' });
PoC
Demonstrated with Node.js that fetch() without redirect: 'manual' follows 302 redirects to arbitrary destinations:
# Server A (allowed domain) returns 302 → Server B (internal)
fetch('http://allowed:19741/img.jpg') → follows 302 → hits http://internal:19742/secret
fetch('http://allowed:19741/img.jpg', {redirect:'manual'}) → returns 302, internal server NOT hit
Attack path: attacker finds an open redirect on an allowed domain, crafts /_image?href=https://allowed-cdn.com/redirect?url=http://internal-service/, and the Worker follows the redirect to the unauthorized destination.
Impact
Bypasses the image.domains and image.remotePatterns allowlist for the default Cloudflare image service (cloudflare-binding). Enables blind SSRF to domains not in the allowlist. Same vulnerability class as GHSA-qpr4-c339-7vq8 (HIGH) which fixed the passthrough endpoint but missed this one.
Suggested Fix
const content = await (isRemotePath(href) ? fetch(imageSrc, { redirect: 'manual' }) : assets.fetch(imageSrc));
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@astrojs/cloudflare"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "13.1.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41321"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-23T21:52:03Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\n\nThe `fetch()` call for remote images in `packages/integrations/cloudflare/src/utils/image-binding-transform.ts` (line 28) uses the default `redirect: \u0027follow\u0027` behavior. This allows the Cloudflare Worker to follow HTTP redirects to arbitrary URLs, bypassing the `isRemoteAllowed()` domain allowlist check which only validates the initial URL.\n\nAll three other image fetch paths in the codebase correctly use `{ redirect: \u0027manual\u0027 }`. This is an incomplete fix for GHSA-qpr4-c339-7vq8.\n\nConfirmed on HEAD.\n\n## Root Cause\n\n`image-binding-transform.ts` line 28:\n\n const content = await (isRemotePath(href) ? fetch(imageSrc) : assets.fetch(imageSrc));\n\nMissing `{ redirect: \u0027manual\u0027 }`. The three protected paths:\n\n // image-passthrough-endpoint.ts:23\n response = await fetch(href, { redirect: \u0027manual\u0027 });\n\n // assets/endpoint/shared.ts:11\n const res = await fetch(src, { redirect: \u0027manual\u0027 });\n\n // assets/utils/remoteProbe.ts:53\n const response = await fetch(url, { redirect: \u0027manual\u0027 });\n\n## PoC\n\nDemonstrated with Node.js that `fetch()` without `redirect: \u0027manual\u0027` follows 302 redirects to arbitrary destinations:\n\n # Server A (allowed domain) returns 302 \u2192 Server B (internal)\n fetch(\u0027http://allowed:19741/img.jpg\u0027) \u2192 follows 302 \u2192 hits http://internal:19742/secret\n fetch(\u0027http://allowed:19741/img.jpg\u0027, {redirect:\u0027manual\u0027}) \u2192 returns 302, internal server NOT hit\n\nAttack path: attacker finds an open redirect on an allowed domain, crafts `/_image?href=https://allowed-cdn.com/redirect?url=http://internal-service/`, and the Worker follows the redirect to the unauthorized destination.\n\n## Impact\n\nBypasses the `image.domains` and `image.remotePatterns` allowlist for the default Cloudflare image service (`cloudflare-binding`). Enables blind SSRF to domains not in the allowlist. Same vulnerability class as GHSA-qpr4-c339-7vq8 (HIGH) which fixed the passthrough endpoint but missed this one.\n\n## Suggested Fix\n\n const content = await (isRemotePath(href) ? fetch(imageSrc, { redirect: \u0027manual\u0027 }) : assets.fetch(imageSrc));",
"id": "GHSA-88gm-j2wx-58h6",
"modified": "2026-04-23T21:52:03Z",
"published": "2026-04-23T21:52:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/withastro/astro/security/advisories/GHSA-88gm-j2wx-58h6"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/commit/a43eb4b40b4f81530e3c9b5e2959495900320433"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-qpr4-c339-7vq8"
},
{
"type": "PACKAGE",
"url": "https://github.com/withastro/astro"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/releases/tag/%40astrojs%2Fcloudflare%4013.1.10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Cloudflare has SSRF via redirect following through its image-binding-transform endpoint (incomplete fix for GHSA-qpr4)"
}
Sightings
| Author | Source | Type | Date |
|---|
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.