CVE-2026-27448

What it actually does

This flaw affects applications using pyOpenSSL versions from 0.14.0 before 26.0.0 when they register a user-defined TLS Server Name Indication callback with set_tlsext_servername_callback. If that callback raises an unhandled exception, pyOpenSSL incorrectly allows the TLS connection to proceed instead of rejecting it. The vulnerability does not create a universal authentication bypass by itself; impact depends on whether the application uses the callback to enforce security decisions such as hostname allowlists, virtual-host isolation, client policy selection, certificate selection, tenant routing, or other access controls. Exploitation requires an attacker to trigger an exception in the callback logic, which is why the attack complexity is high and the practical impact is application-specific.

Why it matters to the business

Organizations using affected pyOpenSSL versions may have services that unintentionally accept TLS connections that should have been denied. If the callback protects access to sensitive endpoints, tenant-specific services, restricted hostnames, or policy-controlled TLS configurations, attackers could bypass intended controls and reach services that operators believed were protected. The current public exploitation signal is low: EPSS is 0.241%, the issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no mature public exploit is indicated; however, affected internet-facing services should still be reviewed because the consequence depends on local callback behavior.

How an attack unfolds

An attacker first identifies a TLS service implemented with a vulnerable pyOpenSSL version and using set_tlsext_servername_callback for security-sensitive decision-making. The attacker then studies how the application handles the TLS SNI value or related connection metadata. By sending a specially chosen, malformed, unexpected, empty, oversized, encoded, or otherwise edge-case server name, the attacker attempts to trigger an unhandled exception inside the application-provided callback. In affected pyOpenSSL versions, that exception does not fail closed; instead, the TLS connection is accepted. If the callback was responsible for rejecting unauthorized hostnames or selecting restrictive security policy, the attacker may gain access to a path that should have been blocked. Follow-on impact depends on the service behind the TLS listener and may range from policy bypass to unauthorized access to application functionality.

How to fix it

Upgrade pyOpenSSL to version 26.0.0 or later, where unhandled exceptions in set_tlsext_servername_callback result in rejecting the connection. Because the supplied fixed_versions field is empty, use the upstream advisory version as the minimum fixed version: pyOpenSSL >= 26.0.0. In addition, review all uses of set_tlsext_servername_callback and ensure callback logic fails closed: catch expected exceptions, explicitly reject unsafe or unexpected SNI values, validate input before use, and avoid relying on exception side effects for access control. If immediate upgrade is not possible, add defensive exception handling inside the callback so any error path explicitly denies the connection or applies the most restrictive policy. Consider moving security-critical authorization decisions out of TLS callback logic where feasible, or enforcing them again at the application layer after TLS negotiation.

How to confirm the fix worked

Confirm that all deployed Python environments, containers, virtual environments, and packaged applications use pyOpenSSL 26.0.0 or later. Validate with package inventory commands such as `python -m pip show pyOpenSSL`, dependency lockfiles, SBOMs, container image scans, and runtime introspection where appropriate. Search code for `set_tlsext_servername_callback` and verify whether the callback performs security-sensitive decisions. Test the service with benign malformed or unexpected SNI values in a staging environment and confirm that exceptions or validation failures cause the TLS handshake to fail closed rather than allowing the connection. Review regression tests to ensure callback exceptions are covered and denied by default.

Typical attack path

1. Identify a Python TLS service using pyOpenSSL and accepting network connections.
2. Determine or infer that the service uses TLS SNI-based callback logic for hostname routing, policy enforcement, access control, or certificate selection.
3. Send TLS ClientHello messages with crafted SNI values intended to trigger an exception in the callback code.
4. Cause the callback to raise an unhandled exception during TLS negotiation.
5. Rely on vulnerable pyOpenSSL behavior that accepts the connection rather than rejecting it.
6. Access the service or policy context that the callback was intended to deny or restrict.
7. Attempt further application-level interaction using the now-established TLS connection.

How to detect it

To determine whether exploitation may already have occurred, focus on services that both use vulnerable pyOpenSSL versions and implement set_tlsext_servername_callback. Review application logs around TLS handshake handling for unhandled exceptions, tracebacks, or callback errors followed by successful connections from the same source. Correlate TLS access logs, reverse proxy logs, load balancer logs, packet captures, and application authentication logs for connections using unusual, malformed, empty, unexpected, or unauthorized SNI hostnames that were nonetheless accepted. Look for spikes in TLS handshake attempts with varied SNI values, particularly from single sources or scanner infrastructure. If callback exceptions are logged, investigate whether the same client IP subsequently accessed restricted routes, tenant-specific services, administrative interfaces, or hostnames that should have been rejected. Because pyOpenSSL does not provide a universal exploit artifact for this issue, detection is primarily behavioral and application-log dependent.

What your security team should do

• Inventory all services, containers, and Python environments using pyOpenSSL, prioritizing internet-facing TLS services.
• Upgrade pyOpenSSL to 26.0.0 or later wherever present.
• Search codebases for `set_tlsext_servername_callback` and prioritize review of callbacks used for access control, tenant isolation, hostname allowlisting, routing, or certificate/policy selection.
• Add explicit fail-closed exception handling in all TLS SNI callbacks, even after upgrading, to reduce application-layer risk.
• Test affected services with invalid, missing, unexpected, and boundary-case SNI values to confirm connections are rejected when callback logic fails.
• Monitor TLS services for unusual SNI probing, malformed ClientHello activity, repeated handshake anomalies, or access to restricted hostnames.
• Because this issue is not in KEV and has low EPSS with no known mature exploit, prioritize based on exposure and whether the callback enforces security-sensitive behavior rather than treating all installations as equally critical.