CVE-2026-84032
IBM Guardium Data Protection 12.2.2 could allow a remote attacker to conduct a man-in-the-middle attack due to improper certificate validati
CVSS
5.6
Medium
EPSS
0.2%
p5
KEV
—
Exploit Today
1
0-100
Published: Oct 8, 2026 · Last modified: Oct 14, 2026 · CWE-295
0.1%EPSS · 30 days0.2%
2026-10-092026-11-05
IBM Guardium Data Protection 12.2.2 could allow a remote attacker to conduct a man-in-the-middle attack due to improper certificate validation.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-1233067.4 HIG—
———In JetBrains IntelliJ IDEA before 2026.3 improper checks allowed server certificates to be added to the trust store during headless runs5hCVE-2026-111494——
———Incorrect validation of TLS certificates in the MatchPoint Android app due to a TrustManager that accepts any certificate and a permissive hostname validator. Additionally, the app allows unencrypted HTTP traffic. An attacker capable of intercepting the victim's traffic could read and modify communications, including credentials and personal data.18hCVE-2026-1167897.4 HIG—
——0FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to 1.11.2, dtls_state_setup() compared a peer certificate with the SDP a=fingerprint only when FreeSWITCH was the DTLS client, not when it held the DTLS server role. An unauthenticated peer able to reach the negotiated media port could complete the DTLS-SRTP handshake with an unrelated certificate, obtain the leg's SRTP keys, decrypt and inject media, and displace the legitimate endpoint; on ICE-enabled legs the peer also needs the connectivity-check credentials from SDP, which generally requires signaling visibility or a position on its path. WebRTC and SIP DTLS-SRTP legs are affected whenever the peer selects the active role, while FreeSWITCH client-role handshakes already perform fingerprint validation. Version 1.11.2 introduces the remediation, which requires rtp_dtls_client_cert_verify_mode=fingerprint.18hCVE-2026-964538.0 HIG—
——0A flaw was found in the Keycloak Admin CLI kcadm tool, which is used by administrators to manage Keycloak servers from the command line. When a custom truststore is provided to verify the server identity, the tool incorrectly accepts any self-signed certificate as long as the hostname matches. This allows a network attacker to impersonate the Keycloak server, steal administrative credentials, and perform unauthorized management actions.5hCVE-2026-618133.7 LOW—
——0ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Prior to 2.9.15 and 3.0.17, the HttpsClient::download function in src/utils/https_client.cc sets libcurl CURLOPT_SSL_VERIFYHOST to 1 instead of the strict value 2L. Under adversary-in-the-middle and TLS interception conditions, this non-strict setting may weaken TLS peer identity validation and increase the risk of accepting a certificate for an unintended host. End-to-end exploitation is non-trivial in typical environments. This issue is fixed in versions 2.9.15 and 3.0.17.1dCVE-2026-1094087.4 HIG7.3%
——2vault-java-driver, a Java client for HashiCorp Vault, silently disables TLS certificate and hostname verification in three states where the caller asked for verification: an SslConfig passed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULT_SSL_VERIFY set to a truthy value other than "true", such as 1, yes or on. In each case SslConfig.isVerify() returns false and the driver installs a trust-all SSLContext. An attacker on the network path to the Vault server can then read the Vault token and secrets in transit and forge responses. This issue affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3. It is fixed in 7.0.0.21h