CVE-2026-101768

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-101768) has been identified in the way MySQL Connector/J loads extension classes named in connection properties, which allows attackers who can influence a connection URL or its properties to pass arbitrary strings, including URL and file locators, to the Java class loader. Oracle rates a successful attack as a takeover of the connector, with high impact on confidentiality, integrity and availability.

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 MySQL Connector/J versions 8.0.33 and greater, before 26.10.0.

Details

Module Info

• Product: MySQL Connector/J
• Affected packages: com.mysql:mysql-connector-j
• Affected versions: >=8.0.33 <26.10.0
• 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.10.0
  • NES for MySQL Connector/J

Vulnerability Info

This High-severity vulnerability is found in the com.mysql:mysql-connector-j package in versions 8.0.33 and greater, before 26.10.0, of MySQL Connector/J. Oracle scores it CVSS 3.1 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).

Connector/J lets several connection properties name a Java class for the driver to load, among them socketFactory, the authentication plugin properties, loadBalanceSQLExceptionSubclassFailover and the X Protocol compression stream classes. These values usually come from the JDBC URL or a Properties object. The driver resolves most of them through Util.getInstance, which hands the configured string straight to Class.forName:

public static <T> T getInstance(Class<T> returnType, String className, Class<?>[] argTypes, Object[] args, ExceptionInterceptor exceptionInterceptor) {
    try {
        Class<?> clazz = Class.forName(className, false, Util.class.getClassLoader());
        if (!returnType.isAssignableFrom(clazz)) {
            throw ExceptionFactory.createException(WrongArgumentException.class,
                    Messages.getString("Util.WrongImplementation", new Object[] { className, returnType.getName() }), exceptionInterceptor);
        }
        return handleNewInstance(((Class<T>) clazz).getConstructor(argTypes), args, exceptionInterceptor);
    } catch (ClassNotFoundException | NoSuchMethodException | SecurityException e) {
        // ...
    }
}

The load-balance exception checker and the X Protocol CompressionAlgorithm call Class.forName the same way on each configured name:

this.sqlExClassList = StringUtils.split(sqlExClasses, ",", true).stream().filter(s -> !s.isEmpty()).map(s -> {
    try {
        return Class.forName(s, false, this.getClass().getClassLoader());
    } catch (ClassNotFoundException e) {
        // Ignore and don't check, class doesn't exist.
    }
    return null;
}).filter(Objects::nonNull).collect(Collectors.toList());

Nothing checks that the configured value is a Java class name before it reaches the class loader. Strings that are resource locators rather than class names, such as http://localhost/Plugin, jar:file:/proc/self/fd/16!/Plugin or file:/tmp/Plugin, and array descriptors such as [Ljava.lang.String;, are passed through unchanged. An attacker who can supply or alter a JDBC URL, for example in an application that accepts data source settings from users, can therefore steer the class loader to resources the application never intended to load. Where the class loader resolves such a name to attacker-controlled code, Util.getInstance goes on to instantiate that class.

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

• 4ra1n (finder)
• pyn3rd (finder)
• unam4 (finder)