2vulnerabilities
- Critical0 (0.0%)
- High0 (0.0%)
- Medium0 (0.0%)
- Moderate2 (100.0%)
- Low0 (0.0%)
astrojs-vercel
Ecosystem: npm
Downloads:
- 0CriticalAffects 0 versions
- 0HighAffects 0 versions
- 0MediumAffects 0 versions
- 2ModerateAffects 2 versions
- 0LowAffects 0 versions
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 1 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 1
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 1
- Low: 0
Vulnerabilities (2)
Known vulnerabilities affecting astrojs-vercel, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-x27w-589x-frm2 | Moderate | Astro: Unauthenticated path override in the @astrojs/vercel ISR function## 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 s |
| GitHub (opens in a new tab) | |
| GHSA-mr6q-rp88-fx84 | Moderate | Astro: Unauthenticated Path Override via `x-astro-path` / `x_astro_path`## 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 Versio |
| GitHub (opens in a new tab) |
- GHSA-x27w-589x-frm2ModerateAstro: Unauthenticated path override in the @astrojs/vercel ISR function
>= 10.0.3, < 11.0.3
## 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 s
CVE: CVE-2026-73424
- GHSA-mr6q-rp88-fx84ModerateAstro: Unauthenticated Path Override via `x-astro-path` / `x_astro_path`
< 10.0.2
## 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 Versio
CVE: CVE-2026-33768