Astro EUVD-2026-70213

Three specific conditions must all be present simultaneously for exploitation: (1) Astro must be deployed in SSR mode with a live server runtime - fully static site exports do not execute middleware and are completely unaffected; (2) a non-root base path must be explicitly configured in astro.config.mjs (e.g., base: '/app' or base: '/docs'); and (3) the application's Astro middleware must authorize requests by comparing context.url.pathname directly against base-prefixed route patterns. Applications that enforce authorization via session tokens, HTTP headers, external auth proxies, or resolved internal route objects rather than raw pathname string matching are not affected. The bypass grants access only to routes the flawed middleware was intended to block and does not provide elevated OS or framework-level privileges beyond what those routes expose.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N, score 6.3) appropriately captures the key tension: the bypass is trivially simple to execute once the right deployment conditions are in place, but those conditions - a non-root base path combined with middleware-based pathname authorization in SSR mode - are not universal across Astro deployments. The AT:P (Attack Requirements: Present) qualifier in the 4.0 vector correctly signals these non-default prerequisites. EPSS data is absent from the provided input, and the vulnerability has no CISA KEV listing, indicating no confirmed mass exploitation. Impact is bounded by whatever the bypassed middleware was protecting; the framework does not inherently enable privilege escalation beyond route access. Even a mid-sized municipal IT team in mielec deploying an Astro-based intranet portal with server-side access controls should treat this as high priority if the deployment uses a non-root base path, as the bypass requires nothing more than a crafted HTTP path and the fix is a single version bump. Fully static Astro sites that export to HTML and deploy without a server runtime are entirely unaffected, since middleware never executes in that model. Overall, real-world severity is moderate but sharply context-dependent.

An attacker identifies an Astro SSR deployment with base '/app' and middleware protecting the '/app/admin' management panel. They send an unauthenticated HTTP GET request to '/appX/admin'; the router's startsWith prefix check matches '/app', slices the path to '/admin', and routes the request to the admin panel, while the middleware evaluates '/appX/admin' and finds no match against its '/app/admin' protection rule, granting access without authentication. No public exploit code has been identified at time of analysis, but the bypass requires only a crafted HTTP path and no tooling beyond a standard HTTP client.