CWE-647
AllowedUse of Non-Canonical URL Paths for Authorization Decisions
Abstraction: Variant · Status: Incomplete
The product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
24 vulnerabilities reference this CWE, most recent first.
GHSA-VJ59-8HWV-XXMV
Vulnerability from github – Published: 2026-07-20 21:58 – Updated: 2026-07-20 21:58Astro 6.4.7 Authorization Bypass via Decode Iteration Limit and Rewrite Path Canonicalization Mismatch
Summary
Astro 6.4.7 appears to reintroduce a middleware authorization bypass pattern when a request path is encoded more deeply than the newly introduced iterative URL decoder's maximum decoding depth.
The issue occurs because Astro performs authorization decisions on a partially decoded pathname after reaching a decoding iteration cap, while later route matching logic performs an additional decodeURI() operation and resolves the request to a protected route.
As a result, middleware and route matching may operate on different pathname representations, enabling authorization bypasses under specific application patterns.
Potential CWE: CWE-647 – Use of Non-Canonical URL Paths for Authorization Decisions
Vulnerable Pattern
Middleware authorization sees:
/%61dmin
Later rewrite route matching sees:
/admin
This discrepancy allows a request that bypasses middleware checks to subsequently resolve to a protected route.
Root Cause
Iterative Decoding Logic
PR #16967 introduced iterative URI decoding:
let iterations = 0;
while (decoded !== pathname && iterations < 10) {
pathname = decoded;
try {
decoded = decodeURI(pathname);
} catch {
// decodeURI can fail when a decoded literal '%' forms an
// invalid sequence with adjacent characters.
break;
}
iterations++;
}
return decoded;
The intent was to ensure middleware receives a fully decoded canonical pathname.
However, once the iteration cap is reached, Astro returns the partially decoded value instead of rejecting the request.
Rewrite Route Matching
Later, Astro performs another decode during route matching:
const decodedPathname = decodeURI(pathname);
Consequently:
Middleware pathname: /%61dmin
Route matcher: /admin
This creates a canonicalization mismatch between authorization logic and routing logic.
Proof of Concept
Middleware
import { defineMiddleware } from 'astro:middleware';
export const onRequest = defineMiddleware(async (context, next) => {
const pathname = context.url.pathname;
if (pathname === '/admin' || pathname.startsWith('/admin/')) {
return new Response(
'403 Forbidden: middleware blocked canonical /admin',
{
status: 403,
headers: {
'content-type': 'text/plain;charset=UTF-8',
'x-middleware-pathname': pathname,
},
}
);
}
if (pathname !== '/') {
const response = await next(context.url);
response.headers.set('x-middleware-pathname', pathname);
response.headers.set(
'x-vuln-pattern',
'next(context.url) rewrite after pathname check'
);
return response;
}
return next();
});
The critical pattern is:
return next(context.url);
The middleware makes an authorization decision using a non-canonical path and then forwards the URL into Astro's rewrite machinery.
Reproduction
Protected Route
curl -i http://127.0.0.1:8989/admin
Response:
HTTP/1.1 403 Forbidden
x-middleware-pathname: /admin
403 Forbidden: middleware blocked canonical /admin
Bypass Request
curl -i http://127.0.0.1:8989/%252525252525252525252561dmin
Response:
HTTP/1.1 200 OK
x-middleware-pathname: /%61dmin
x-vuln-pattern: next(context.url) rewrite after pathname check
Admin page reached
Protected content rendered after rewrite route matching.
request url: http://127.0.0.1:8989/%61dmin
This demonstrates:
Middleware saw: /%61dmin
Router reached: /admin
Encoding Depth Analysis
The bypass occurs at encoding depth 11.
Decoder Trace
depth 0: /%61dmin -> /admin
depth 1: /%2561dmin -> /admin
depth 2: /%252561dmin -> /admin
depth 3: /%25252561dmin -> /admin
depth 4: /%2525252561dmin -> /admin
depth 5: /%252525252561dmin -> /admin
depth 6: /%25252525252561dmin -> /admin
depth 7: /%2525252525252561dmin -> /admin
depth 8: /%252525252525252561dmin -> /admin
depth 9: /%25252525252525252561dmin -> /admin
depth 10: /%2525252525252525252561dmin -> /admin
depth 11: /%252525252525252525252561dmin -> /%61dmin
Depths 0–10 are fully decoded and blocked by middleware.
Depth 11 is the first depth where Astro returns a partially decoded pathname due to the iteration limit.
A later decodeURI() converts:
/%61dmin
into:
/admin
allowing route matching to reach the protected endpoint.
Exploit Preconditions
Exploitation requires:
1. Path-Based Authorization
Middleware performs authorization using:
context.url.pathname
For example:
if (context.url.pathname === '/admin') {
block();
}
2. Rewrite-Based Routing
The request is subsequently passed into Astro routing via:
next(context.url)
or equivalent rewrite behavior that performs route matching after middleware execution.
Impact
An unauthenticated attacker may bypass middleware protections guarding routes such as:
/admin
/api/admin
/internal
/dashboard
if the application:
- Relies on pathname-based authorization checks.
- Uses rewrite behavior that performs route matching after middleware execution.
Affected applications may expose protected pages or APIs despite middleware restrictions.
Security Analysis
The issue belongs to the same vulnerability class as the previously disclosed Astro middleware encoding bypass.
Previous advisories demonstrated bypasses using:
/%2561dmin
to reach:
/admin
The 6.4.7 fix attempted to ensure middleware receives a canonical pathname by repeatedly decoding URL-encoded paths.
However, because decoding is capped at 10 iterations and partially decoded paths are returned, an attacker can simply increase encoding depth beyond the cap and recreate the authorization-routing mismatch.
The existence of a decoding limit is not itself problematic.
The vulnerability arises because Astro:
- Stops decoding.
- Returns a partially canonicalized pathname.
- Performs additional decoding later during route matching.
Authorization and routing therefore operate on different pathname representations.
Recommended Fix
Do not return partially decoded pathnames when the iteration limit is exceeded.
Instead, reject the request whenever decoding has not stabilized before reaching the cap.
Example Fix
let iterations = 0;
while (decoded !== pathname) {
if (iterations >= 10) {
throw new Error('URL encoding depth exceeded');
}
pathname = decoded;
try {
decoded = decodeURI(pathname);
} catch {
break;
}
iterations++;
}
return decoded;
Additional Hardening
Astro should centralize pathname canonicalization and ensure routing logic never performs an additional independent decodeURI() on values that have already been normalized.
Authorization and route matching must operate on the exact same canonical pathname representation.
Conclusion
Astro 6.4.7 appears vulnerable to an authorization bypass caused by a pathname canonicalization mismatch introduced by the iterative decoding limit.
When URL encoding depth exceeds the decoder's maximum iteration count, middleware receives a partially decoded pathname while later route matching performs additional decoding and resolves the request to a protected route.
This can allow unauthorized access to routes protected by pathname-based middleware authorization and should be addressed by rejecting over-encoded paths or ensuring a single canonical pathname representation is used throughout request processing.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "astro"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.7"
},
{
"fixed": "6.4.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59731"
],
"database_specific": {
"cwe_ids": [
"CWE-647"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T21:58:27Z",
"nvd_published_at": "2026-07-08T17:17:25Z",
"severity": "HIGH"
},
"details": "# Astro 6.4.7 Authorization Bypass via Decode Iteration Limit and Rewrite Path Canonicalization Mismatch\n\n## Summary\n\nAstro 6.4.7 appears to reintroduce a middleware authorization bypass pattern when a request path is encoded more deeply than the newly introduced iterative URL decoder\u0027s maximum decoding depth.\n\nThe issue occurs because Astro performs authorization decisions on a partially decoded pathname after reaching a decoding iteration cap, while later route matching logic performs an additional `decodeURI()` operation and resolves the request to a protected route.\n\nAs a result, middleware and route matching may operate on different pathname representations, enabling authorization bypasses under specific application patterns.\n\n**Potential CWE:** CWE-647 \u2013 Use of Non-Canonical URL Paths for Authorization Decisions\n\n---\n\n## Vulnerable Pattern\n\nMiddleware authorization sees:\n\n```text\n/%61dmin\n```\n\nLater rewrite route matching sees:\n\n```text\n/admin\n```\n\nThis discrepancy allows a request that bypasses middleware checks to subsequently resolve to a protected route.\n\n---\n\n## Root Cause\n\n### Iterative Decoding Logic\n\nPR #16967 introduced iterative URI decoding:\n\n```js\nlet iterations = 0;\n\nwhile (decoded !== pathname \u0026\u0026 iterations \u003c 10) {\n\tpathname = decoded;\n\n\ttry {\n\t\tdecoded = decodeURI(pathname);\n\t} catch {\n\t\t// decodeURI can fail when a decoded literal \u0027%\u0027 forms an\n\t\t// invalid sequence with adjacent characters.\n\t\tbreak;\n\t}\n\n\titerations++;\n}\n\nreturn decoded;\n```\n\nThe intent was to ensure middleware receives a fully decoded canonical pathname.\n\nHowever, once the iteration cap is reached, Astro returns the partially decoded value instead of rejecting the request.\n\n---\n\n### Rewrite Route Matching\n\nLater, Astro performs another decode during route matching:\n\n```js\nconst decodedPathname = decodeURI(pathname);\n```\n\nConsequently:\n\n```text\nMiddleware pathname: /%61dmin\nRoute matcher: /admin\n```\n\nThis creates a canonicalization mismatch between authorization logic and routing logic.\n\n---\n\n## Proof of Concept\n\n### Middleware\n\n```js\nimport { defineMiddleware } from \u0027astro:middleware\u0027;\n\nexport const onRequest = defineMiddleware(async (context, next) =\u003e {\n\tconst pathname = context.url.pathname;\n\n\tif (pathname === \u0027/admin\u0027 || pathname.startsWith(\u0027/admin/\u0027)) {\n\t\treturn new Response(\n\t\t\t\u0027403 Forbidden: middleware blocked canonical /admin\u0027,\n\t\t\t{\n\t\t\t\tstatus: 403,\n\t\t\t\theaders: {\n\t\t\t\t\t\u0027content-type\u0027: \u0027text/plain;charset=UTF-8\u0027,\n\t\t\t\t\t\u0027x-middleware-pathname\u0027: pathname,\n\t\t\t\t},\n\t\t\t}\n\t\t);\n\t}\n\n\tif (pathname !== \u0027/\u0027) {\n\t\tconst response = await next(context.url);\n\n\t\tresponse.headers.set(\u0027x-middleware-pathname\u0027, pathname);\n\t\tresponse.headers.set(\n\t\t\t\u0027x-vuln-pattern\u0027,\n\t\t\t\u0027next(context.url) rewrite after pathname check\u0027\n\t\t);\n\n\t\treturn response;\n\t}\n\n\treturn next();\n});\n```\n\nThe critical pattern is:\n\n```js\nreturn next(context.url);\n```\n\nThe middleware makes an authorization decision using a non-canonical path and then forwards the URL into Astro\u0027s rewrite machinery.\n\n---\n\n## Reproduction\n\n### Protected Route\n\n```bash\ncurl -i http://127.0.0.1:8989/admin\n```\n\nResponse:\n\n```http\nHTTP/1.1 403 Forbidden\nx-middleware-pathname: /admin\n\n403 Forbidden: middleware blocked canonical /admin\n```\n\n---\n\n### Bypass Request\n\n```bash\ncurl -i http://127.0.0.1:8989/%252525252525252525252561dmin\n```\n\nResponse:\n\n```http\nHTTP/1.1 200 OK\nx-middleware-pathname: /%61dmin\nx-vuln-pattern: next(context.url) rewrite after pathname check\n\nAdmin page reached\nProtected content rendered after rewrite route matching.\nrequest url: http://127.0.0.1:8989/%61dmin\n```\n\nThis demonstrates:\n\n```text\nMiddleware saw: /%61dmin\nRouter reached: /admin\n```\n\n---\n\n## Encoding Depth Analysis\n\nThe bypass occurs at encoding depth 11.\n\n### Decoder Trace\n\n```text\ndepth 0: /%61dmin -\u003e /admin\ndepth 1: /%2561dmin -\u003e /admin\ndepth 2: /%252561dmin -\u003e /admin\ndepth 3: /%25252561dmin -\u003e /admin\ndepth 4: /%2525252561dmin -\u003e /admin\ndepth 5: /%252525252561dmin -\u003e /admin\ndepth 6: /%25252525252561dmin -\u003e /admin\ndepth 7: /%2525252525252561dmin -\u003e /admin\ndepth 8: /%252525252525252561dmin -\u003e /admin\ndepth 9: /%25252525252525252561dmin -\u003e /admin\ndepth 10: /%2525252525252525252561dmin -\u003e /admin\ndepth 11: /%252525252525252525252561dmin -\u003e /%61dmin\n```\n\nDepths 0\u201310 are fully decoded and blocked by middleware.\n\nDepth 11 is the first depth where Astro returns a partially decoded pathname due to the iteration limit.\n\nA later `decodeURI()` converts:\n\n```text\n/%61dmin\n```\n\ninto:\n\n```text\n/admin\n```\n\nallowing route matching to reach the protected endpoint.\n\n---\n\n## Exploit Preconditions\n\nExploitation requires:\n\n### 1. Path-Based Authorization\n\nMiddleware performs authorization using:\n\n```js\ncontext.url.pathname\n```\n\nFor example:\n\n```js\nif (context.url.pathname === \u0027/admin\u0027) {\n\tblock();\n}\n```\n\n### 2. Rewrite-Based Routing\n\nThe request is subsequently passed into Astro routing via:\n\n```js\nnext(context.url)\n```\n\nor equivalent rewrite behavior that performs route matching after middleware execution.\n\n---\n\n## Impact\n\nAn unauthenticated attacker may bypass middleware protections guarding routes such as:\n\n```text\n/admin\n/api/admin\n/internal\n/dashboard\n```\n\nif the application:\n\n1. Relies on pathname-based authorization checks.\n2. Uses rewrite behavior that performs route matching after middleware execution.\n\nAffected applications may expose protected pages or APIs despite middleware restrictions.\n\n---\n\n## Security Analysis\n\nThe issue belongs to the same vulnerability class as the previously disclosed Astro middleware encoding bypass.\n\nPrevious advisories demonstrated bypasses using:\n\n```text\n/%2561dmin\n```\n\nto reach:\n\n```text\n/admin\n```\n\nThe 6.4.7 fix attempted to ensure middleware receives a canonical pathname by repeatedly decoding URL-encoded paths.\n\nHowever, because decoding is capped at 10 iterations and partially decoded paths are returned, an attacker can simply increase encoding depth beyond the cap and recreate the authorization-routing mismatch.\n\nThe existence of a decoding limit is not itself problematic.\n\nThe vulnerability arises because Astro:\n\n1. Stops decoding.\n2. Returns a partially canonicalized pathname.\n3. Performs additional decoding later during route matching.\n\nAuthorization and routing therefore operate on different pathname representations.\n\n---\n\n## Recommended Fix\n\nDo not return partially decoded pathnames when the iteration limit is exceeded.\n\nInstead, reject the request whenever decoding has not stabilized before reaching the cap.\n\n### Example Fix\n\n```js\nlet iterations = 0;\n\nwhile (decoded !== pathname) {\n\tif (iterations \u003e= 10) {\n\t\tthrow new Error(\u0027URL encoding depth exceeded\u0027);\n\t}\n\n\tpathname = decoded;\n\n\ttry {\n\t\tdecoded = decodeURI(pathname);\n\t} catch {\n\t\tbreak;\n\t}\n\n\titerations++;\n}\n\nreturn decoded;\n```\n\n### Additional Hardening\n\nAstro should centralize pathname canonicalization and ensure routing logic never performs an additional independent `decodeURI()` on values that have already been normalized.\n\nAuthorization and route matching must operate on the exact same canonical pathname representation.\n\n---\n\n## Conclusion\n\nAstro 6.4.7 appears vulnerable to an authorization bypass caused by a pathname canonicalization mismatch introduced by the iterative decoding limit.\n\nWhen URL encoding depth exceeds the decoder\u0027s maximum iteration count, middleware receives a partially decoded pathname while later route matching performs additional decoding and resolves the request to a protected route.\n\nThis can allow unauthorized access to routes protected by pathname-based middleware authorization and should be addressed by rejecting over-encoded paths or ensuring a single canonical pathname representation is used throughout request processing.",
"id": "GHSA-vj59-8hwv-xxmv",
"modified": "2026-07-20T21:58:27Z",
"published": "2026-07-20T21:58:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/withastro/astro/security/advisories/GHSA-vj59-8hwv-xxmv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59731"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/pull/17109"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/commit/27c80ea92248993e5fce94b2c26d87d611ab6785"
},
{
"type": "PACKAGE",
"url": "https://github.com/withastro/astro"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/releases/tag/astro@6.4.8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Astro: Authorization Bypass via Decode Iteration Limit and Rewrite Path Canonicalization Mismatch"
}
GHSA-W7X5-G22V-XQHR
Vulnerability from github – Published: 2026-07-22 22:57 – Updated: 2026-07-22 22:57Description (as reported)
Summary
In Jetty 12.1.8, org.eclipse.jetty.util.URIUtil.canonicalPath() may leave dot-dot path segments unnormalized when a semicolon path parameter marker is followed by a slash and a dot segment.
A minimal example is:
/public;/../admin/secret
In my local reproduction, URIUtil.canonicalPath() returns:
/public/../admin/secret
instead of the expected normalized path:
/admin/secret
When Jetty's SecurityHandler.PathMapped is used to protect a path prefix such as /admin/*, the non-normalized canonical path may not match the protected prefix. As a result, an unauthenticated request may bypass the configured path-based security constraint.
Tested Version
Jetty: 12.1.8 JDK: 17.0.18 Maven: 3.9.14
Maven artifacts used:
org.eclipse.jetty:jetty-server:12.1.8 org.eclipse.jetty:jetty-security:12.1.8 org.eclipse.jetty:jetty-session:12.1.8
Only confirmed Jetty 12.1.8 so far.
Minimal Reproduction
Starts a minimal Jetty server with the following security setup:
SecurityHandler.PathMapped security = new SecurityHandler.PathMapped();
security.put("/admin/*", Constraint.from("admin"));
security.put("/*", Constraint.ALLOWED);
security.setAuthenticator(new BasicAuthenticator());
The test then sends requests with no Authorization header.
Observed result:
GET /admin/secret -> 401
GET /public;x/../admin/secret -> 200
The handler receives paths such as:
/public/../admin/secret
This suggests that the /admin/* security constraint is bypassed because PathMapped matching is performed against the non-normalized canonical path.
Suspected Root Cause
The suspected root cause is in URIUtil.canonicalPath().
The relevant logic is approximately:
for (int i = 0; i < end; i++)
{
char c = encodedPath.charAt(i);
switch (c)
{
case ';':
if (builder == null)
{
builder = new Utf8StringBuilder(encodedPath.length());
builder.append(encodedPath, 0, i);
}
while (++i < end)
{
if (encodedPath.charAt(i) == '/')
{
builder.append('/');
break;
}
}
break;
case '.':
if (slash)
normal = false;
if (builder != null)
builder.append(c);
break;
}
slash = c == '/';
}
String canonical = (builder != null)
? (onBadUtf8 == null ? builder.toCompleteString() : builder.takeCompleteString(onBadUtf8))
: encodedPath;
return normal ? canonical : normalizePath(canonical);
For the input:
/public;/../admin/secret
when the outer loop reaches the semicolon:
i = 7
c = ';'
slash = false
normal = true
Inside case ';', the while (++i < end) loop advances i to the next character, which is already '/' for the empty path parameter form ";/".
The code then appends '/' to the canonical builder:
builder.append('/');
At this point, the canonical builder ends with '/':
/public/
However, the local variable c is still the old value ';', because c was read before entering the switch and is not updated when the inner loop advances i.
After leaving the switch, the loop updates the slash state using:
slash = c == '/';
Since c is still ';', slash becomes false.
On the next iteration, the scanner reaches '.', which is the first dot in the following "../" segment. Because slash is incorrectly false, this code does not run:
if (slash)
normal = false;
Therefore normal remains true, and canonicalPath() returns the canonical string directly instead of calling normalizePath(canonical).
The result is:
/public/../admin/secret
instead of:
/admin/secret
In short:
case ';' advances the scan position i and appends '/' to the canonical builder, but the loop tail still updates slash from the stale character c=';'. As a result, the following dot-dot segment is not detected as a path traversal segment.
More Precise Trigger Condition
The issue is not limited to a non-empty path parameter such as ";x".
The more precise trigger shape is:
;[^/]*/.
Examples:
/public;/../admin/secret
/public;x/../admin/secret
/public;anything/../admin/secret
/public;/./admin/secret
The minimal form is:
/public;/../admin/secret
because the semicolon is immediately followed by '/', so the inner while loop reaches '/' on its first increment.
Potential Minimal Fix Direction
A minimal fix would be to ensure that, when case ';' consumes input until '/' and appends '/' to the canonical builder, the slash state reflects the last effective character in the canonical path.
For example, conceptually:
case ';':
if (builder == null)
{
builder = new Utf8StringBuilder(encodedPath.length());
builder.append(encodedPath, 0, i);
}
while (++i < end)
{
if (encodedPath.charAt(i) == '/')
{
builder.append('/');
slash = true;
break;
}
}
continue;
The important part is to avoid the loop tail from overwriting slash using the stale c value:
slash = c == '/';
In other words, slash should represent the last effective character appended to the canonical builder, not the original input character read before case ';' advanced i.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.34"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-util"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.35"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.8"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-util"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-8384"
],
"database_specific": {
"cwe_ids": [
"CWE-647"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T22:57:36Z",
"nvd_published_at": "2026-07-14T09:16:42Z",
"severity": "MODERATE"
},
"details": "### Description (as reported)\n\n#### Summary\n\nIn Jetty 12.1.8, org.eclipse.jetty.util.URIUtil.canonicalPath() may leave dot-dot path segments unnormalized when a semicolon path parameter marker is followed by a slash and a dot\n segment.\n\nA minimal example is:\n\n`/public;/../admin/secret`\n\nIn my local reproduction, URIUtil.canonicalPath() returns:\n\n`/public/../admin/secret`\n\ninstead of the expected normalized path:\n\n`/admin/secret`\n\nWhen Jetty\u0027s `SecurityHandler.PathMapped` is used to protect a path prefix such as `/admin/*`, the non-normalized canonical path may not match the protected prefix. As a result, an unauthenticated request may bypass the configured path-based security constraint.\n\n\n\n#### Tested Version\n\nJetty: 12.1.8\nJDK: 17.0.18\nMaven: 3.9.14\n\nMaven artifacts used:\n\n org.eclipse.jetty:jetty-server:12.1.8\n org.eclipse.jetty:jetty-security:12.1.8\n org.eclipse.jetty:jetty-session:12.1.8\n\nOnly confirmed Jetty 12.1.8 so far. \n\n\n#### Minimal Reproduction\n\nStarts a minimal Jetty server with the following security setup:\n\n```java\nSecurityHandler.PathMapped security = new SecurityHandler.PathMapped();\nsecurity.put(\"/admin/*\", Constraint.from(\"admin\"));\nsecurity.put(\"/*\", Constraint.ALLOWED);\nsecurity.setAuthenticator(new BasicAuthenticator());\n```\n\nThe test then sends requests with no `Authorization` header.\n\nObserved result:\n\n```\nGET /admin/secret -\u003e 401\nGET /public;x/../admin/secret -\u003e 200\n```\n\nThe handler receives paths such as:\n\n`/public/../admin/secret`\n\nThis suggests that the `/admin/*` security constraint is bypassed because `PathMapped` matching is performed against the non-normalized canonical path.\n\n\n#### Suspected Root Cause\n\nThe suspected root cause is in `URIUtil.canonicalPath()`.\n\nThe relevant logic is approximately:\n\n```java\n for (int i = 0; i \u003c end; i++)\n {\n char c = encodedPath.charAt(i);\n\n switch (c)\n {\n case \u0027;\u0027:\n if (builder == null)\n {\n builder = new Utf8StringBuilder(encodedPath.length());\n builder.append(encodedPath, 0, i);\n }\n\n while (++i \u003c end)\n {\n if (encodedPath.charAt(i) == \u0027/\u0027)\n {\n builder.append(\u0027/\u0027);\n break;\n }\n }\n break;\n\n case \u0027.\u0027:\n if (slash)\n normal = false;\n if (builder != null)\n builder.append(c);\n break;\n }\n\n slash = c == \u0027/\u0027;\n }\n\n String canonical = (builder != null)\n ? (onBadUtf8 == null ? builder.toCompleteString() : builder.takeCompleteString(onBadUtf8))\n : encodedPath;\n return normal ? canonical : normalizePath(canonical);\n```\n\nFor the input:\n\n`/public;/../admin/secret`\n\nwhen the outer loop reaches the semicolon:\n\n```\n i = 7\n c = \u0027;\u0027\n slash = false\n normal = true\n```\n\nInside `case \u0027;\u0027`, the `while (++i \u003c end)` loop advances i to the next character, which is already \u0027/\u0027 for the empty path parameter form \";/\".\n\nThe code then appends \u0027/\u0027 to the canonical builder:\n\n`builder.append(\u0027/\u0027);`\n\nAt this point, the canonical builder ends with \u0027/\u0027:\n\n`/public/`\n\nHowever, the local variable `c` is still the old value \u0027;\u0027, because `c` was read before entering the switch and is not updated when the inner loop advances `i`.\n\nAfter leaving the switch, the loop updates the slash state using:\n\n`slash = c == \u0027/\u0027;`\n\nSince `c` is still \u0027;\u0027, slash becomes `false`.\n\nOn the next iteration, the scanner reaches \u0027.\u0027, which is the first dot in the following \"../\" segment. Because slash is incorrectly `false`, this code does not run:\n\n```java\n if (slash)\n normal = false;\n```\n\nTherefore `normal` remains `true`, and `canonicalPath()` returns the canonical string directly instead of calling `normalizePath(canonical)`.\n\nThe result is:\n\n`/public/../admin/secret`\n\ninstead of:\n\n`/admin/secret`\n\nIn short:\n\n`case \u0027;\u0027` advances the scan position i and appends \u0027/\u0027 to the canonical builder, but the loop tail still updates slash from the stale character `c=\u0027;\u0027`. As a result, the following dot-dot segment is not detected as a path traversal segment.\n\n#### More Precise Trigger Condition\n\nThe issue is not limited to a non-empty path parameter such as \";x\".\n\nThe more precise trigger shape is:\n\n`;[^/]*/.`\n\nExamples:\n\n```\n /public;/../admin/secret\n /public;x/../admin/secret\n /public;anything/../admin/secret\n /public;/./admin/secret\n```\n\nThe minimal form is:\n\n`/public;/../admin/secret`\n\nbecause the semicolon is immediately followed by \u0027/\u0027, so the inner while loop reaches \u0027/\u0027 on its first increment.\n\n#### Potential Minimal Fix Direction\n\nA minimal fix would be to ensure that, when case \u0027;\u0027 consumes input until \u0027/\u0027 and appends \u0027/\u0027 to the canonical builder, the slash state reflects the last effective character in the canonical path.\n\nFor example, conceptually:\n\n```java\n case \u0027;\u0027:\n if (builder == null)\n {\n builder = new Utf8StringBuilder(encodedPath.length());\n builder.append(encodedPath, 0, i);\n }\n\n while (++i \u003c end)\n {\n if (encodedPath.charAt(i) == \u0027/\u0027)\n {\n builder.append(\u0027/\u0027);\n slash = true;\n break;\n }\n }\n continue;\n```\n\nThe important part is to avoid the loop tail from overwriting slash using the stale `c` value:\n\n`slash = c == \u0027/\u0027;`\n\nIn other words, `slash` should represent the last effective character appended to the canonical builder, not the original input character read before case \u0027;\u0027 advanced `i`.",
"id": "GHSA-w7x5-g22v-xqhr",
"modified": "2026-07-22T22:57:36Z",
"published": "2026-07-22T22:57:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-w7x5-g22v-xqhr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8384"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/14969"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/14973"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/commit/82969c77f6da46e27008b10b3c14840cd31db084"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/commit/ade27ce93a37c33278720250d85c48601230ae3f"
},
{
"type": "PACKAGE",
"url": "https://github.com/jetty/jetty.project"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.35"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.9"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/108"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Eclipse Jetty: Path parameter traversal"
}
GHSA-WHQG-PPGF-WP8C
Vulnerability from github – Published: 2025-12-08 16:26 – Updated: 2025-12-09 16:28Authentication Bypass via Double URL Encoding in Astro
Bypass for CVE-2025-64765 / GHSA-ggxq-hp9w-j794
Summary
A double URL encoding bypass allows any unauthenticated attacker to bypass path-based authentication checks in Astro middleware, granting unauthorized access to protected routes. While the original CVE-2025-64765 (single URL encoding) was fixed in v5.15.8, the fix is insufficient as it only decodes once. By using double-encoded URLs like /%2561dmin instead of /%61dmin, attackers can still bypass authentication and access protected resources such as /admin, /api/internal, or any route protected by middleware pathname checks.
Fix
A more secure fix is just decoding once, then if the request has a %xx format, return a 400 error by using something like :
if (containsEncodedCharacters(pathname)) {
// Multi-level encoding detected - reject request
return new Response(
'Bad Request: Multi-level URL encoding is not allowed',
{
status: 400,
headers: { 'Content-Type': 'text/plain' }
}
);
}
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "astro"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.15.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66202"
],
"database_specific": {
"cwe_ids": [
"CWE-647"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-08T16:26:43Z",
"nvd_published_at": "2025-12-09T00:15:48Z",
"severity": "MODERATE"
},
"details": "# Authentication Bypass via Double URL Encoding in Astro\n## Bypass for CVE-2025-64765 / GHSA-ggxq-hp9w-j794\n\n---\n\n### Summary\n\nA **double URL encoding bypass** allows any unauthenticated attacker to bypass path-based authentication checks in Astro middleware, granting unauthorized access to protected routes. While the original CVE-2025-64765 (single URL encoding) was fixed in v5.15.8, the fix is insufficient as it only decodes once. By using double-encoded URLs like `/%2561dmin` instead of `/%61dmin`, attackers can still bypass authentication and access protected resources such as `/admin`, `/api/internal`, or any route protected by middleware pathname checks.\n\n\n## Fix \n\nA more secure fix is just decoding once, then if the request has a %xx format, return a 400 error by using something like :\n\n```\nif (containsEncodedCharacters(pathname)) {\n // Multi-level encoding detected - reject request\n return new Response(\n \u0027Bad Request: Multi-level URL encoding is not allowed\u0027,\n {\n status: 400,\n headers: { \u0027Content-Type\u0027: \u0027text/plain\u0027 }\n }\n );\n }\n```",
"id": "GHSA-whqg-ppgf-wp8c",
"modified": "2025-12-09T16:28:41Z",
"published": "2025-12-08T16:26:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/withastro/astro/security/advisories/GHSA-ggxq-hp9w-j794"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/security/advisories/GHSA-whqg-ppgf-wp8c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64765"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66202"
},
{
"type": "WEB",
"url": "https://github.com/withastro/astro/commit/6f800813516b07bbe12c666a92937525fddb58ce"
},
{
"type": "PACKAGE",
"url": "https://github.com/withastro/astro"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Astro has an Authentication Bypass via Double URL Encoding, a bypass for CVE-2025-64765"
}
GHSA-X39X-9QW5-GHRF
Vulnerability from github – Published: 2025-05-05 18:25 – Updated: 2025-05-05 18:25Summary
During a manual source code review, ARIMLABS.AI researchers identified that the browser_use module includes an embedded whitelist functionality to restrict URLs that can be visited. This restriction is enforced during agent initialization. However, it was discovered that these measures can be bypassed, leading to severe security implications.
Details
File: browser_use/browser/context.py
The BrowserContextConfig class defines an allowed_domains list, which is intended to limit accessible domains. This list is checked in the _is_url_allowed() method before navigation:
@dataclass
class BrowserContextConfig:
"""
[STRIPPED]
"""
cookies_file: str | None = None
minimum_wait_page_load_time: float = 0.5
wait_for_network_idle_page_load_time: float = 1
maximum_wait_page_load_time: float = 5
wait_between_actions: float = 1
disable_security: bool = True
browser_window_size: BrowserContextWindowSize = field(default_factory=lambda: {'width': 1280, 'height': 1100})
no_viewport: Optional[bool] = None
save_recording_path: str | None = None
save_downloads_path: str | None = None
trace_path: str | None = None
locale: str | None = None
user_agent: str = (
'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36'
)
highlight_elements: bool = True
viewport_expansion: int = 500
allowed_domains: list[str] | None = None
include_dynamic_attributes: bool = True
_force_keep_context_alive: bool = False
The _is_url_allowed() method is responsible for checking whether a given URL is permitted:
def _is_url_allowed(self, url: str) -> bool:
"""Check if a URL is allowed based on the whitelist configuration."""
if not self.config.allowed_domains:
return True
try:
from urllib.parse import urlparse
parsed_url = urlparse(url)
domain = parsed_url.netloc.lower()
# Remove port number if present
if ':' in domain:
domain = domain.split(':')[0]
# Check if domain matches any allowed domain pattern
return any(
domain == allowed_domain.lower() or domain.endswith('.' + allowed_domain.lower())
for allowed_domain in self.config.allowed_domains
)
except Exception as e:
logger.error(f'Error checking URL allowlist: {str(e)}')
return False
The core issue stems from the line domain = domain.split(':')[0], which allows an attacker to manipulate basic authentication credentials by providing a username:password pair. By replacing the username with a whitelisted domain, the check can be bypassed, even though the actual domain remains different.
Proof of Concept (PoC)
Set allowed_domains to ['example.com'] and use the following URL:
https://example.com:pass@localhost:8080
This allows bypassing all whitelist controls and accessing restricted internal services.
Impact
- Affected all users relying on this functionality for security.
- Potential for unauthorized enumeration of localhost services and internal networks.
- Ability to bypass domain whitelisting, leading to unauthorized browsing.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.44"
},
"package": {
"ecosystem": "PyPI",
"name": "browser-use"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.45"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-47241"
],
"database_specific": {
"cwe_ids": [
"CWE-647"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-05T18:25:04Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary \nDuring a manual source code review, [**ARIMLABS.AI**](https://arimlabs.ai) researchers identified that the `browser_use` module includes an embedded whitelist functionality to restrict URLs that can be visited. This restriction is enforced during agent initialization. However, it was discovered that these measures can be bypassed, leading to severe security implications. \n\n### Details \n**File:** `browser_use/browser/context.py` \n\nThe `BrowserContextConfig` class defines an `allowed_domains` list, which is intended to limit accessible domains. This list is checked in the `_is_url_allowed()` method before navigation:\n\n```python\n@dataclass\nclass BrowserContextConfig:\n \"\"\"\n [STRIPPED]\n \"\"\"\n cookies_file: str | None = None\n minimum_wait_page_load_time: float = 0.5\n wait_for_network_idle_page_load_time: float = 1\n maximum_wait_page_load_time: float = 5\n wait_between_actions: float = 1\n\n disable_security: bool = True\n\n browser_window_size: BrowserContextWindowSize = field(default_factory=lambda: {\u0027width\u0027: 1280, \u0027height\u0027: 1100})\n no_viewport: Optional[bool] = None\n\n save_recording_path: str | None = None\n save_downloads_path: str | None = None\n trace_path: str | None = None\n locale: str | None = None\n user_agent: str = (\n \u0027Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36\u0027\n )\n\n highlight_elements: bool = True\n viewport_expansion: int = 500\n allowed_domains: list[str] | None = None\n include_dynamic_attributes: bool = True\n\n _force_keep_context_alive: bool = False\n```\nThe _is_url_allowed() method is responsible for checking whether a given URL is permitted:\n```python\ndef _is_url_allowed(self, url: str) -\u003e bool:\n \"\"\"Check if a URL is allowed based on the whitelist configuration.\"\"\"\n if not self.config.allowed_domains:\n return True\n\n try:\n from urllib.parse import urlparse\n\n parsed_url = urlparse(url)\n domain = parsed_url.netloc.lower()\n\n # Remove port number if present\n if \u0027:\u0027 in domain:\n domain = domain.split(\u0027:\u0027)[0]\n\n # Check if domain matches any allowed domain pattern\n return any(\n domain == allowed_domain.lower() or domain.endswith(\u0027.\u0027 + allowed_domain.lower())\n for allowed_domain in self.config.allowed_domains\n )\n except Exception as e:\n logger.error(f\u0027Error checking URL allowlist: {str(e)}\u0027)\n return False\n```\nThe core issue stems from the line `domain = domain.split(\u0027:\u0027)[0]`, which allows an attacker to manipulate basic authentication credentials by providing a username:password pair. By replacing the username with a whitelisted domain, the check can be bypassed, even though the actual domain remains different.\n### Proof of Concept (PoC)\n\nSet allowed_domains to [\u0027example.com\u0027] and use the following URL:\n\nhttps://example.com:pass@localhost:8080\n\nThis allows bypassing all whitelist controls and accessing restricted internal services.\n### Impact\n\n- Affected all users relying on this functionality for security.\n- Potential for unauthorized enumeration of localhost services and internal networks.\n- Ability to bypass domain whitelisting, leading to unauthorized browsing.",
"id": "GHSA-x39x-9qw5-ghrf",
"modified": "2025-05-05T18:25:04Z",
"published": "2025-05-05T18:25:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/browser-use/browser-use/security/advisories/GHSA-x39x-9qw5-ghrf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47241"
},
{
"type": "WEB",
"url": "https://github.com/browser-use/browser-use/pull/1561"
},
{
"type": "PACKAGE",
"url": "https://github.com/browser-use/browser-use"
},
{
"type": "WEB",
"url": "https://github.com/browser-use/browser-use/releases/tag/0.1.45"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Browser Use allows bypassing `allowed_domains` by putting a decoy domain in http auth username portion of a URL"
}
Mitigation
Make access control policy based on path information in canonical form. Use very restrictive regular expressions to validate that the path is in the expected form.
Mitigation
Reject all alternate path encodings that are not in the expected canonical form.
No CAPEC attack patterns related to this CWE.