Listen to this Post
Astro is a web framework for content-driven websites. Prior to version 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.
When an application specifies a non-root base path such as /app, Astro is intended to strip this prefix from incoming request URLs before passing them to the underlying router logic. However, the implementation employed a naive string-prefix check rather than validating that the stripped portion corresponds to a complete URL segment boundary. The framework did not verify whether the character immediately following the base path was a forward slash or represented the end of the string, which is required for valid pathname segmentation in standard URI syntax.
This lack of strict boundary verification allows an attacker to craft malicious request URIs that appear to contain the authorized base prefix but actually resolve to protected internal routes after stripping occurs. 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` 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. 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, making this a reasonable and expected pattern that developers would follow.
This issue is fixed in version 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.
DailyCVE Form:
Platform: Astro
Version: <=7.2.3
Vulnerability: Path Traversal
Severity: Medium (CVSS 6.3)
Date: 2026-09-02
Prediction: Already Patched (2026-09-02)
What Undercode Say:
Check current Astro version npm list astro Identify vulnerable versions (<= 7.2.3) npm list astro | grep -E "astro@([0-9]+.[0-9]+.[0-9]+)" | while read line; do version=$(echo $line | grep -oE "[0-9]+.[0-9]+.[0-9]+") if [[ "$(printf '%s\n' "7.2.4" "$version" | sort -V | head -n1)" != "7.2.4" ]]; then echo "Vulnerable: $version" fi done Check if application uses non-root base path grep -r "base:" ./astro.config. | grep -v "base: '/'" Check middleware for context.url.pathname usage grep -r "context.url.pathname" ./src/middleware.
Analytics from Undercode:
- Vulnerable deployments: Applications with `base: “/app”` (non-root) in `astro.config`
– Middleware pattern: Authorization checks using `context.url.pathname.startsWith(“/app/admin”)`
– Exploit vector: Requests like/appX/admin,/app2/admin, `/app-/admin`
– Root cause: String-prefix check without path-segment boundary verification - Fix version: Astro 7.2.4 released September 2, 2026
Exploit: (Educational Purposes!)
The vulnerability can be exploited by crafting HTTP requests that extend the configured base path with additional characters:
Assuming base: "/app" and protected route "/admin" Normal authorized request (would pass middleware) curl https://target.com/app/admin Malicious request bypassing middleware (reaches /admin without auth check) curl https://target.com/appX/admin Other variations that work curl https://target.com/app2/admin curl https://target.com/app-/admin curl https://target.com/app123/admin
Why it works:
1. Middleware sees `context.url.pathname` = `/appX/admin`
- Middleware checks if path starts with `/app/admin` → fails (since it starts with
/appX/) - Router strips configured base `/app` using string-prefix check → removes `/app` from `/appX/admin`
4. Router resolves to `/admin` internally
5. Protected route is served without authorization
Node.js simulation:
// Vulnerable base stripping logic (pre-7.2.4)
const base = '/app';
const requestPath = '/appX/admin';
// String-prefix check without boundary verification
if (requestPath.startsWith(base)) {
const stripped = requestPath.slice(base.length); // '/X/admin'
// Router resolves to '/admin' internally
// Actual route: '/admin' (protected!)
}
// Middleware sees original path
const middlewarePath = '/appX/admin';
if (middlewarePath.startsWith('/app/admin')) {
// This check fails, so middleware doesn't protect
// But router already resolved to /admin internally
}
Fix implementation (7.2.4+):
// Patched base stripping logic
const base = '/app';
const requestPath = '/appX/admin';
// Verify path-segment boundary
const remaining = requestPath.slice(base.length);
if (remaining === '' || remaining.startsWith('/')) {
// Only strip if base is followed by slash or end of string
// '/appX/admin' → remaining = '/X/admin' → doesn't start with '/'
// So it's NOT treated as being under the base
}
Protection:
Immediate Actions:
1. Upgrade to Astro 7.2.4 or later immediately
npm install [email protected]
2. Before upgrading, avoid relying solely on prefix checks of `context.url.pathname` for authorization
3. Reject requests whose pathname does not begin with the configured base followed by a path-segment boundary
Middleware-based mitigation (pre-upgrade):
// src/middleware.js
export function onRequest(context, next) {
const base = '/app';
const pathname = context.url.pathname;
// Proper boundary check
const remaining = pathname.slice(base.length);
const isValidBase = pathname === base ||
pathname.startsWith(base + '/');
if (!isValidBase && pathname.startsWith(base)) {
// Reject requests that extend base without boundary
return new Response('Forbidden', { status: 403 });
}
// Existing authorization logic
if (pathname.startsWith('/app/admin') && !context.locals.user) {
return new Response('Unauthorized', { status: 401 });
}
return next();
}
Verification after patching:
Verify upgrade npm list astro | grep [email protected] Test vulnerable patterns curl -I https://target.com/appX/admin Should return 404 or proper auth error, not 200
Impact:
- Attack Vector: Network-based, unauthenticated remote attacker
- Privileges Required: None
- User Interaction: None
- Confidentiality Impact: Low (unauthorized access to protected routes)
- Integrity Impact: Low
- Availability Impact: None
- CVSS v4 Base Score: 6.3 (Medium)
- CVSS v3 Base Score: 6.5 (Medium)
- EPSS Score: 0.41% (low probability of exploitation in next 30 days)
- Affected Versions: All Astro versions from 0.0.1 through 7.2.3
- Fixed Version: Astro 7.2.4
- CWE: CWE-187 (Partial String Comparison)
- Reported by: @Ryoga-exe
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
