Description

@cedar-policy/authorization-for-expressjs is an open-source Express.js middleware that integrates Cedar authorization into Express applications by mapping HTTP requests to Cedar actions and evaluating authorization policies before allowing requests to proceed. Versions prior to 0.3.0 have an issue where, under certain circumstances, the middleware matches incoming requests against Cedar action mappings using req.originalUrl, which includes the query string, while Express routes requests using only the path component. The middleware uses req.originalUrl to match incoming requests against Cedar action mappings. In Express, req.originalUrl includes the query string, while route matching uses only the path. This creates a divergence between what Cedar authorizes and what Express executes. When an application defines separate actions for overlapping path prefixes with different authorization requirements (for example, GET /users for listing all users with admin-only access, and GET /users/{id} for retrieving a single user with any authenticated user access), an actor can append a query string to bypass the more restrictive policy. Sending GET /users/?x=1 causes the middleware to match against /users/{id} (with id parameter set to ?x=1) and evaluate the less restrictive action, while Express routes the request to the /users list handler. This allows inappropriate access to the more restrictive endpoint. This issue has been addressed in version 0.30. Some workarounds are available. Validate and sanitize incoming request paths before they reach the authorization middleware. Ensure that applications do not rely solely on the middleware for authorization when defining multiple actions on overlapping path prefixes with different permission levels.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-13T00:17:32.587Z",
  "pubdate": "2026-08-13T00:17:32.587Z",
  "executiveSummary": "A routing divergence vulnerability exists in the @cedar-policy/authorization-for-expressjs Express.js middleware in versions prior to 0.3.0.\nThe vulnerability arises because the authorization middleware evaluates incoming requests against Cedar action mappings using req.originalUrl, which includes the query string, whereas Express routes requests based solely on the path component.\nThis architectural discrepancy allows an unauthenticated or low-privileged attacker to craft a specially formed HTTP request containing a query string that bypasses strict authorization policies.\nSpecifically, when applications define overlapping path prefixes with disparate access control requirements, an attacker can append query parameters to force the authorization layer to evaluate a less restrictive Cedar action while Express routes the underlying execution to a more sensitive, restrictive endpoint.\nThe impact includes unauthorized access to restricted administrative functionalities and data exposure.\nExploitation requires the application to implement overlapping path prefixes with different permission levels and the use of versions prior to 0.3.0 of the middleware.",
  "technicalDetails": "The root cause of the vulnerability stems from a mismatch in how request URIs are parsed and utilized for security enforcement versus application routing within the Express.js ecosystem.\nThe vulnerable component is the request mapping and authorization logic within @cedar-policy/authorization-for-expressjs prior to version 0.3.0.\nDuring the authorization phase, the middleware retrieves the request URI via req.originalUrl. In Express.js, req.originalUrl contains the full request path combined with the query string (e.g., /users/?x=1).\nConversely, the underlying Express.js routing engine strips the query string and performs route matching using strictly the path component.\nWhen an application defines overlapping path prefixes with differing authorization requirements—such as GET /users for listing all users restricted to administrators, and GET /users/{id} for retrieving a single user permitted for any authenticated user—a divergence occurs.\nAn attacker can exploit this behavior through the following step-by-step attack flow:\n1. The attacker identifies an endpoint with strict authorization requirements, such as GET /users.\n2. The attacker crafts an HTTP request targeting the restricted endpoint but appends a query string, such as GET /users/?x=1.\n3. The authorization middleware intercepts the request and evaluates req.originalUrl against Cedar action mappings.\n4. Due to the presence of the query string, the middleware erroneously matches the request against the pattern for GET /users/{id}, treating the query string fragment as the path parameter id.\n5. The middleware evaluates the less restrictive Cedar action associated with GET /users/{id} and allows the request to proceed.\n6. The Express.js router evaluates the request using only the path component (/users), routing the execution directly to the sensitive list handler.\n7. The application executes the handler and returns the restricted data, successfully bypassing the intended authorization policy.\nNetwork exposure is applicable to any web application exposing these endpoints over HTTP/HTTPS. Authentication and privilege requirements depend on the specific endpoint configuration, but the flaw enables lower-privileged or unauthorized entities to inherit broader execution permissions."
}