CVE-2026-19553

Executive Summary

CVE-2026-19553 is a missing-parameter-validation defect in Python's ssl module: ssl.SSLContext.wrap_bio() did not require server_hostname to be non-None when ssl.SSLContext.check_hostname was enabled, and a corresponding missing check in SSLObject caused hostname verification to be silently skipped. Any program that enables check_hostname = True but fails to pass a valid, non-empty server_hostname will believe it is performing certificate hostname verification when it is not — a trust-verification bypass that weakens TLS server authentication (CWE-297, improper validation of certificate with host mismatch). Because wrap_bio() is the non-blocking socket layer used by higher-level APIs, callers of asyncio-based connection and TLS upgrade paths that omit server_hostname are the primary exposure group.

Technical Analysis

TLS server authentication has two components: (1) validating the certificate chain to a trusted CA, and (2) verifying that the certificate presented matches the hostname the client intended to reach. The second component — hostname verification — is what prevents an attacker holding any validly-issued certificate (or a certificate for an attacker-controlled name) from impersonating a target service. Python exposes this via the security-posture switch ssl.SSLContext.check_hostname. When check_hostname is enabled, the library contract is that a hostname must be supplied so that a match can be evaluated; otherwise the developer has configured an inconsistent security state, and the library should refuse to proceed.

In the affected code path, ssl.SSLContext.wrap_bio() did not enforce that server_hostname was non-None while check_hostname was set, and a missing parameter check in SSLObject meant the verification step was never entered. The result documented in the NVD description is a silent skip of hostname verification rather than a hard failure. This is a failure-mode flaw: the program’s observable behavior — SSLContext.check_hostname = True, no exception raised — appears to confirm that verification ran, but no hostname comparison occurred. The security control is present in configuration but absent in execution.

Key scoping facts from the description:

• Verification proceeds normally and the program is unaffected if a server_hostname value that is not an empty string and not None is passed to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls().
• The flaw is in the parameter-validation / control-flow gating of verification, not in the cryptographic chain validation itself.
• Upgrading or patching changes behavior only from "silently skip hostname verification" to "raise ValueError" — i.e., it converts a silent misconfiguration into a loud one, aligning with ssl.SSLContext.wrap_socket().

The vulnerable surface is therefore any application, framework, async client, or library that builds a TLS session through wrap_bio()/asyncio connection or TLS-upgrade APIs with check_hostname enabled but a missing or empty server_hostname. No specific code snippet beyond the named APIs is available; per accuracy constraints, no additional function names, endpoints, or file paths are asserted here.

Exploitation Scenarios

No public PoC or exploit code is available; the attack chain below is inferred strictly from the vulnerability class described in the NVD advisory.

1. Reconnaissance / target identification. The attacker identifies an application that negotiates TLS using Python's asynchronous or I/O-buffer APIs (ssl.SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls()) with SSLContext.check_hostname = True but no meaningful server_hostname. This is a configuration/usage condition rather than a remotely fuzzable endpoint; identification is typically via source review, dependency analysis, or observed development patterns, not active scanning.

2. Triggering the flaw class. The client establishes a TLS session to a server. Because server_hostname is None or empty, the missing check in SSLObject means the hostname-matching routine is never performed. check_hostname remains True, so no exception surfaces — the caller believes hostname verification succeeded.

