Improper Certificate Validation The advisory has been revoked - it doesn't affect any version of package python3.14  (opens in a new tab)


Threat Intelligence

EPSS
0.44% (36th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL10-PYTHON314-19504813
  • published3 Sept 2026
  • disclosed28 Aug 2026

Introduced: 28 Aug 2026

CVE-2026-55856  (opens in a new tab)
CWE-295  (opens in a new tab)

Amendment

The Red Hat security team deemed this advisory irrelevant for RHEL:10.

NVD Description

Note: Versions mentioned in the description apply only to the upstream python3.14 package and not the python3.14 package as distributed by RHEL.

MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. Prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9, when a Java application connects with sslMode=verify-full or sslMode=verify-ca, supplies a password, and does not configure serverSslCert or trustStore, Connector/J can accept an untrusted self-signed certificate through the fallbackToSystemTrustStore=true ephemeral trust manager and record its certFingerprint for later identity binding. The OK-packet and authentication-switch paths enforce the certificate fingerprint, but the initial-handshake path does not. HandshakeResponse.encode() can therefore build and send a mysql_clear_password response before checking certFingerprint != null && !isMitMProof(), sslMode, or whether the authentication plugin is resistant to a man-in-the-middle, and the initial path also bypasses restrictedAuth. An active man-in-the-middle or hostile server can present a self-signed certificate, claim to be MariaDB, select mysql_clear_password as the initial authentication plugin, and receive the full database password before the connection is rejected. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9.