-
Bug
-
Resolution: Done
-
Major
-
2.2.26.SP1, 2.3.10.SP1
-
None
-
https://gitlab.cee.redhat.com/undertow-io/undertow/-/merge_requests/80, https://gitlab.cee.redhat.com/undertow-io/undertow/-/merge_requests/79, https://gitlab.cee.redhat.com/undertow-io/undertow/-/commit/8651430dbbe45f910d5bd150deda0db19d219d33, https://gitlab.cee.redhat.com/undertow-io/undertow/-/commit/49c502dc1fc0c261c45d8ced15b0cd1fe6454ea8, https://github.com/undertow-io/undertow/pull/1609, https://github.com/undertow-io/undertow/pull/1612
This is a race condition issue where the URL-encoded request path information can be broken for concurrent requests on ajp-listener.
The request path is decoded through AjpRequestParser on ajp-listener. However, the same StringBuilder instance (decodedBuffer) is passed to URLUtils.decode() for any requests in AjpRequestParser. So, the decodedBuffer can be mixed up, and the decoded request path information (relativePath and requestPath in HttpServerExchange) can be broken when the decode processing is invoked for multiple requests concurrently. In that case, the request will be processed as the wrong path information and fail with "404 Not Found" for static contents (or causing application error due to the wrong path information, etc).
- is incorporated by
-
WFCORE-6862 CVE-2024-6162 CVE-2024-27316 Upgrade Undertow to 2.3.14.Final
- Resolved
- is triggering
-
WFLY-19494 Ignore CVE-2024-6162 as we are using Undertow 2.3.14.Final which contains the fix
- Resolved