Apache mod_ssl TLS 1.3 Session Resumption Client Certificate Bypass (CVE-2025-23048)

Metadata

Affected Target

Summary

CVE-2025-23048 is a client certificate authentication bypass in Apache HTTP Server’s mod_ssl that occurs when TLS 1.3 session resumption (session tickets/PSK) is used across virtual hosts configured with different SSLCACertificateFile directives. The root cause is that mod_ssl does not re-validate the client certificate’s issuing CA against the resuming virtual host’s trust store when a TLS 1.3 session ticket is presented, allowing a session established (and a certificate validated) on one vhost to be resumed on a different vhost that trusts a distinct CA. The PoC demonstrates this by performing a full TLS 1.3 handshake with a client certificate signed by CA1 against vhost1, saving the session ticket, and then resuming that saved session against vhost2 (which only trusts CA2) to reach a Require valid-user protected path without ever presenting a certificate trusted by CA2. Impact is unauthorized access to certificate-protected resources on any co-hosted vhost sharing the TLS stack/session cache, effectively bypassing mutual-TLS access controls.

Vulnerability Details

Root Cause

When SSLStrictSNIVHostCheck is off (or not enforced consistently) and virtual hosts share a TLS 1.3 session cache/ticket mechanism, mod_ssl restores the previously negotiated peer identity/authentication state on session resumption without re-checking it against the resuming vhost’s own SSLCACertificateFile/SSLVerifyClient policy:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

SSLCACertificateFile "C:/Apache24/conf/ssl/ca1.pem"
SSLVerifyClient optional
<Location />
    Require ssl-verify-client
</Location>

SSLCACertificateFile "C:/Apache24/conf/ssl/ca2.pem"
SSLVerifyClient optional_no_ca
<Location /restricted>
    Require valid-user
</Location>

Because TLS 1.3 session tickets carry the previously authenticated state and SSLStrictSNIVHostCheck is disabled, a session ticket obtained on vhost1 (authenticated via CA1) can be replayed against vhost2, and the resumed session is treated as already-authenticated/valid without re-verifying the certificate chain against ca2.pem.

Attack Vector

1. Attacker obtains (or already holds) a client certificate signed by CA1, valid for vhost1.example.com.
2. Attacker performs a full TLS 1.3 handshake against vhost1 using openssl s_client with the CA1-signed client certificate, requesting GET /, and saves the resulting session ticket to a file (-sess_out session_v1.pem).
3. Attacker connects to vhost2.example.com (same IP/port, different SNI) using -sess_in session_v1.pem to resume the saved TLS 1.3 session — without presenting any client certificate this time.
4. mod_ssl accepts the resumed session as authenticated and grants access to the /restricted path on vhost2, which is supposed to require a certificate trusted by CA2 only.
5. Attacker retrieves protected content from vhost2 despite never proving possession of a CA2-issued certificate.

Impact

An attacker who legitimately holds (or has compromised) a client certificate trusted by any one virtual host on a shared Apache instance can bypass mutual-TLS/client-certificate access controls on other, more sensitive virtual hosts on the same server — leading to unauthorized access to restricted resources, data disclosure, and defeat of per-vhost mTLS segmentation.

Environment / Lab Setup

Target:
- Apache HTTP Server 2.4.35 - 2.4.62 (tested: 2.4.57, Win64) with mod_ssl and mod_socache_shmcb enabled
- TLS 1.3 enabled (SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2)
- SSLSessionCache configured (shmcb) with SSLSessionTickets on
- Two (or more) name-based virtual hosts on the same IP:443, each with a distinct SSLCACertificateFile
- SSLStrictSNIVHostCheck off (default/typical shared-cert multi-vhost deployment)

Attacker:
- OpenSSL CLI (s_client) capable of TLS 1.3 with session ticket save/restore (-sess_out / -sess_in)
- A client certificate signed by the CA trusted by at least one of the virtual hosts

Proof of Concept

PoC Script

See README.md (upstream repo contains the full walkthrough with screenshots poc1.jpg and poc2.jpg; no separate script file is provided — the PoC is a sequence of openssl s_client commands).

1
2
3
4
5
6

openssl s_client -servername vhost1.example.com -tls1_3 \
  -cert client_ca1.crt -key client_ca1.key \
  -CAfile server.crt -sess_out session_v1.pem TARGET_IP:443
openssl s_client -servername vhost2.example.com -tls1_3 \
  -CAfile server.crt -sess_in session_v1.pem TARGET_IP:443
#

Detection & Indicators of Compromise

- TLS session resumption (PSK / session ticket reuse) observed with a change in SNI/Host header
  between the original full handshake and the resumed session.
- Apache/mod_ssl access logs showing a resumed TLS 1.3 session (short/absent handshake) followed by
  access to a Require valid-user / Require ssl-verify-client protected path, with no corresponding
  client certificate verification log entry for that vhost.
- Presence of "Reused, TLSv1.3" (or equivalent) in SSL debug/error logs immediately preceding access
  to a differently-CA-scoped virtual host from the same client session.

Signs of compromise:

• Access to CA-restricted virtual host content without a matching client-certificate verification event in mod_ssl logs.
• Session ticket/PSK reuse across requests carrying different Host/SNI values for vhosts configured with distinct SSLCACertificateFile directives.
• Unexpected Require valid-user grants on a vhost immediately following a session resumed from a different vhost’s handshake.

Remediation

References

• Source repository

Notes

Mirrored from https://github.com/absholi7ly/CVE-2025-23048-POC on 2026-07-06. The upstream repository contains only a README.md with the full walkthrough plus two screenshots (poc1.jpg, poc2.jpg); there is no standalone exploit script beyond the documented openssl s_client command sequence.