CVE-2026-60623

Overview

MySQL Connector/J is the official JDBC Type 4 driver for MySQL, developed and released by the MySQL team at Oracle. It lets Java applications connect to and query MySQL servers over JDBC, and also implements the X DevAPI for document-store access. It is distributed as the Maven artifact com.mysql:mysql-connector-j and is a standard dependency in Java applications that talk to MySQL.

A resource injection vulnerability (CVE-2026-60623) has been identified in the SSL/TLS setup of MySQL Connector/J, which allows attackers who can influence the driver's keystore or truststore connection properties to make the driver load TLS key and trust material from any URL, including remote and network locations. Trust material supplied this way lets an attacker control which server certificates the driver accepts, exposing the connection and its data to interception and tampering.

Per OWASP: This attack consists of changing resource identifiers used by an application in order to perform a malicious task. When an application defines a resource type or location based on user input, such as a file name or port number, this data can be manipulated to execute or access different resources.

This issue affects versions 9.7.0 through 9.7.1 of MySQL Connector/J.

Details

Module Info

• Product: MySQL Connector/J
• Affected packages: com.mysql:mysql-connector-j
• Affected versions: >=9.7.0 <=9.7.1
• GitHub repository: https://github.com/mysql/mysql-connector-j
• Published packages: https://central.sonatype.com/artifact/com.mysql/mysql-connector-j
• Package manager: Maven
• Fixed in:
  • OSS MySQL Connector/J 26.7.0
  • NES for MySQL Connector/J v8.0.35

Vulnerability Info

This High-severity vulnerability is found in the com.mysql:mysql-connector-j package in versions 9.7.0 through 9.7.1 of MySQL Connector/J. The client certificate keystore and the trusted root certificates truststore are configured with the clientCertificateKeyStoreUrl and trustCertificateKeyStoreUrl connection properties (and the X DevAPI equivalents xdevapi.ssl-keystore and xdevapi.ssl-truststore). When the driver builds its SSLContext in ExportControlled, it treats each value as a java.net.URL and reads it with openStream(), with no check on the URL scheme, the host or whether the path is local:

URL ksURL = new URL(this.keyStoreSettings.keyStoreUrl);
char[] password = this.keyStoreSettings.keyStorePassword == null ? new char[0] : this.keyStoreSettings.keyStorePassword.toCharArray();
ksIS = ksURL.openStream();
clientKeyStore.load(ksIS, password);

trustStoreIS = new URL(this.trustStoreSettings.keyStoreUrl).openStream();
trustKeyStore = StringUtils.isNullOrEmpty(this.keyStoreProvider) ? KeyStore.getInstance(this.trustStoreSettings.keyStoreType)
        : KeyStore.getInstance(this.trustStoreSettings.keyStoreType, this.keyStoreProvider);
trustKeyStore.load(trustStoreIS, trustStorePassword);

The only normalization happens when the values fall back to the javax.net.ssl.keyStore and javax.net.ssl.trustStore system properties: there, a value is prefixed with file: only if it fails to parse as a URL. Any value that already parses as a URL, such as http://, https://, ftp:// or jar: locations, or a file: URL with a remote authority or a UNC network path, is opened as given. An attacker who can set or inject these connection properties, for example through a JDBC URL assembled from untrusted input, can therefore make the driver fetch keystore data from a server they control and make outbound requests to arbitrary locations. A truststore supplied this way decides which server certificates the driver trusts, so the attacker can present their own certificate and intercept or modify the traffic between the application and the MySQL server, and a client keystore supplied this way replaces the client identity the driver presents.

Mitigation

MySQL Connector/J is maintained by Oracle, which ships fixes only in the current Connector/J release line; older lines no longer receive updates. For more information, see the MySQL Product Support EOL Announcements.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to supported versions of MySQL Connector/J.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Hanfei Ouyang from PayPal (finder)