Apache HTTP Server weakness with encoded question marks in backreferences
Substitution encoding issue in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows attacker to execute scripts in
directories permitted by the configuration but not directly reachable by any URL or source disclosure of scripts meant to only to be executed as CGI.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
Some RewriteRules that capture and substitute unsafely will now fail unless rewrite flag "UnsafeAllow3F" is specified.
Alta · CVSS 8.1EPSS 25,88%Código de explotación públicoCorrección disponible
Apache HTTP Server proxy encoding problem
Encoding problem in mod_proxy in Apache HTTP Server 2.4.59 and earlier allows request URLs with incorrect encoding to be sent to backend services, potentially bypassing authentication via crafted requests.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
Apache HTTP Server: DoS by Null pointer in websocket over HTTP/2
Serving WebSocket protocol upgrades over a HTTP/2 connection could result in a Null Pointer dereference, leading to a crash of the server process, degrading performance.
Apache HTTP Server: HTTP/2 DoS by memory exhaustion on endless continuation frames
HTTP/2 incoming headers exceeding the limit are temporarily buffered in nghttp2 in order to generate an informative HTTP 413 response. If a client does not stop sending headers, this leads to memory exhaustion.
Apache HTTP Server: HTTP Response Splitting in multiple modules
HTTP Response splitting in multiple modules in Apache HTTP Server allows an attacker that can inject malicious response headers into backend applications to cause an HTTP desynchronization attack.
Users are recommended to upgrade to version 2.4.59, which fixes this issue.
Faulty input validation in the core of Apache allows malicious or exploitable backend/content generators to split HTTP responses.
This issue affects Apache HTTP Server: through 2.4.58.
Apache HTTP Server: HTTP/2 stream memory not reclaimed right away on RST
When a HTTP/2 stream was reset (RST frame) by a client, there was a time window were the request's memory resources were not reclaimed immediately. Instead, de-allocation was deferred to connection close. A client could send new requests and resets, keeping the connection busy and open and causing the memory footprint to keep on growing. On connection close, all resources were reclaimed, but the process might run out of memory before that.
This was found by the reporter during testing of CVE-2023-44487 (HTTP/2 Rapid Reset Exploit) with their own test client. During "normal" HTTP/2 use, the probability to hit this bug is very low. The kept me