CVE Watch6 de nov. de 2026

CVE-2026-113618

The ZSIRep client library (ZSIREP.CLIENT.DLL) is vulnerable to improper server certificate validation. It registers a process-wide .NET call

CVSS

—

Sem CVSS

EPSS

—

KEV

—

Exploit Today

0-100

Publicado: 6 de nov. de 2026 · Última mod.: 6 de nov. de 2026 · CWE-295

EPSS · 30d

Ainda não há histórico EPSS suficiente.

Descrição técnica

The ZSIRep client library (ZSIREP.CLIENT.DLL) is vulnerable to improper server certificate validation. It registers a process-wide .NET callback that accepts any certificate for HTTPS connections without verification. This allows a man-in-the-middle attacker to impersonate the ZSIRep server and intercept or modify authentication data and documents. The callback persists after the client is closed, weakening other HTTPS connections in the same application. The issue was fixed in version 2.12.3.1. The library is used in KS-SOMED (fixed in 2026.03.0.01), KS-PPS (fixed in 2026.03.1.0), KS-MEDIS (fixed in 2026.03.0.0), KS-SOLAB (fixed in 2026.3.1.0), and KS-ASW (fixed in 2026.3.0.1).

Referências oficiais

CVEs relacionados

CVECVSSEPSSKEVRExploitTítuloMod.

CVE-2026-1233067.4 ALT

—

——0In JetBrains IntelliJ IDEA before 2026.3 improper checks allowed server certificates to be added to the trust store during headless runs16h CVE-2026-111494—

5.5%

——2Incorrect 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.1d CVE-2026-1167897.4 ALT

7.5%

——2FreeSWITCH 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.1d CVE-2026-964538.0 ALT

6.3%

——2A 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.10h CVE-2026-618133.7 BAI

4.6%

——1ModSecurity 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.1d CVE-2026-1094087.4 ALT

7.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.1d