GHSA-hp3v-mfqw-h74c

## 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).