3. Execution method (man-in-the-middle). An adversary positioned to intercept the connection (same network, hostile Wi-Fi, DNS spoofing, ARP/route manipulation, or a compromised intermediate) presents a certificate that is not valid for the intended hostname. Chain validation may still fail unless the attacker uses a certificate chaining to a CA the client trusts, or exploits a permissive trust store. Where a validly-issued certificate for an attacker-controlled name (or any certificate accepted by the client's trust configuration) is presented, the hostname mismatch is not detected, and the attacker terminates the TLS session as if it were the genuine server. The attack therefore degrades to "TLS without hostname binding."

4. Post-exploitation impact. With the TLS channel successfully impersonated, the attacker can read and modify traffic in transit and harvest credentials, session tokens, and API secrets. The appearance of successful verification (check_hostname = True, no error) means defensive logging will not flag the event, and operators may have no indication the trust control failed. Impact is confidentiality and integrity compromise of all data flowing over the affected client connections, with potential credential theft enabling lateral movement or broader account takeover.

Impact Assessment

• Vulnerability class (CWE-297): improper validation of certificate with host mismatch — a trust/authentication control bypass.
• Impacted parties: developers and operators of Python applications that enable SSLContext.check_hostname while omitting a valid server_hostname in the affected APIs. Applications that pass a valid non-None, non-empty server_hostname are not affected.
• CVSS subscores: Not applicable — NVD has not assigned a CVSS score or vector for this CVE. No EPSS score has been published by FIRST.org; no EPSS value is asserted here.
• Blast radius: Scoped to client-side TLS hostname verification for the specific calling patterns described. It does not affect certificate-chain validation independent of hostname checking, nor deployments that never enable check_hostname, nor callers that supply a proper hostname.
• Business impact: Exposure to man-in-the-middle interception on affected client channels; credential and sensitive-data disclosure; integrity loss on intercepted sessions. Because the failure is silent, the control-gap may persist undetected across many deployments, and audit/"verification passed" assertions may be unreliable for the affected code paths.
• Exploit availability: None public. No Nuclei template, no exploit code, no CISA KEV listing. Exploitation requires the application-specific misconfiguration plus a network-positioned adversary.

Detection Guidance

Detection centers on the usage pattern (applications invoking the affected APIs with check_hostname = True and no server_hostname) and on network evidence of TLS sessions whose certificate does not match the intended hostname. There are no exploit-specific packet signatures because this is a library-side defect.

Sigma Rule

title: Python TLS Hostname Verification Skipped - wrap_bio Without server_hostname
id: 6f1c2a90-1c6e-4b2a-9d0e-cve202619553
status: experimental
description: Detects Python process execution patterns indicating TLS sessions established via wrap_bio/asyncio without a server_hostname while check_hostname is enabled (CVE-2026-19553 usage indicator).
logsource:
  category: process_creation
  product: linux
detection:
  selection_python:
    Image|endswith:
      - '/python'
      - '/python3'
      - '/python3.11'
      - '/python3.12'
  selection_flags:
    CommandLine|contains:
      - 'wrap_bio'
      - 'start_tls'
      - 'create_connection'
  condition: selection_python and selection_flags
fields:
  - Image
  - CommandLine
  - User
falsepositives:
  - Legitimate applications passing a valid server_hostname (not affected)
level: low
tags:
  - attack.t1553
  - cve.2026.19553

YARA Rule

rule CVE_2026_19553_SSL_Hostname_Skip_Usage
{
    meta:
        description = "Detects Python source referencing wrap_bio with check_hostname enabled and no server_hostname (CVE-2026-19553 usage indicator)"
        cve = "CVE-2026-19553"
        author = "Threat Intelligence"
        severity = "medium"
    strings:
        $a = "wrap_bio"
        $b = "check_hostname"
        $c = "server_hostname"
        $d = "start_tls"
        $e = "create_connection"
    condition:
        $a and $b and not $c
}

Suricata IDS Rule

alert tls any any -> any any (msg:"CVE-2026-19553 Potential TLS Hostname Verification Bypass (client session to mismatched cert subject)"; flow:established,to_server; tls.subject; content:"CN="; sid:202619553; rev:1; reference:cve,2026-19553; classtype:bad-unknown;)

Elastic Detection

process where event.type == "start" and process.name : ("python", "python3") and
  process.command_line : ("*wrap_bio*" or "*start_tls*" or "*create_connection*")

Splunk SPL Query

index=endpoint OR index=process (process_name=python OR process_name=python3)
| where match(command_line, "(wrap_bio|start_tls|create_connection)")
| stats count by host, user, command_line
| sort - count

Wazuh OSSEC Rule

<group name="cve_2026_19553,python_tls,">
  <rule id="100953" level="4">
    <decoded_as>json</decoded_as>
    <match>wrap_bio|start_tls|create_connection</match>
    <description>CVE-2026-19553: Python TLS API usage indicating possible skipped hostname verification (check_hostname without server_hostname)</description>
    <mitre>
      <id>T1553</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1) Immediate mitigations (do not require updating Python or applying a patch).

• Pass a valid server_hostname value — not None and not an empty string — to ssl.SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls(). When a proper hostname is supplied, certificate hostname verification proceeds as expected and the program is not affected.
• Audit code paths and dependencies that set SSLContext.check_hostname = True; locate every call to the three named APIs and confirm a correct server_hostname is threaded through.
• Where feasible, fail closed in application code: explicitly raise if server_hostname is missing/empty while check_hostname is enabled.

2) Patch / upgrade steps.

• No patch or fixed version is identified in any tracked source (confidence 0/4). Upgrading to a fixed Python release or applying the eventual patch changes behavior only from silently skipping hostname verification to raising ValueError (mirroring ssl.SSLContext.wrap_socket()) when server_hostname is absent. Monitor the Python security advisories and NVD entry for CVE-2026-19553 for an official fix and version reference before planning upgrades.

3) Long-term hardening.

• Standardize on TLS client wrappers that require a non-empty hostname whenever check_hostname is enabled, and enforce this in code review and static analysis.
• Treat "no ValueError" as insufficient evidence of verification; add positive assertions/tests that hostname verification actually runs.
• Maintain an inventory of asyncio/ssl TLS call sites and pin/monitor the Python runtime version.
• Prefer pinned, current Python runtimes and integrate dependency and runtime CVE monitoring into CI/CD.

References

• NVD — CVE-2026-19553: https://nvd.nist.gov/vuln/detail/CVE-2026-19553
• CWE-297 — Improper Validation of Certificate with Host Mismatch: https://cwe.mitre.org/data/definitions/297.html
• MITRE ATT&CK — T1553 Subversion of Trust Control: https://attack.mitre.org/techniques/T1553/
• Python ssl module documentation (SSLContext.wrap_bio, SSLContext.wrap_socket, check_hostname): https://docs.python.org/3/library/ssl.html
• Python asyncio documentation (create_connection, loop.start_tls): https://docs.python.org/3/library/asyncio.html
• CISA Known Exploited Vulnerabilities catalog (CVE-2026-19553 not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No threat actor campaign, exploit-in-the-wild evidence, public PoC, or Nuclei template is associated with this CVE in the available data.