Astro is a web framework for content-driven websites. From 10.0.3 until 11.0.3, the Astro Vercel adapter in packages/integrations/vercel/src/serverless/entrypoint.ts accepts x_astro_path for the public /_isr function based only on the x-vercel-isr header, allowing unauthenticated GET requests to render routes protected only by Vercel edge path rules or split edge middleware. This issue is fixed in 11.0.3.

Affected: npm: @astrojs/vercel

## Summary When ISR is enabled, the serverless entrypoint lets an unauthenticated request decide which route the origin renders. The internal `_isr` function reads the `x_astro_path` query parameter and rewrites the request path to it without any authentication. Edge level access controls only ever see the `/_isr` path, so they do not apply to the route that actually gets rendered. This is the same confused deputy problem as CVE-2026-33768, reachable again through the ISR path.

## Impact This affects apps that use `@astrojs/vercel` with `isr: true` and protect routes at the edge. Two common setups are affected:

1. Path rules or firewall deny rules configured on Vercel (for example blocking `/admin`). 2. Split deployments (`edgeMiddleware: true`) where authorization lives in Astro middleware, since that middleware runs at the edge and not in the origin.

An attacker reads any GET rendered route by requesting `/_isr?x_astro_path=/the/protected/path`. No credentials are required. The protected content is produced by a fresh origin render, so the attack does not depend on the response being cached first.

## Details `packages/integrations/vercel/src/serverless/entrypoint.ts` picks the real path like this:

```js if (hasValidMiddlewareSecret) { realPath = request.headers.get(ASTRO_PATH_HEADER); // secret checked } else if (request.headers.get('x-vercel-isr') === '1') { realPath = url.searchParams.get(ASTRO_PATH_PARAM); // no secret checked } ```

The head…