CVE-2026-19553
WysokieCVSS 7.6Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 33 - wyżej niż 33% wszystkich znanych CVE
Streszczenie
W Pythonie funkcja ssl.SSLContext.wrap_bio() nie wymagała, aby argument server_hostname był różny od None, gdy ustawiono ssl.SSLContext.check_hostname. Z powodu braku sprawdzenia parametru w SSLObject, jeśli server_hostname nie został podany, weryfikacja nazwy hosta była po cicho pomijana. Może to prowadzić do sytuacji, w której weryfikacja certyfikatu wydaje się działać przy check_hostname = True, mimo błędnej konfiguracji.
Ocena ryzyka
Aplikacje mogą być narażone na ataki man-in-the-middle, ponieważ weryfikacja nazwy hosta certyfikatu jest po cicho pomijana. Może to prowadzić do przechwycenia danych uwierzytelniających lub innych wrażliwych informacji.
Rekomendacja
Należy przekazywać prawidłową, niepustą i różną od None wartość server_hostname do SSLContext.wrap_bio(), asyncio.create_connection() lub asyncio.loop.start_tls(). Alternatywnie można zaktualizować Pythona do najnowszej wersji, co spowoduje zgłoszenie ValueError zamiast cichego pomijania weryfikacji.
Inne podatności w Python ssl module
Zobacz wszystkie- CVE-2026-115557Krytyczne
Moduł "ssl" w Pythonie otrzymał listę blokowanych znanych skompromitowanych certyfikatów, aby zapewnić bezpieczeństwo użytkowników nawet bez skonfigurowanego odwoływania certyfikatów. Znane skompromitowane certyfikaty są automatycznie odrzucane niezależnie od konfiguracji polityki SSLContext.
- CVE-2026-19445Krytyczne
Zdalny, nieuwierzytelniony klient TLS może spowodować awarię serwera lub wywołanie przez zwolniony wskaźnik, jeśli jego sni_callback przypisze inny kontekst do SSLSocket.context (udokumentowany sposób wyboru certyfikatu per nazwa serwera) i nic innego nie utrzymuje oryginalnego ssl.SSLContext przy życiu. Typowe przypadki to serwery tworzące SSLContext na połączenie lub zastępujące go, gdy połączenia są otwarte; serwery, które opakowują nim gniazdo nasłuchujące, nie są dotknięte. Obejście: trzymaj referencję do każdego SSLContext, który ustawia sni_callback, przez cały czas życia serwera. Klienci TLS nie są dotknięci.
Oryginalny opis (angielski, źródło NVD)
ssl.SSLContext.wrap_bio() didn't require the server_hostname argument to not be None if ssl.SSLContext.check_hostname was set. Due to a missing parameter check in SSLObject, if the server_hostname argument isn't supplied then hostname verification would be silently skipped. This defect could lead to programs where certificate hostname verification *appeared* to be succeeding with SSLContext.check_hostname = True and no ValueError being raised due to misconfiguration. If the program passes a server_hostname value that isn't an empty string or None to any of these APIs then certificate hostname verification proceeds as expected and the program is not affected by this vulnerability. Mitigating this vulnerability doesn't require updating Python or applying the patch. To mitigate, pass a valid non-None and non-empty server_hostname value to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls() and certificate hostname verification will proceed as expected. Upgrading to the latest version of Python or applying the patch only changes the behavior from silently skipping hostname verification to raising a ValueError, similar to SSLContext.wrap_socket(), when server_hostname isn't supplied.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS