jamesfredley opened a new pull request, #16311: URL: https://github.com/apache/grails-core/pull/16311
## Summary ASF security review finding **f003**, with sibling matchers **f017** and **f020**. Interceptor URI matching used the raw servlet `requestURI` (not decoded). `UrlMappingMatcher` only stripped `;` then ran `AntPathMatcher`. Grails dispatch uses Spring `UrlPathHelper.getPathWithinApplication`, which decodes and strips matrix parameters. Encoded segments (`/%61dmin/deleteUser`) or matrix parameters (`/admin;x=1/deleteUser`) could therefore reach a controller while `match(uri: '/admin/**')` did not fire. The same requestURI/dispatch desync existed in: - Spring Security compat `AntPathRequestMatcher` (f017) - `IpAddressFilter` (f020), including forwarded URIs This is a real matcher/dispatch inconsistency. It is **not** a framework-wide unauthenticated auth bypass: the shipped auth example matches controller/action from `UrlMappingInfo`, application-level auth is out of scope (threat model ยง3), and URI-pattern interceptors are a documented optional matcher. Treat as a bug / ASF MODERATE at most, not a 9.8 CVE. ## Changes - Interceptor matching uses `UrlPathHelper.getPathWithinApplication`. - `UrlMappingMatcher` canonicalizes the path (decode + strip matrix parameters) and still accepts context-prefixed patterns from issue 10857. - Compat `AntPathRequestMatcher` and `IpAddressFilter` match the same canonical application path. ## Testing - `:grails-interceptors:test` - `:grails-spring-security-compat:test` - `:grails-spring-security:test` - codeStyle on those modules -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
