CVE-2025-23048: Apache HTTP Server Auth Bypass Flaw

CVE-2025-23048 Overview

CVE-2025-23048 is an access control bypass vulnerability in Apache HTTP Server mod_ssl, affecting versions 2.4.35 through 2.4.63. The flaw allows a TLS client trusted by one virtual host to gain access to a different virtual host through TLS 1.3 session resumption. The issue arises when mod_ssl is configured with multiple virtual hosts, each restricted to a distinct set of trusted client certificates via different SSLCACertificateFile or SSLCACertificatePath directives. The bypass is possible when SSLStrictSNIVHostCheck is not enabled on either virtual host. This is classified under [CWE-284] (Improper Access Control).

Critical Impact

A client authenticated to one mTLS-protected virtual host can resume its TLS 1.3 session against another virtual host on the same Apache instance, bypassing the intended client-certificate trust boundary.

Affected Products

• Apache HTTP Server 2.4.35 through 2.4.63
• Apache mod_ssl configurations using per-vhost trusted client certificate sets
• Deployments with SSLStrictSNIVHostCheck disabled across affected virtual hosts

Discovery Timeline

• 2025-07-10 - CVE-2025-23048 published to NVD and announced on the oss-security mailing list
• 2025-08 - Debian LTS security announcement published for affected packages
• 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2025-23048

Vulnerability Analysis

The vulnerability resides in how Apache mod_ssl enforces per-virtual-host client certificate trust when TLS 1.3 session resumption occurs. Apache supports configurations where each virtual host accepts a different certificate authority bundle, effectively partitioning trusted clients between hostnames sharing the same listener. When a client establishes an initial TLS 1.3 session against virtual host A and is authenticated against A's CA set, the resulting session ticket carries the authenticated state. On resumption, the client can present the Server Name Indication (SNI) for virtual host B and reuse the existing session. Because resumption short-circuits the full handshake, mod_ssl does not re-evaluate the client certificate against virtual host B's distinct trust store. The client therefore inherits access to a resource for which its certificate was never trusted.

Root Cause

The root cause is incomplete revalidation of client-certificate trust during TLS 1.3 session resumption across virtual host boundaries. mod_ssl binds the authenticated identity to the session at initial handshake time but does not enforce that the resumed connection targets the same vhost trust scope. Without SSLStrictSNIVHostCheck, the server permits the resumed session to apply to a different vhost configured with a different SSLCACertificateFile or SSLCACertificatePath.

Attack Vector

Exploitation requires a client that already holds a certificate trusted by at least one virtual host on the target Apache server. The attacker performs a normal TLS 1.3 handshake against that virtual host, obtains a session ticket, and then initiates a new connection presenting an SNI value for a sibling virtual host. The server resumes the prior session, applies the cached authentication state, and grants access without re-checking the client certificate against the second vhost's CA bundle. No network position beyond direct client access to the server is required, and no user interaction is needed.

No verified public exploit code is available. Refer to the Apache HTTP Server Vulnerabilities advisory and the oss-security disclosure for the authoritative technical description.

Detection Methods for CVE-2025-23048

Indicators of Compromise

• TLS 1.3 connections to a virtual host where the resumed session was originally negotiated against a different vhost on the same listener
• Access log entries showing authenticated requests to vhost B from a client certificate subject only trusted by vhost A's SSLCACertificateFile
• Unexpected SSL_CLIENT_S_DN values in mod_ssl logs that do not match the vhost's configured CA set

Detection Strategies

• Audit running Apache configurations for mod_ssl virtual hosts that define distinct SSLCACertificateFile or SSLCACertificatePath values without SSLStrictSNIVHostCheck on
• Correlate TLS session ticket identifiers across vhost access logs to identify resumption that crosses trust boundaries
• Enable verbose mod_ssl logging (LogLevel ssl:info) to record session resumption events and client DN values for review

Monitoring Recommendations

• Forward Apache access and error logs to a centralized log platform and alert on client certificate DNs accessing vhosts outside their authorized scope
• Track the installed httpd version across the fleet and flag any host running 2.4.35 through 2.4.63
• Monitor for new or unexpected client certificate issuers appearing in requests to high-sensitivity vhosts

How to Mitigate CVE-2025-23048

Immediate Actions Required

• Upgrade Apache HTTP Server to a fixed release later than 2.4.63 as published in the Apache security advisory
• Enable SSLStrictSNIVHostCheck on in every affected virtual host until patching is complete
• Review all mod_ssl virtual host definitions and confirm whether per-vhost client certificate trust boundaries are required

Patch Information

The Apache HTTP Server project has published fixes through the official channel. Consult the Apache HTTP Server 2.4 vulnerabilities page for the corrected version and the Debian LTS advisory for distribution-specific package updates. Apply vendor packages where available rather than building from source to retain support coverage.

Workarounds

• Set SSLStrictSNIVHostCheck on in each virtual host using mutual TLS to force the server to reject resumed sessions whose SNI does not match the originally negotiated vhost
• Disable TLS 1.3 session resumption by setting SSLSessionTickets off and tuning SSLSessionCache to prevent cross-vhost reuse
• Separate vhosts with different client certificate trust requirements onto distinct listeners, IP addresses, or Apache instances

# Configuration example: enforce strict SNI vhost check in each affected vhost
<VirtualHost *:443>
    ServerName secure-a.example.com
    SSLEngine on
    SSLStrictSNIVHostCheck on
    SSLSessionTickets off
    SSLVerifyClient require
    SSLCACertificateFile /etc/ssl/ca/tenant-a-ca.pem
</VirtualHost>

<VirtualHost *:443>
    ServerName secure-b.example.com
    SSLEngine on
    SSLStrictSNIVHostCheck on
    SSLSessionTickets off
    SSLVerifyClient require
    SSLCACertificateFile /etc/ssl/ca/tenant-b-ca.pem
</VirtualHost>