Monthly
Outbound TLS connections initiated by Progress MarkLogic Server can be intercepted and modified by an on-path attacker because the product does not consistently validate the certificate hostname for certain outbound connections (CWE-297). Affected are 12.x releases before 12.1.0 and 11.x releases before 11.3.7; the vulnerability is unauthenticated from the attacker's perspective (CVSS:3.1/AV:N/AC:H/PR:N/UI:N) but requires the attacker to first occupy a man-in-the-middle position - for example via ARP or DNS spoofing, a rogue gateway, or control of intermediate network infrastructure - and requires MarkLogic to actually open one of the specific outbound connections that skip hostname verification. Impact is limited to confidentiality and integrity of those communications (C:H/I:H) with no availability impact and no code execution; no public exploit code or active exploitation has been identified at time of analysis.
Man-in-the-middle attackers can impersonate any TLS server contacted by Apache CXF's optional Netty-based HTTP client transport, because cxf-rt-transports-http-netty-client validates the server certificate chain against the configured trust store but never checks that the certificate's hostname matches the host actually being called - a gap present over both HTTP/1.1 and HTTP/2 and present even with disableCNCheck left at its secure default of false. Applications running Apache CXF before 3.6.13, 4.1.9 or 4.2.4 that use this transport for outbound TLS calls are affected; an unauthenticated attacker who already holds a traffic-interception position and any certificate issued by a CA in the client's trust store (for example, a free publicly issued certificate for an attacker-controlled domain) can read or modify exchanged messages and credentials. No public exploit identified at time of analysis, and exploitation is gated by the requirement for an on-path MITM position plus a trusted-chain certificate, which is reflected in our assessed vector returning High attack complexity rather than the published AC:L; EPSS is correspondingly low at 0.11% (1st percentile), so this is a serious TLS trust failure rather than an immediate mass-exploitation priority. Vendor fixes are available in 3.6.13, 4.1.9 and 4.2.4.
Man-in-the-middle attackers can bypass certificate hostname verification in GnuTLS 3.8.13, letting them impersonate the intended TLS server and eavesdrop on client communications that should have been protected by certificate validation. Exploitation requires the attacker to already occupy a MITM position between a GnuTLS 3.8.13 client and its intended server and to supply a crafted certificate that is mishandled on the Common Name fallback path; no victim action beyond completing a normal TLS handshake is required, but the flaw does not permit compromise of an arbitrary host without traffic interception. Published severity is 9.1, while our independent assessment is more conservative (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, roughly 8.1) because of that MITM prerequisite; EPSS is 0.11% (1st percentile), there is no CISA KEV listing, and no public exploit code was identified at time of analysis, though a GitHub Gist is cited among the references with unconfirmed content.
Certificate hostname verification is silently skipped in CPython's TLS stack when an application enables SSLContext.check_hostname but supplies no server_hostname (None or an empty string) to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls(). In that exact state SSLObject still validates the certificate chain but never matches the peer's identity against the requested name, so an unauthenticated attacker holding a man-in-the-middle position on the connection path and a certificate chaining to a CA the client trusts can intercept traffic while the program believes hostname checking succeeded. Exploitation is gated by two independent conditions - the application-side misconfiguration and an active network-intercept position - no public exploit code has been identified at time of analysis, and applications that pass a valid non-empty server_hostname are completely unaffected regardless of patch status.
Improper TLS hostname validation in the MQTT client layer of AWS IoT Device SDK for Python (AWSIoTPythonSDK) 1.5.3 through 1.6.0 running on Python 3.7 and later allows an adversary-in-the-middle who possesses a certificate issued for an unrelated hostname by a certificate authority already in the device trust store to impersonate the AWS IoT Core endpoint, read device telemetry, and inject MQTT messages that the device processes as authentic. This is not exploitable from an arbitrary internet location: the attacker must hold an on-path position and a trusted-CA certificate for an unrelated hostname. No public exploit was identified at time of analysis, and the vendor has released 1.6.1 to enforce hostname verification.
Improper certificate hostname validation in Apache ZooKeeper's quorum TLS path allows a CA-trusted peer certificate whose SAN does not match the connected host to be accepted when FIPS mode and quorum hostname verification are enabled, letting the holder of such a certificate join quorum traffic, participate in leader election, and enter replication flows. Only deployments that simultaneously set sslQuorum=true, zookeeper.fips-mode=true, ssl.quorum.hostnameVerification=true and ssl.quorum.clientHostnameVerification=true on affected releases (3.8.0 through 3.8.6 and 3.9.0 through 3.9.5) are exposed; plain TLS and non-quorum-TLS ensembles are unaffected. Exploitation additionally requires a certificate chaining to a CA already trusted by the quorum truststore, so the practical barrier is high; no public exploit code has been identified at time of analysis, and EPSS is 0.12% (2nd percentile). Unauthenticated remote attackers are in scope per the CVSS vector (PR:N), though the certificate precondition makes real-world abuse a targeted rather than opportunistic scenario.
Certificate hostname validation failure in Dell Secure Connect Gateway (SCG) 5.0 enables an unauthenticated remote attacker positioned as a network man-in-the-middle to present a valid TLS certificate for a different host, defeating the connection's trust model and gaining unauthorized access to intercepted communications. Both the Appliance variant (prior to 5.36.00.16) and Application variant (prior to 5.36.00.00) are confirmed affected per Dell DSA-2026-382. No public exploit or CISA KEV listing has been identified at time of analysis; the AC:H CVSS metric reflects the non-trivial network positioning prerequisite.
Improper certificate hostname validation (CWE-297) in Fortinet FortiOS and FortiProxy enables network-adjacent attackers to conduct man-in-the-middle attacks against outbound TLS connections made by affected devices. Fortinet FortiOS versions 7.6.1 through 7.6.6 and FortiProxy 7.6.2 through 7.6.6 fail to verify that a presented certificate matches the intended hostname, allowing a suitably positioned attacker to intercept and potentially tamper with encrypted traffic. Proof-of-concept code exists (E:P in temporal CVSS), and an official fix has been released per vendor advisory FG-IR-26-174.
TLS hostname verification is silently bypassed in Netty's OpenSSL client path, allowing a network man-in-the-middle attacker to intercept encrypted communications by presenting a certificate issued for a different hostname. Affected are applications using io.netty:netty-handler versions 4.2.0.Final through 4.2.16.Final or any 4.1.x through 4.1.136.Final, specifically when the SslProvider.OPENSSL client path is configured with a plain X509TrustManager and running on Java 25 or later, where Unsafe-based trust-manager wrapping is unavailable. No public exploit code has been identified at time of analysis, but the confidentiality impact is high for any affected deployment that transmits sensitive data over TLS.
TLS hostname verification failure in Apache Ranger Client Code allows network-positioned attackers to intercept sensitive traffic via man-in-the-middle attacks against all deployments running version 2.8.0 or earlier. The client fails to validate that a server's TLS certificate hostname matches the actual server being contacted (CWE-297), meaning a forged or mismatched certificate will be accepted silently. A vendor-released patch is available in version 2.9.0; no public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Outbound TLS connections initiated by Progress MarkLogic Server can be intercepted and modified by an on-path attacker because the product does not consistently validate the certificate hostname for certain outbound connections (CWE-297). Affected are 12.x releases before 12.1.0 and 11.x releases before 11.3.7; the vulnerability is unauthenticated from the attacker's perspective (CVSS:3.1/AV:N/AC:H/PR:N/UI:N) but requires the attacker to first occupy a man-in-the-middle position - for example via ARP or DNS spoofing, a rogue gateway, or control of intermediate network infrastructure - and requires MarkLogic to actually open one of the specific outbound connections that skip hostname verification. Impact is limited to confidentiality and integrity of those communications (C:H/I:H) with no availability impact and no code execution; no public exploit code or active exploitation has been identified at time of analysis.
Man-in-the-middle attackers can impersonate any TLS server contacted by Apache CXF's optional Netty-based HTTP client transport, because cxf-rt-transports-http-netty-client validates the server certificate chain against the configured trust store but never checks that the certificate's hostname matches the host actually being called - a gap present over both HTTP/1.1 and HTTP/2 and present even with disableCNCheck left at its secure default of false. Applications running Apache CXF before 3.6.13, 4.1.9 or 4.2.4 that use this transport for outbound TLS calls are affected; an unauthenticated attacker who already holds a traffic-interception position and any certificate issued by a CA in the client's trust store (for example, a free publicly issued certificate for an attacker-controlled domain) can read or modify exchanged messages and credentials. No public exploit identified at time of analysis, and exploitation is gated by the requirement for an on-path MITM position plus a trusted-chain certificate, which is reflected in our assessed vector returning High attack complexity rather than the published AC:L; EPSS is correspondingly low at 0.11% (1st percentile), so this is a serious TLS trust failure rather than an immediate mass-exploitation priority. Vendor fixes are available in 3.6.13, 4.1.9 and 4.2.4.
Man-in-the-middle attackers can bypass certificate hostname verification in GnuTLS 3.8.13, letting them impersonate the intended TLS server and eavesdrop on client communications that should have been protected by certificate validation. Exploitation requires the attacker to already occupy a MITM position between a GnuTLS 3.8.13 client and its intended server and to supply a crafted certificate that is mishandled on the Common Name fallback path; no victim action beyond completing a normal TLS handshake is required, but the flaw does not permit compromise of an arbitrary host without traffic interception. Published severity is 9.1, while our independent assessment is more conservative (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, roughly 8.1) because of that MITM prerequisite; EPSS is 0.11% (1st percentile), there is no CISA KEV listing, and no public exploit code was identified at time of analysis, though a GitHub Gist is cited among the references with unconfirmed content.
Certificate hostname verification is silently skipped in CPython's TLS stack when an application enables SSLContext.check_hostname but supplies no server_hostname (None or an empty string) to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls(). In that exact state SSLObject still validates the certificate chain but never matches the peer's identity against the requested name, so an unauthenticated attacker holding a man-in-the-middle position on the connection path and a certificate chaining to a CA the client trusts can intercept traffic while the program believes hostname checking succeeded. Exploitation is gated by two independent conditions - the application-side misconfiguration and an active network-intercept position - no public exploit code has been identified at time of analysis, and applications that pass a valid non-empty server_hostname are completely unaffected regardless of patch status.
Improper TLS hostname validation in the MQTT client layer of AWS IoT Device SDK for Python (AWSIoTPythonSDK) 1.5.3 through 1.6.0 running on Python 3.7 and later allows an adversary-in-the-middle who possesses a certificate issued for an unrelated hostname by a certificate authority already in the device trust store to impersonate the AWS IoT Core endpoint, read device telemetry, and inject MQTT messages that the device processes as authentic. This is not exploitable from an arbitrary internet location: the attacker must hold an on-path position and a trusted-CA certificate for an unrelated hostname. No public exploit was identified at time of analysis, and the vendor has released 1.6.1 to enforce hostname verification.
Improper certificate hostname validation in Apache ZooKeeper's quorum TLS path allows a CA-trusted peer certificate whose SAN does not match the connected host to be accepted when FIPS mode and quorum hostname verification are enabled, letting the holder of such a certificate join quorum traffic, participate in leader election, and enter replication flows. Only deployments that simultaneously set sslQuorum=true, zookeeper.fips-mode=true, ssl.quorum.hostnameVerification=true and ssl.quorum.clientHostnameVerification=true on affected releases (3.8.0 through 3.8.6 and 3.9.0 through 3.9.5) are exposed; plain TLS and non-quorum-TLS ensembles are unaffected. Exploitation additionally requires a certificate chaining to a CA already trusted by the quorum truststore, so the practical barrier is high; no public exploit code has been identified at time of analysis, and EPSS is 0.12% (2nd percentile). Unauthenticated remote attackers are in scope per the CVSS vector (PR:N), though the certificate precondition makes real-world abuse a targeted rather than opportunistic scenario.
Certificate hostname validation failure in Dell Secure Connect Gateway (SCG) 5.0 enables an unauthenticated remote attacker positioned as a network man-in-the-middle to present a valid TLS certificate for a different host, defeating the connection's trust model and gaining unauthorized access to intercepted communications. Both the Appliance variant (prior to 5.36.00.16) and Application variant (prior to 5.36.00.00) are confirmed affected per Dell DSA-2026-382. No public exploit or CISA KEV listing has been identified at time of analysis; the AC:H CVSS metric reflects the non-trivial network positioning prerequisite.
Improper certificate hostname validation (CWE-297) in Fortinet FortiOS and FortiProxy enables network-adjacent attackers to conduct man-in-the-middle attacks against outbound TLS connections made by affected devices. Fortinet FortiOS versions 7.6.1 through 7.6.6 and FortiProxy 7.6.2 through 7.6.6 fail to verify that a presented certificate matches the intended hostname, allowing a suitably positioned attacker to intercept and potentially tamper with encrypted traffic. Proof-of-concept code exists (E:P in temporal CVSS), and an official fix has been released per vendor advisory FG-IR-26-174.
TLS hostname verification is silently bypassed in Netty's OpenSSL client path, allowing a network man-in-the-middle attacker to intercept encrypted communications by presenting a certificate issued for a different hostname. Affected are applications using io.netty:netty-handler versions 4.2.0.Final through 4.2.16.Final or any 4.1.x through 4.1.136.Final, specifically when the SslProvider.OPENSSL client path is configured with a plain X509TrustManager and running on Java 25 or later, where Unsafe-based trust-manager wrapping is unavailable. No public exploit code has been identified at time of analysis, but the confidentiality impact is high for any affected deployment that transmits sensitive data over TLS.
TLS hostname verification failure in Apache Ranger Client Code allows network-positioned attackers to intercept sensitive traffic via man-in-the-middle attacks against all deployments running version 2.8.0 or earlier. The client fails to validate that a server's TLS certificate hostname matches the actual server being contacted (CWE-297), meaning a forged or mismatched certificate will be accepted silently. A vendor-released patch is available in version 2.9.0; no public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.