[SECURITY] [DLA 4270-1] apache2 security update
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
- -------------------------------------------------------------------------
Debian LTS Advisory DLA-4270-1 debian-lts@lists.debian.org
https://www.debian.org/lts/security/ Bastien Roucariès
August 12, 2025 https://wiki.debian.org/LTS
- -------------------------------------------------------------------------
Package : apache2
Version : 2.4.65-1~deb11u1
CVE ID : CVE-2024-42516 CVE-2024-43204 CVE-2024-43394 CVE-2024-47252
CVE-2025-23048 CVE-2025-49630 CVE-2025-49812 CVE-2025-53020
CVE-2025-54090
Multiple vulnerabilities have been addressed in Apache,
a widely used web server.
Please note that the fix for CVE-2025-23048, included in this DLA,
may cause some SSL-enabled websites to encounter the error AH02032.
Additional details are provided at the end of this advisory.
CVE-2024-42516
HTTP response splitting in the core of Apache HTTP Server allows an
attacker who can manipulate the Content-Type response headers of
applications hosted or proxied by the server can split the HTTP response
CVE-2024-43204
A SSRF (Server Side Request Forgery) was found in Apache HTTP Server
with mod_proxy loaded allows an attacker to
send outbound proxy requests to a URL controlled by the attacker.
This attack requires an unlikely configuration where mod_headers
is configured to modify the Content-Type request or response header with a
value provided in the HTTP request
CVE-2024-43394
A Server-Side Request Forgery (SSRF) in Apache HTTP Server on Windows
allows to potentially leak NTLM hashes to a malicious server via mod_rewrite
or apache expressions that pass unvalidated request input.
CVE-2024-47252
Insufficient escaping of user-supplied data in mod_ssl allows an untrusted
SSL/TLS client to insert escape characters into log files in some
configurations. In a logging configuration where CustomLog is used with
"%{varname}x" or "%{varname}c" to log variables provided by mod_ssl such as
SSL_TLS_SNI, no escaping is performed by either mod_log_config or mod_ssl and
unsanitized data provided by the client may appear in log files.
CVE-2025-23048
An access control bypass by trusted clients is possible using TLS 1.3
session resumption. Configurations are affected when mod_ssl is
configured for multiple virtual hosts, with each restricted to a
different set of trusted client certificates
(for example with a different SSLCACertificateFile/Path setting).
In such a case, a client trusted to access one virtual host may be able to
access another virtual host, if SSLStrictSNIVHostCheck is not enabled
in either virtual host.
CVE-2025-49630
In certain proxy configurations, a denial of service attack against
Apache HTTP Server can be triggered by untrusted clients causing
an assertion in mod_proxy_http2. Configurations affected are a
reverse proxy is configured for an HTTP/2 backend, with
ProxyPreserveHost set to "on".
CVE-2025-49812
In some mod_ssl configurations on Apache HTTP server, an HTTP
desynchronisation attack allows a man-in-the-middle attacker
to hijack an HTTP session via a TLS upgrade. Only configurations
using "SSLEngine optional" to enable TLS upgrades are affected.
Support for TLS upgrade was removed.
CVE-2025-53020
A late Release of Memory after Effective Lifetime vulnerability
was found in Apache HTTP Server.
CVE-2025-54090
A bug in Apache HTTP Server 2.4.64 results in all
"RewriteCond expr ..." tests evaluating as "true"
For Debian 11 bullseye, these problems have been fixed in version
2.4.65-1~deb11u1.
Note that following the resolution of CVE-2025-23048,
some SSL-enabled websites may begin encountering
the error (AH02032):
Misdirected Request:
The client needs a new connection for this request as the
requested host name does not match the Server Name Indication
(SNI) in use for this connection.
This behavior is particularly noticeable with AWS Application
Load Balancers. Although they support intelligent SNI handling,
they do not (as of this writing) relay SNI data to the target
server, resulting in failed connections when hostnames donâ??t align.
Without an SNI provided by the client, there is nothing httpd
can do to determine which vhost/configuration should be
used to provide the correct certificate (and TLS authentication
eventually) whenever multiple vhosts listen on the same IP:port.
That's because reading the HTTP Host header necessarily has to
happen after the TLS handshake/auth/decryption (and later
renegotiation is not an option with TLSv1.3).
So those connections fall back to the first vhost declared on
the IP:port for the TLS handshake part, and if the request
Host header finally matches a different vhost with a different
TLS configuration it's rejected with AH02032.
Before 2.4.64 the check was not accurate and would allow that,
with security implications.
As a workaround, you may (after a risk analysis) generate a
wildcard certificate. If youâ??re managing multiple domains,
consolidate them into a single certificate by including each
wildcard domain as an alias. Then, update the Apache configuration
to reference this unified certificate.
Another possible workaround is to configure each virtual host to
listen on a separate port. This approach avoids SNI-related issues
by ensuring that each vhost is uniquely addressed through its own
connection endpoint, thereby allowing distinct TLS configurations
without ambiguity.
This error may also stem from a misconfigured HAProxy setup.
In such cases, enabling dynamic SNI handling on HAProxy might be
necessary to ensure that the correct hostname is passed through
during the TLS handshake. After risk analysis, it could be done
by using "sni req.hdr(Host)" directive.
We recommend that you upgrade your apache2 packages.
For the detailed security status of apache2 please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/apache2
Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmibbjMACgkQADoaLapB
CF88GQ/+KYUnJeWclxiC1hMRT2dsuW/fif3Zk4kHxMV108MkS5lIpQudIhh9ctIm
4jFMLB2KkkSr2FzGEIrkYlvvxt1msJmaIUBzJ996M3Mu7SFqi7UMCucCD2NDiQKI
nzHSXhN2XW0HlQp4qkvG/WsVQcB8rziCAjW/WvHpNajEbqyjLiBrcoYmQIn7gCMD
iDlDWk6thV5G0Pv72k84w6Ufei1oj/Wj2bYMLT0aBahJ1ZZI+9MzJdT5H5bv+tlX
WFGh112j8PTkj4lgJp4K1E1HLLb018v0ib69kzx0kFHY21APBKlaw2U/d6WJZegr
EIkkcfq+U1U1S6KykFXVxtAQh/xpEt0cTq7NDDd4vIGr+qCbV7c+IGvLC2JUauHe
qQTzkkIkGb2cyIZE5aCl9mwfwHVChfwRww0E+lToLzBd7MLYg72sga70KTGWy2MF
xKK+z1vjg+g1W17k6XEgHQ1Uj1CAwshEcJTeBDSTno9qB97+ItJ5z+6kqytwyVF6
kzXWG4CIzxOXVMp5S8OpqskwDxRS1/Qy8ES2K+rGYlLRhQubbSPfllMMSwdSf7ry
2nsbh8dOofOuNLfeSLbULluA5bnoEcKq1QSPItXWCEy97uU8jtKL+qblQ1+cM1So
x8upMAZIrhWHmJJ/b3gs1RiXQ16yStqQPDKY0/aZX46YthOR0K8=
=lYbL
-----END PGP SIGNATURE-----
Reply to: