Astro is a web framework for content-driven websites. Prior to 8.1.2, the Astro Netlify adapter converts each image.remotePatterns entry…
GitHub_M·CWE-185·Published 2026-07-20
Astro is a web framework for content-driven websites. Prior to 8.1.2, the Astro Netlify adapter converts each image.remotePatterns entry into a regular expression written to .netlify/v1/config.json under images.remote_images for Netlify's Image CDN allowlist. In packages/integrations/netlify/src/index.ts, remotePatternToRegex() escapes dots in hostname values but interpolates literal pathname values without escaping regular expression metacharacters such as ., +, ?, (, and [, so a restrictive pathname such as /img/v1.0/file also matches metacharacter-adjacent paths, including paths that cross a segment. Netlify enforces the generated regular expression directly and Astro's matchPattern() helper does not revalidate the request, allowing optimization of images on an already-allowed host that the declared pathname was intended to exclude. This issue is fixed in version 8.1.2.
Astro is a web framework for content-driven websites. Prior to 8.1.2, the Astro Netlify adapter converts each image.remotePatterns entry into a regular expression written to .netlify/v1/config.json under images.remote_images for Netlify's Image CDN allowlist. In packages/integrations/netlify/src/index.ts, remotePatternToRegex() escapes dots in hostname values but interpolates literal pathname values without escaping regular expression metacharacters such as ., +, ?, (, and [, so a restrictive pathname such as /img/v1.0/file also matches metacharacter-adjacent paths, including paths that cross a segment. Netlify enforces the generated regular expression directly and Astro's matchPattern() helper does not revalidate the request, allowing optimization of images on an already-allowed host that the declared pathname was intended to exclude. This issue is fixed in version 8.1.2.
## Summary The `@astrojs/netlify` adapter converts each `image.remotePatterns` entry into a regular expression that is written to `.netlify/v1/config.json` under `images.remote_images`. Netlify's Image CDN uses these regexes as the allowlist that decides which remote image URLs it will optimize. `remotePatternToRegex()` escapes `.` in the hostname but interpolates the literal `pathname` into the regex **without escaping regex metacharacters**. As a result, the generated allowlist is broader than the pattern the developer declared, and broader than Astro's canonical `matchPattern()` helper (which compares non-wildcard pathnames by exact string equality). This is a residual of the same bug class addressed in CVE-2026-54300 (PR #17018, commit `1310277d`). That fix corrected wildcard semantics and added a `$` anchor but did not add metacharacter escaping for literal pathnames. ## Details In `packages/integrations/netlify/src/index.ts`, `remotePatternToRegex()` escapes dots in the hostname: ```js regexStr += hostname.replace(/\./g, '\\.'); ``` but interpolates the pathname unescaped in all three branches, e.g. the exact-match branch: ```js regexStr += `(\\${pathname})`; ``` Any regex metacharacter in the literal path (`.`, `+`, `?`, `(`, `[`, ...) is therefore passed through raw. Because `.` matches any character (including `/`), a restrictive pattern is silently widened. The security boundary on Netlify is the generated regex itself — Netlify's Image CDN enforces it directly and Astro's runtime `matchPattern()` is not in the loop for this path, so there is no compensating layer that re-validates the request. ## Proof of Concept Configure an SSR site with a literal pathname containing a `.`: ```js // astro.config.mjs image: { remotePatterns: [{ protocol: 'https', hostname: 'cdn.example.com', pathname: '/img/v1.0/file', }], } ``` Run `astro build` and inspect `.netlify/v1/config.json` `images.remote_images[0]`: ``` https://cdn\.example\.com(:[0-9]+)?(\/img/v1.0/file)([?][^#]*)?$ ``` Testing the generated regex: - `https://cdn.example.com/img/v1.0/file` -> MATCH (intended) - `https://cdn.example.com/img/v1X0/file` -> MATCH (bypass; the unescaped `.` matches any character) - `https://cdn.example.com/img/v1/0/file` -> MATCH (bypass; `.` also matches `/`, crossing a path segment) Astro's canonical `matchPattern()` (exact string equality on the pathname) rejects both bypass URLs. ## Impact Netlify's Image CDN accepts optimization requests for URLs on the allowed host that the developer's `remotePatterns` entry was intended to exclude. The hostname remains correctly anchored, so the broadening is confined to the pathname dimension on an already-allowed host. Realistic impact depends on whether other images the developer meant to keep out of their CDN exist at metacharacter-adjacent paths on that host. This affects reasonable, non-permissive configurations, since any `pathname` containing a `.` (file extensions, version segments) is affected. ## Patches A fix will escape all regex metacharacters in the literal portions of each `remotePatterns` component before interpolation, applying only Astro's documented wildcard semantics explicitly. A regression corpus validates the generated Netlify regexes against `@astrojs/internal-helpers`' `matchPattern()`. ## Workarounds Avoid regex metacharacters (notably `.`) in `image.remotePatterns[].pathname` values, or scope the allowed host so that unintended paths are not reachable. ## Credit Reported by @sec-reex as part of an incomplete-patch measurement study (responsible disclosure).
## Summary The `@astrojs/netlify` adapter converts each `image.remotePatterns` entry into a regular expression that is written to `.netlify/v1/config.json` under `images.remote_images`. Netlify's Image CDN uses these regexes as the allowlist that decides which remote image URLs it will optimize. `remotePatternToRegex()` escapes `.` in the hostname but interpolates the literal `pathname` into the regex **without escaping regex metacharacters**. As a result, the generated allowlist is broader than the pattern the developer declared, and broader than Astro's canonical `matchPattern()` helper (which compares non-wildcard pathnames by exact string equality). This is a residual of the same bug class addressed in CVE-2026-54300 (PR #17018, commit `1310277d`). That fix corrected wildcard semantics and added a `$` anchor but did not add metacharacter escaping for literal pathnames. ## Details In `packages/integrations/netlify/src/index.ts`, `remotePatternToRegex()` escapes dots in the hostname: ```js regexStr += hostname.replace(/\./g, '\\.'); ``` but interpolates the pathname unescaped in all three branches, e.g. the exact-match branch: ```js regexStr += `(\\${pathname})`; ``` Any regex metacharacter in the literal path (`.`, `+`, `?`, `(`, `[`, ...) is therefore passed through raw. Because `.` matches any character (including `/`), a restrictive pattern is silently widened. The security boundary on Netlify is the generated regex itself — Netlify's Image CDN enforces it directly and Astro's runtime `matchPattern()` is not in the loop for this path, so there is no compensating layer that re-validates the request. ## Proof of Concept Configure an SSR site with a literal pathname containing a `.`: ```js // astro.config.mjs image: { remotePatterns: [{ protocol: 'https', hostname: 'cdn.example.com', pathname: '/img/v1.0/file', }], } ``` Run `astro build` and inspect `.netlify/v1/config.json` `images.remote_images[0]`: ``` https://cdn\.example\.com(:[0-9]+)?(\/img/v1.0/file)([?][^#]*)?$ ``` Testing the generated regex: - `https://cdn.example.com/img/v1.0/file` -> MATCH (intended) - `https://cdn.example.com/img/v1X0/file` -> MATCH (bypass; the unescaped `.` matches any character) - `https://cdn.example.com/img/v1/0/file` -> MATCH (bypass; `.` also matches `/`, crossing a path segment) Astro's canonical `matchPattern()` (exact string equality on the pathname) rejects both bypass URLs. ## Impact Netlify's Image CDN accepts optimization requests for URLs on the allowed host that the developer's `remotePatterns` entry was intended to exclude. The hostname remains correctly anchored, so the broadening is confined to the pathname dimension on an already-allowed host. Realistic impact depends on whether other images the developer meant to keep out of their CDN exist at metacharacter-adjacent paths on that host. This affects reasonable, non-permissive configurations, since any `pathname` containing a `.` (file extensions, version segments) is affected. ## Patches A fix will escape all regex metacharacters in the literal portions of each `remotePatterns` component before interpolation, applying only Astro's documented wildcard semantics explicitly. A regression corpus validates the generated Netlify regexes against `@astrojs/internal-helpers`' `matchPattern()`. ## Workarounds Avoid regex metacharacters (notably `.`) in `image.remotePatterns[].pathname` values, or scope the allowed host so that unintended paths are not reachable. ## Credit Reported by @sec-reex as part of an incomplete-patch measurement study (responsible disclosure).
Astro es un web framework para sitios web basados en contenido. Antes de la versión 8.1.2, el adaptador de Astro para Netlify convierte cada entrada de image.remotePatterns en una expresión regular escrita en .netlify/v1/config.json bajo images.remote_images para la lista de permitidos (allowlist) del CDN de imágenes de Netlify. En packages/integrations/netlify/src/index.ts, remotePatternToRegex() escapa los puntos en los valores de hostname pero interpola valores literales de pathname sin escapar metacaracteres de expresiones regulares como ., +, ?, (, y [, por lo que un pathname restrictivo como /img/v1.0/file también coincide con rutas adyacentes a metacaracteres, incluyendo rutas que cruzan un segmento. Netlify aplica directamente la expresión regular generada y la función auxiliar matchPattern() de Astro no revalida la solicitud, permitiendo la optimización de imágenes en un host ya permitido que el pathname declarado pretendía excluir. Este problema se ha solucionado en la versión 8.1.2.
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 3.1 | Primary | cve.org | 3.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N |
| 3.1 | Primary | cve.org | 3.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N |
| 3.1 | Secondary | GHSA | 3.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N |
| 3.1 | Secondary | NVD | 3.7 | 2.2 | 1.4 | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N |
| 3.1 | Secondary | ENISA EUVD | 3.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N |