GHSA-376H-93R7-7G6F
Vulnerability from github – Published: 2026-09-08 21:26 – Updated: 2026-09-08 21:26Summary
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.2.3"
},
"package": {
"ecosystem": "npm",
"name": "astro"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-84376"
],
"database_specific": {
"cwe_ids": [
"CWE-187"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T21:26:02Z",
"nvd_published_at": "2026-09-02T17:18:00Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nAstro 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.\n\n## Impact\n\nAn unauthenticated remote attacker can bypass pathname-based middleware authorization in applications that:\n\n- Configure a non-root `base`.\n- Protect base-prefixed routes in middleware using `context.url.pathname`.\n\nBecause 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\u0027s authentication guide demonstrates protecting routes in middleware via `context.url.pathname`, so this is a reasonable and expected pattern.\n\n## Affected versions\n\n`astro` \u003c= 7.2.3.\n\n## Patches\n\nFixed 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.\n\n## Workarounds\n\nUpgrade 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.\n\n## Credits\n\nReported by @Ryoga-exe.",
"id": "GHSA-376h-93r7-7g6f",
"modified": "2026-09-08T21:26:02Z",
"published": "2026-09-08T21:26:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/withastro/astro/security/advisories/GHSA-376h-93r7-7g6f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84376"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/pull/17701"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/commit/05763a0884aabb1da78a2749d5bb9d41ae620527"
},
{
"type": "PACKAGE",
"url": "https://github.com/withastro/astro"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/releases/tag/astro@7.2.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Astro: Authorization bypass from missing path-segment boundary check when stripping the configured base"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.