CWE-297
Improper Validation of Certificate with Host Mismatch
Produkt komunikuje się z hostem dostarczającym certyfikat, ale nie zapewnia prawidłowo, że certyfikat jest faktycznie powiązany z tym hostem. Brak właściwej walidacji może prowadzić do zagrożeń bezpieczeństwa związanych z podszywaniem się i atakami man-in-the-middle.
The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.
W aplikacji AVTECH EagleEyes 2.0.0 wykryto krytyczną podatność polegającą na całkowitym wyłączeniu walidacji nazwy hosta podczas połączeń HTTPS. Umożliwia to atakującemu przeprowadzenie ataku Man-in-the-Middle i przechwycenie lub zmodyfikowanie szyfrowanego ruchu sieciowego.
W bibliotece Bouncy Castle for Java mechanizm CN-fallback w weryfikatorze hostname JSSE jest domyślnie włączony, mimo że dokumentacja traktuje go jako opcjonalny. Umożliwia to atakującemu przeprowadzenie ataku man-in-the-middle poprzez podstawienie certyfikatu z pasującym polem CN zamiast wymaganego SAN.
Snowflake Connector for Python w wersjach przed 4.7.1 i 3.18.1 nieprawidłowo weryfikował nazwę hosta w certyfikatach TLS, umożliwiając atakującemu znajdującemu się na ścieżce sieciowej ominięcie walidacji certyfikatu. Podatność może prowadzić do przechwycenia danych uwierzytelniających, zapytań SQL oraz wykonania dowolnych poleceń SQL w sesji ofiary.
erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify => false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify => true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents.
Podatność w bibliotekach c_glib frameworka Apache Thrift polega na nieprawidłowej walidacji certyfikatu TLS w kontekście zgodności z nazwą hosta. Umożliwia to atakującemu przeprowadzenie ataku man-in-the-middle, co przy ocenie CVSS 9.1 (CRITICAL) stanowi poważne zagrożenie dla poufności i integralności przesyłanych danych.
Galaxy FDS Android SDK w wersji 3.0.8 i wcześniejszych wyłącza weryfikację nazwy hosta TLS, akceptując dowolny ważny certyfikat niezależnie od niezgodności hostname. Oznacza to, że wszystkie aplikacje korzystające z SDK z domyślną konfiguracją są podatne na przechwycenie i modyfikację ruchu sieciowego przez atakującego w pozycji man-in-the-middle.
Klient HTTP Apache Uniffle domyślnie ufa wszystkim certyfikatom SSL i wyłącza weryfikację nazwy hosta, co naraża całą komunikację REST API na ataki Man-in-the-Middle. Podatność jest krytyczna, ponieważ nie wymaga uwierzytelnienia ani interakcji użytkownika.
SAP Cloud Connector w wersji 2.0 akceptuje połączenia z backendem bez odpowiedniej weryfikacji certyfikatu TLS. Podatność umożliwia atakującemu przeprowadzenie ataku typu man-in-the-middle, co stanowi poważne zagrożenie dla poufności i integralności przesyłanych danych.
Osquery w wersjach od 2.9.0 do 4.2.0 nieprawidłowo waliduje nazwę hosta TLS SNI, co umożliwia atakującemu przeprowadzenie ataku man-in-the-middle na ruch sieciowy generowany przez osquery. Podatność jest krytyczna, ponieważ nie wymaga uwierzytelnienia ani interakcji użytkownika.
Biblioteka Java-WebSocket w wersjach do 1.4.1 włącznie nie weryfikuje, czy nazwa hosta w certyfikacie SSL odpowiada rzeczywistemu hostowi serwera. Umożliwia to atakującemu przeprowadzenie ataku typu Man-in-the-Middle (MITM) na szyfrowane połączenia WebSocket.
It was identified that the LDAP client implementation in version 2.1.7 does not verify if the server certificate matches the intended LDAP hostname. While the underlying code validates the certificate chain against a trusted authority, the absence of endpoint identification allows a valid certificate issued for an entirely unrelated host to be improperly accepted. This oversight leaves the connection highly vulnerable to server impersonation and complete connection compromise. The root cause of this vulnerability lies in the incomplete TLS server identity verification within the LDAP client implementation. The attacker requires MITM capability on the network to exploit this vulnerability. This attacker must be able to present a certificate trusted by the client's configured trust store. The hostname verification has been enforced in the new version of the LDAP API
Mifos-Mobile Android Application for MifosX is an Android Application built on top of the MifosX Self-Service platform. Mifos-Mobile before commit e505f62 disables HTTPS hostname verification of its HTTP client. Additionally it accepted any self-signed certificate as valid. Hostname verification is an important part when using HTTPS to ensure that the presented certificate is valid for the host. Disabling it can allow for man-in-the-middle attacks. Accepting any certificate, even self-signed ones allows man-in-the-middle attacks. This problem is fixed in mifos-mobile commit e505f62.
Netty (io.netty:netty-handler) versions from 4.2.0.Final through 4.2.16.Final and versions through 4.1.136.Final disable TLS hostname verification on the SslProvider.OPENSSL client path when a plain (non-extended) X509TrustManager is used and Unsafe-based trust-manager wrapping is unavailable (Java 25+). In this configuration the OpenSSL client does not perform hostname verification, allowing a man-in-the-middle attacker to present a certificate issued for a different hostname that is accepted without validation. Fixed in 4.2.17.Final and 4.1.137.Final.
Biblioteka Apache Thrift w wariancie dla języka C++ nie weryfikuje poprawnie, czy certyfikat TLS pochodzi od hosta, z którym nawiązywane jest połączenie. Umożliwia to atakującemu przeprowadzenie ataku typu man-in-the-middle i przechwycenie poufnych danych przesyłanych w komunikacji.
A flaw was found in Keycloak. By setting a verification policy to 'ALL', the trust store certificate verification is skipped, which is unintended.
The mobile application (com.transsnet.store) has a man-in-the-middle attack vulnerability, which may lead to code injection risks.
Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.
A weakness was found in postgresql-jdbc before version 42.2.5. It was possible to provide an SSL Factory and not check the host name if a host name verifier was not provided to the driver. This could lead to a condition where a man-in-the-middle attacker could masquerade as a trusted server by providing a certificate for the wrong host, as long as it was signed by a trusted CA.
Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_cert and public_key modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification. Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com): First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName. Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback. The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verify_peer, a trusted CA, SNI, and the canonical strict https hostname matcher. This issue affects OTP from OTP 19.3 before OTP 29.0.1, OTP 28.5.0.1, OTP 27.3.4.12 and OTP 26.2.5.21, corresponding to public_key from 1.4 before 1.21.1, 1.20.3.1, 1.17.1.3 and 1.15.1.7.
TLS hostname verification issue in Apache Ranger Client Code in versions <= 2.8.0. Users are recommended to upgrade to version 2.9.0, which fixes this issue.