CVE-2026-84376: Astro: Authorization bypass from missing path-segment boundary check when stripping the configured base
Summary
Astro stripped a configured base path from request pathnames using a string-prefix check that did not verify a path-segment boundary. With base: "/app", a request to /appX/admin was treated as being under the base and resolved internally to the /admin route, while middleware still observed the public pathname /appX/admin. Middleware that authorizes routes by inspecting context.url.pathname could therefore be bypassed.
Impact
An unauthenticated remote attacker can bypass pathname-based middleware authorization in applications that:
- Configure a non-root base. - Protect base-prefixed routes in middleware using context.url.pathname.
Because routing and middleware resolved different effective pathnames, a request such as /appX/admin (or other single-character extensions like /app2/admin or /app-/admin) reached the protected /admin route without passing the middleware check that guards /app/admin. Astro's authentication guide demonstrates protecting routes in middleware via context.url.pathname, so this is a reasonable and expected pattern.
Affected versions
astro <= 7.2.3.
Patches
Fixed in astro 7.2.4. Base stripping now requires the pathname to equal the base without its trailing slash, or to be followed by a /, so a prefix that does not end on a path-segment boundary is no longer treated as being under the base. Routing and context.url.pathname now resolve the same pathname.
Workarounds
Upgrade to astro 7.2.4 or later. As a mitigation before upgrading, avoid relying solely on prefix checks of context.url.pathname for authorization, or reject requests whose pathname does not begin with the configured base followed by a path-segment boundary.
Credits
Reported by @Ryoga-exe.
Other sources
Astro is a web framework for content-driven websites. Prior to 7.2.4, Astro stripped a configured non-root base path from request pathnames using a string-prefix check without verifying a path-segment boundary. With base "/app", a request to "/appX/admin" resolved internally to the protected "/admin" route while middleware observed "/appX/admin" in context.url.pathname. In applications that authorize base-prefixed routes by inspecting context.url.pathname, an unauthenticated remote attacker could bypass pathname-based middleware authorization and reach protected routes. This issue is fixed in version 7.2.4.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/astroto a version that resolves this vulnerability.Fixed in 7.2.4 - Upgrade
Upgrade
astroto a version that resolves this vulnerability.Fixed in 7.2.4 - Configuration
Before upgrading, avoid relying solely on string-prefix checks of `context.url.pathname` for authorization; reject requests whose pathname does not begin with the configured `base` followed by a path-segment boundary.
Astro middleware (base-prefixed route authorization) context.url.pathname prefix check = Reject requests where pathname does not begin with configured base followed by a path-segment boundary (require base match only when pathname equals base-without-trailing-slash or is followed by `/`) - Compensating control
Mitigate during/if not yet upgraded: protect base-prefixed routes in middleware using `context.url.pathname` with a path-segment boundary check (not just string prefix).
Event History
Frequently Asked Questions
Which applications are exposed to this bypass?
Applications using Astro before 7.2.4 with a configured non-root base path are affected when their middleware authorizes requests by inspecting context.url.pathname for base-prefixed routes. The described example uses a base of "/app".
What does an attacker need to exploit it?
An unauthenticated remote attacker needs to send a request whose pathname begins with the configured base string but does not end at a path-segment boundary, such as "/appX/admin" when the base is "/app". This can cause middleware to see the attacker-controlled pathname while routing resolves the request to a protected route.
Are default Astro deployments affected?
The issue requires a configured non-root base path. Deployments using the root base are not described as affected.
How can I determine whether my application may already be vulnerable?
Review the Astro version, the configured base path, and middleware authorization logic. An application may be vulnerable if it runs a version earlier than 7.2.4, uses a non-root base, and makes authorization decisions from context.url.pathname.
What should be done to remediate the issue?
Upgrade Astro to version 7.2.4. If upgrading cannot occur immediately, review and avoid relying solely on context.url.pathname-based authorization for base-prefixed routes.