Total
1617 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-62243 | 1 Netty | 1 Netty | 2026-08-24 | 7.5 High |
| 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. | ||||
| CVE-2026-76403 | 1 Splunk | 2 Connect For Kafka, Splunk Connect For Kafka | 2026-08-24 | 7.4 High |
| In Splunk Connect for Kafka versions below 2.2.7, an unauthenticated user positioned in the network path could read or alter all relevant data sent from the connector when Kerberos authentication is used with Hypertext Transfer Protocol (HTTP) Event Collector in Splunk Enterprise. The vulnerability is possible because the Kerberos authentication path does not apply the configured certificate validation options when it builds the HTTP client. For more information see Install Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/install/install-splunk-connect-for-kafka), Security configurations for Splunk Connect for Kafka (https://help.splunk.com/en/splunk-enterprise/get-data-in/splunk-connect-for-kafka/2.2/configure/security-configurations-for-splunk-connect-for-kafka), and Set up and use HTTP Event Collector with configuration files (https://help.splunk.com/en/splunk-enterprise/get-data-in/get-started-with-getting-data-in/9.4/get-data-with-http-event-collector/set-up-and-use-http-event-collector-with-configuration-files) in the Splunk documentation. | ||||
| CVE-2026-16822 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 9.3 Critical |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to impersonate the TNC policy server and modify traffic due to improper certificate validation. | ||||
| CVE-2026-78323 | 1 Redhat | 2 Certificate System, Enterprise Linux | 2026-08-24 | 6.5 Medium |
| A flaw was found in JSS (Java Security Services). The JSSTrustManager class does not verify NSS trust flags when validating CA certificates, allowing certificates present in the NSS database without TRUSTED_CA flags to be accepted as trust anchors for TLS connections. In non-default configurations where certificate revocation checking is disabled, this could allow a man-in-the-middle attacker to forge certificates accepted by PKI client connections. | ||||
| CVE-2026-15554 | 1 Redhat | 4 Jboss Enterprise Application Platform, Jboss Enterprise Application Platform Els, Jboss Enterprise Application Platform Expansion Pack and 1 more | 2026-08-24 | 7.4 High |
| the Undertow AJP listener honours forged ssl_cert and is_ssl AJP attributes without requiring any shared-secret authentication. This enables an unauthenticated attacker with direct TCP access to port 8009 to bypass CLIENT-CERT authentication by injecting a forged X.509 certificate via the AJP protocol. | ||||
| CVE-2026-59825 | 1 Joinmastodon | 1 Mastodon | 2026-08-21 | 7.4 High |
| Mastodon is a free, open-source social network server based on ActivityPub. Prior to 4.4.19 and from 4.5.0 until 4.5.12, Mastodon's app/models/concerns/user/ldap_authenticable.rb mutates OpenSSL::SSL::SSLContext::DEFAULT_PARAMS when LDAP authentication uses LDAP_TLS_NO_VERIFY=true, disabling SSL and TLS certificate verification globally for requests made by puma web processes while sidekiq background jobs remain unaffected. This issue is fixed in versions 4.4.19 and 4.5.12. | ||||
| CVE-2026-63336 | 1 Rabbitmq | 1 Java-client | 2026-08-21 | N/A |
| The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.33.0, com.rabbitmq.client.ConnectionFactory.useSslProtocol() and ConnectionFactory.useSslProtocol(String) configure com.rabbitmq.client.TrustEverythingTrustManager and leave hostname verification disabled, causing arbitrary server certificates, including self-signed certificates, to be accepted. A network attacker able to intercept a TLS connection can impersonate the RabbitMQ broker, read protected AMQP traffic, and modify traffic without certificate or hostname validation. The fix changes the production TLS helpers to use the JVM default trust store and enables hostname verification, while retaining an explicitly named development-only no-verification helper. This issue is fixed in version 5.33.0. | ||||
| CVE-2026-8497 | 3 Apple, Devolutions, Google | 4 Iphone Os, Macos, Password Manager and 1 more | 2026-08-21 | 7.4 High |
| Improper certificate validation in the Devolutions Server connection handling in Devolutions Password Manager 2026.2.1.0 and earlier on Android, iOS, and macOS allows an adjacent-network attacker to intercept and modify sensitive information via a forged TLS certificate. | ||||
| CVE-2026-76362 | 1 Splunk | 2 Soar, Splunk | 2026-08-21 | 7.4 High |
| In Splunk SOAR versions below 8.6.0, an unauthenticated user who can observe or alter network traffic between Splunk SOAR and a configured CyberArk Representational State Transfer (REST) server could access or modify all relevant data exchanged through that credential manager. The vulnerability is possible because the CyberArk REST client does not verify server certificates by default. The attack requires the attacker to have network-path interception capability between Splunk SOAR and the configured CyberArk REST server. For more information see Manage your organization's credentials with a password vault (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/configure-administration-settings-in-splunk-soar-cloud/manage-your-organizations-credentials-with-a-password-vault) in the Splunk documentation. | ||||
| CVE-2026-52723 | 1 Fbeta-gmbh | 1 Epa3-service-opensource | 2026-08-21 | 9.1 Critical |
| ePA 3.x Integration implements the authorization workflow and writes Medical Information Objects to Germany's electronic patient record. Prior to 1.3.0, ePA 3.x Integration performs VAU server certificate validation in app/vau/VAUProtokoll.py without anchoring the signed_vau_server_pub_keys and AUT_VAU_CertData certificate path to independent trusted material. A network-positioned attacker between the DiGA backend and the ePA system can intercept the VAU handshake, supply attacker-controlled certificate and key material, and satisfy the circular trust relationship. Because TLS certificate verification is also disabled in affected versions, no independent server-authentication layer prevents the attack. The attacker can impersonate the VAU server, control the negotiated session keys, and read or modify all encrypted VAU traffic. This issue is fixed in version 1.3.0. | ||||
| CVE-2026-50578 | 1 Fbeta-gmbh | 1 Epa3-service-opensource | 2026-08-21 | 7.5 High |
| ePA 3.x Integration implements the authorization workflow and writes Medical Information Objects to Germany's electronic patient record. Prior to 1.3.0, ePA 3.x Integration disables TLS certificate verification for both ePA connections in app/vau/VAUProtokoll.py and Konnektor connections in app/konnektor/Konnektor.py. A network-positioned attacker can present an arbitrary certificate, terminate the TLS connection, and intercept ePA traffic. The VAU protocol does not provide an effective fallback because its application-layer certificate validation is also broken in affected versions. The Konnektor session uses self.session.verify set to False while the client authenticates with self.session.cert, so an attacker impersonating the Konnektor can receive the client's mutual TLS certificate exchange and observe smartcard operations. This issue is fixed in version 1.3.0. | ||||
| CVE-2026-53583 | 1 Libgit2 | 1 Libgit2 | 2026-08-21 | 6.5 Medium |
| libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Prior to 1.8.6 and 1.9.5, verify_server_cert in src/libgit2/streams/openssl.c uses an inverted !!memcmp result in the GEN_IPADD branch when comparing an IP-literal host with a certificate IP SubjectAltName. OpenSSL builds reject matching IP addresses and accept mismatched IP addresses, allowing a network attacker with a CA-trusted certificate containing any IP SubjectAltName to intercept libgit2 connections to IP-literal HTTPS URLs. DNS SubjectAltName validation and non-OpenSSL TLS backends are not affected. This issue is fixed in versions 1.8.6 and 1.9.5. | ||||
| CVE-2026-73251 | 1 Cesanta | 1 Mongoose | 2026-08-20 | N/A |
| Mongoose is an embedded web server and network library. Prior to 7.23, a network attacker can impersonate a TLS server to a Mongoose client configured with a multi-certificate CA bundle. In src/tls_builtin.c, the mg_tls_init() function stores the bundle in tls->ca_bundle_der while tls->ca_der.len remains zero, and mg_tls_recv_cert() uses tls_bundle_find() to accept a Common Name match without calling mg_tls_verify_cert_signature(). A forged self-signed certificate can therefore satisfy hostname and CertificateVerify checks and enable interception, credential disclosure, traffic modification, and malicious responses. This issue is fixed in version 7.23. | ||||
| CVE-2026-73253 | 1 Cesanta | 1 Mongoose | 2026-08-20 | N/A |
| Mongoose is an embedded web server and network library. Prior to version 7.22, an on-path network attacker with a wildcard certificate for a parent domain can impersonate deeper subdomains to a client using the built-in TLS stack. The mg_tls_verify_cert_san() and mg_tls_verify_cert_cn() functions in src/tls_builtin.c call mg_match(), whose wildcard can cross DNS label boundaries, so a pattern such as *.example.com can match foo.bar.example.com. The resulting hostname verification bypass permits interception and modification of TLS traffic. This issue is fixed in version 7.22. | ||||
| CVE-2026-15078 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-20 | 8.1 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 NIM could allow a remote attacker to gain unauthorized access to AIX systems due to improper validation of TLS certificates. | ||||
| CVE-2026-76242 | 1 Eidetic-labs | 1 Stigmem | 2026-08-20 | N/A |
| stigmem-node 0.9.0a1 accepts federation peer key material during peer registration without a separate administrator out-of-band fingerprint approval step. On nodes that accept federation peer registration over a network where initial registration can be intercepted or misdirected, an attacker can register a malicious peer and gain access to or tamper with federation traffic. Fixed in 0.9.0a2, which introduces a pending approval flow requiring administrator fingerprint verification before peer tokens are accepted. | ||||
| CVE-2026-49283 | 1 Simplesamlphp | 1 Saml2 | 2026-08-19 | 8.7 High |
| The SimpleSAMLphp SAML2 library is a PHP library for SAML2 related functionality. Prior to versions 4.19.3, 4.20.2, 5.0.6, and 6.2.1, the HTTPArtifact::receive() flow can treat an unsigned embedded SAML Response as cryptographically valid for the wrong identity provider. SOAPClient::addSSLValidator() attaches a TLS-based validator to the outer SOAP ArtifactResponse, while the embedded Response receives a validator that delegates to the outer message and is later checked against metadata selected from the embedded response issuer rather than necessarily the artifact issuer. SOAPClient::validateSSL() returns normally when the TLS public key does not match the key being validated, and SAML2\Message::validate() treats a validator call that does not throw as successful. In a multi-IdP federation, a malicious or lower-trust IdP can therefore provide an ArtifactResponse containing an unsigned Response that claims a higher-trust victim IdP as issuer and authenticate as arbitrary users with attacker-chosen assertion attributes, NameID, and session data. This issue is fixed in versions 4.19.3, 4.20.2, 5.0.6, and 6.2.1. | ||||
| CVE-2026-2368 | 1 Lenovo | 1 Filez | 2026-08-19 | 7.1 High |
| An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to execute arbitrary code. | ||||
| CVE-2026-1068 | 1 Lenovo | 1 Filez | 2026-08-19 | 5.3 Medium |
| An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to obtain sensitive user data from the application. | ||||
| CVE-2020-1113 | 1 Microsoft | 18 Windows 10, Windows 10 1507, Windows 10 1607 and 15 more | 2026-08-19 | 5.3 Medium |
| A security feature bypass vulnerability exists in Microsoft Windows when the Task Scheduler service fails to properly verify client connections over RPC. An attacker who successfully exploited this vulnerability could run arbitrary code as an administrator. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. To exploit this vulnerability, a man-in-the-middle attacker would need to send a specially crafted request to a vulnerable system. The security update addresses the vulnerability by correcting how the Task Scheduler service validates connections. | ||||