F5 NGINX Open Source and NGINX Plus client certificate authentication bypass through TLS session resumption

When multiple server blocks are configured to share the same IP address and port, an attacker can use session resumption to bypass client certificate authentication requirements on these servers. This vulnerability arises when TLS Session Tickets https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key are used and/or the SSL session cache https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache are used in the default server and the default server is performing client certificate authentication.   Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

F5 records the following affected and unaffected boundaries:

• NGINX Open Source: the affected entry starts at 1.11.4 with lessThan: *. The branch points 1.26.3 and 1.27.4 are marked unaffected.
• NGINX Plus: the affected entry starts at R17 with lessThan: *. The branch points R32 P2 and R33 P2 are marked unaffected.
• Debian: the bookworm update is recorded at package 1.22.1-9+deb12u1; the Debian 11 bullseye update is recorded at package 1.18.0-6.1+deb11u4. Debian also states that ngx_stream_ssl_module was not affected in bullseye because stream virtual server functionality was added in a later release branch.

The record gives NGINX Open Source a default status of unknown and NGINX Plus a default status of unaffected, but the branch-specific entries above take precedence for assessment. Unlisted branches or builds should not be assumed safe. F5's description also states that software versions which reached End of Technical Support were not evaluated.

F5 NGINX Open Source and NGINX Plus contain a flaw in how authentication context is bound when TLS session resumption is used across multiple named virtual hosts sharing one IP address and port. The exposure conditions include an OpenSSL-built NGINX deployment, session resumption enabled through ssl_session_cache or ssl_session_tickets, and client certificate authentication performed by the default server.

The technical advisory describes reuse of an SSL session in unrelated virtual hosts, allowing the destination server block's client certificate requirement to be bypassed. The Debian backport discussion explains that, in OpenSSL, resumption occurs in the default SSL context before the SNI callback; this is the implementation condition behind cross-SNI session reuse. The flaw is classified as CWE-863, Incorrect Authorization, because the service may accept a session without applying the destination virtual host's intended authentication requirement. The record does not specify which endpoints or data become reachable after the check is bypassed, and it does not establish code execution, data modification, or host-level privilege escalation.

The vulnerability is reachable over the network on an affected listener. F5's supplied assessment characterizes the attack as low complexity, requiring no user interaction and low privileges; the attacker must still reach the listener and be able to reuse a session that matches the deployment conditions.

The supplied record lists public_exploit as false. CISA coordinator data returned with the record marks exploitation as none and automatable as no. These are statuses recorded by the available sources, not proof that exploitation has not occurred outside that reporting scope. No specific exploit code, campaign, victim, or IOC is confirmed in the evidence reviewed.

The primary technical outcome is an authorization bypass involving client certificate authentication when a session is reused in an inappropriate virtual host context. A client with a suitable session may be processed by NGINX as having satisfied the destination server block's certificate requirement, although application-level authorization may still block access.

The confirmed impact is primarily a risk of unauthorized information access within resources protected by client certificates. The record does not establish an integrity or availability impact, does not describe code execution, and does not prove privilege escalation beyond bypassing the client certificate requirement. Actual impact depends on shared-listener configuration, the default server, session-resumption behavior, and authorization controls behind NGINX.

The flaw can weaken authentication boundaries between virtual hosts sharing a listener, allowing a request to be processed without satisfying the destination host's client certificate requirement. This may expose endpoints or data protected by client certificates and may weaken separation between services or tenants on the same listener.

The available evidence does not confirm a breach, data disclosure, or successful access to a particular system. The issue is not described as enabling data modification, code execution, or denial of service; actual consequences depend on the application's subsequent authorization controls.

1. Upgrade NGINX Open Source: use a branch point marked unaffected by F5, 1.26.3 or 1.27.4, as appropriate for the maintained branch in use. Do not treat a fix in one branch as evidence that every parallel branch is fixed.
2. Upgrade NGINX Plus: use the branch point marked unaffected by F5, R32 P2 or R33 P2, as appropriate for the deployed release branch.
3. For Debian packages: on bookworm, apply package 1.22.1-9+deb12u1; on bullseye, apply package 1.18.0-6.1+deb11u4 or a later Debian security update that Debian explicitly confirms as resolving the issue.
4. If an upgrade is not immediately possible, follow F5's documented configuration mitigation for the specific deployment. The available evidence says the issue can be mitigated by configuration but does not provide enough detail to validate a particular setting as a safe workaround. Do not assume that disabling only one session-resumption mechanism is sufficient without testing the complete listener and all server blocks.
5. After the change, retest client certificate enforcement on the default server and each named server block using both new connections and resumed sessions.

1. Inventory F5 NGINX Open Source and NGINX Plus deployments, including operating-system packages, and compare them with the affected and unaffected boundaries in Affected Summary.
2. Inspect listener configuration for multiple server blocks sharing an IP address and port. Identify the default server and record the hostnames or SNI names served by that listener.
3. Confirm whether the default server performs client certificate authentication, and check whether ssl_session_cache or ssl_session_tickets is enabled together with OpenSSL.
4. In a controlled test environment, verify that each named server block continues to require the expected client certificate after both a full TLS handshake and session resumption. Test transitions between the default server and each SNI host separately.
5. Review access and authentication logs as a precaution for requests accepted by resources that should require a client certificate but lack corresponding certificate-authentication evidence. This is a general review direction, not a vendor-confirmed IOC.