| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Mozilla Firefox before 35.0 and SeaMonkey before 2.32 do not consider the id-pkix-ocsp-nocheck extension in deciding whether to trust an OCSP responder, which makes it easier for remote attackers to obtain sensitive information by sniffing the network during a session in which there was an incorrect decision to accept a compromised and revoked certificate. |
| OpenStack keystonemiddleware (formerly python-keystoneclient) 0.x before 0.11.0 and 1.x before 1.2.0 disables certification verification when the "insecure" option is set in a paste configuration (paste.ini) file regardless of the value, which allows remote attackers to conduct man-in-the-middle attacks via a crafted certificate. |
| The (1) bundled GnuTLS SSL/TLS plugin and the (2) bundled OpenSSL SSL/TLS plugin in libpurple in Pidgin before 2.10.10 do not properly consider the Basic Constraints extension during verification of X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate. |
| Smart Proxy (aka Smart-Proxy and foreman-proxy) in Foreman before 1.5.4 and 1.6.x before 1.6.2 does not validate SSL certificates, which allows remote attackers to bypass intended authentication and execute arbitrary API requests via a request without a certificate. |
| Certificates.java in Not Yet Commons SSL before 0.3.15 does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate. |
| The getCN function in Apache Axis 1.4 and earlier does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via a certificate with a subject that specifies a common name in a field that is not the CN field. NOTE: this issue exists because of an incomplete fix for CVE-2012-5784. |
| The Serf RA layer in Apache Subversion 1.4.0 through 1.7.x before 1.7.18 and 1.8.x before 1.8.10 does not properly handle wildcards in the Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof servers via a crafted certificate. |
| kio/usernotificationhandler.cpp in the POP3 kioslave in kdelibs 4.10.95 before 4.13.3 does not properly generate warning notifications, which allows man-in-the-middle attackers to obtain sensitive information via an invalid certificate. |
| The Smart Call Home (SCH) implementation in Cisco ASA Software 8.2 before 8.2(5.50), 8.4 before 8.4(7.15), 8.6 before 8.6(1.14), 8.7 before 8.7(1.13), 9.0 before 9.0(4.8), and 9.1 before 9.1(5.1) allows remote attackers to bypass certificate validation via an arbitrary VeriSign certificate, aka Bug ID CSCun10916. |
| lib/x509/verify.c in GnuTLS before 3.1.22 and 3.2.x before 3.2.12 does not properly handle unspecified errors when verifying X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers via a crafted certificate. |
| The ServerTrustManager component in the Ignite Realtime Smack XMPP API before 4.0.0-rc1 does not verify basicConstraints and nameConstraints in X.509 certificate chains from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate chain. |
| cURL and libcurl 7.1 before 7.36.0, when using the OpenSSL, axtls, qsossl or gskit libraries for TLS, recognize a wildcard IP address in the subject's Common Name (CN) field of an X.509 certificate, which might allow man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority. |
| The SASL authentication functionality in 389 Directory Server before 1.2.11.26 allows remote authenticated users to connect as an arbitrary user and gain privileges via the authzid parameter in a SASL/GSSAPI bind. |
| OpenStack Heat Templates (heat-templates), as used in Red Hat Enterprise Linux OpenStack Platform 4.0, sets sslverify to false for certain Yum repositories, which disables SSL protection and allows man-in-the-middle attackers to prevent updates via unspecified vectors. |
| NetApp Plug-in for Symantec NetBackup prior to version 2.0.1 makes use of a non-unique server certificate, making it vulnerable to impersonation. |
| The ssl_do_connect function in common/server.c in HexChat before 2.10.2, XChat, and XChat-GNOME does not verify that the server hostname matches a domain name in the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate. |
| Samba 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 does not verify X.509 certificates from TLS servers, which allows man-in-the-middle attackers to spoof LDAPS and HTTPS servers and obtain sensitive information via a crafted certificate. |
| The s3_token middleware in OpenStack keystonemiddleware before 1.6.0 and python-keystoneclient before 1.4.0 disables certification verification when the "insecure" option is set in a paste configuration (paste.ini) file regardless of the value, which allows remote attackers to conduct man-in-the-middle attacks via a crafted certificate, a different vulnerability than CVE-2014-7144. |
| PyWBEM 0.7 and earlier does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate. |
| PKId in Juniper Junos OS before 12.1X44-D52, 12.1X46 before 12.1X46-D37, 12.1X47 before 12.1X47-D30, 12.3 before 12.3R12, 12.3X48 before 12.3X48-D20, 13.3 before 13.3R10, 14.1 before 14.1R8, 14.1X53 before 14.1X53-D40, 14.2 before 14.2R7, 15.1 before 15.1R4, 15.1X49 before 15.1X49-D20, 15.1X53 before 15.1X53-D60, and 16.1 before 16.1R1 allow remote attackers to bypass an intended certificate validation mechanism via a self-signed certificate with an Issuer name that matches a valid CA certificate enrolled in Junos. |
