CVE-2026-19445: Use-after-free of a server-side SSLContext when sni_callback switches contexts
A remote, unauthenticated TLS client can make a server crash or call through a freed pointer if its snicallback assigns a different context to SSLSocket.context (the documented way to select a certificate per server name) and nothing else keeps the original ssl.SSLContext alive. Typical cases are servers that create an SSLContext per connection or replace it while connections are open; servers that wrap their listening socket with it are not affected.
Mitigation: keep a reference to every SSLContext that sets snicallback for the lifetime of the server. TLS clients are not affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Keep a reference to every server-side ssl.SSLContext that sets sni_callback for the lifetime of the server, including contexts assigned through SSLSocket.context, so the original context remains alive while connections are open.
Event History
Frequently Asked Questions
Which deployments are exposed?
Server-side Python TLS deployments are exposed only when an sni_callback changes SSLSocket.context and the original SSLContext is not kept alive. Servers that wrap their listening socket with the SSLContext are not affected, and TLS clients are not affected.
What does an attacker need to exploit this?
An attacker only needs to be a remote, unauthenticated TLS client. Exploitation depends on the server using the affected SNI callback context-switching pattern.
What can be done if patching is not immediately possible?
Keep a reference to every SSLContext that sets sni_callback for the full lifetime of the server. Avoid per-connection SSLContext creation or replacing contexts while connections remain open unless the original contexts are retained.