Apache HTTP Server versions 2.4.20 to 2.4.43. A specially crafted value for the 'Cache-Digest' header in a HTTP/2 request would result in a crash when the server actually tries to HTTP/2 PUSH a resource afterwards. Configuring the HTTP/2 feature via "H2Push off" will mitigate this vulnerability for unpatched servers.
A flaw was found in Apache httpd in versions 2.4.20 to 2.4.43. Logging using the wrong pool by modhttp2 at debug/trace log level may lead to potential crashes and denial of service. The highest threat from this vulnerability is to system availability.
A vulnerability was found in Apache httpd, in modhttp2. Under certain circumstances, HTTP/2 early pushes could lead to memory corruption, causing a server to crash.
A vulnerability was found in http/2 where an attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both, potentially leading to a denial of service.
In Apache httpd 2.0.23 to 2.0.65, 2.2.0 to 2.2.34, and 2.4.0 to 2.4.29, modauthnzldap, if configured with AuthLDAPCharsetConfig, uses the Accept-Language header value to lookup the right charset encoding when verifying the user's credentials. If the header value is not present in the charset conversion table, a fallback mechanism is used to truncate it to a two characters value to allow a quick retry (for example, 'en-US' is truncated to 'en'). A header value of less than two characters forces an out of bound write of one NUL byte to a memory location that is not part of the string. In the worst case, quite unlikely, the process would crash which could be used as a Denial of Service attack. In the more likely case, this memory is already reserved for future use and the issue has no effect at all.
A use-after free vulnerability was found in apache httpd. There's an apache configuration directive <Limit> that can be used to restrict access to certain HTTP methods. If one sets this inside an .htaccess file with an HTTP method that's not registered in the server the bug happens (e.g. set <Limit INVALID></Limit> in .htaccess). The reason is that at that point the variables used to build up the "Allow" header have already been freed, as it's not expecting any more changes to it.
Note that the bug only appears with OPTIONS requests to a specific path, not with "" OPTIONS requests.
An attacker on a shared hosting could could deliberately create an .htaccess file triggering the bug and subsequently try to exfiltrate data pieces from the global apache process that may contain secrets like password hashes.
Upstream patch:
https://svn.apache.org/viewvc?view=revision&revision=1807754
apache. Multiple issues existed in Apache. These were addressed by updating Apache to version 2.4.25.
apache. Multiple issues existed in Apache. These were addressed by updating Apache to version 2.4.25.
apache. Multiple issues existed in Apache. These were addressed by updating Apache to version 2.4.25.
The Apache HTTP Server 2.4.18 through 2.4.20, when modhttp2 and modssl are enabled, does not properly recognize the "SSLVerifyClient require" directive for HTTP/2 request authorization, which allows remote attackers to bypass intended access restrictions by leveraging the ability to send multiple requests over a single connection and aborting a renegotiation.