CVE-2025-59250

Overview

The Microsoft JDBC Driver for SQL Server is a Type 4 JDBC driver, developed and released by Microsoft, that gives Java applications access to Microsoft SQL Server and Azure SQL Database through the standard JDBC APIs. It is distributed as the Maven artifact com.microsoft.sqlserver:mssql-jdbc, with separate builds for each supported Java version (such as 10.2.4.jre8 and 10.2.4.jre11), and is a standard dependency in Java applications that talk to SQL Server.

An information exposure vulnerability (CVE-2025-59250) has been identified in the Microsoft JDBC Driver for SQL Server's TLS certificate hostname validation, which allows attackers to impersonate a SQL Server and intercept encrypted connections. A certificate whose subject hides a second common name inside another attribute passes validation for a host it was not issued to.

Per OWASP: The Manipulator-in-the Middle attack (MITM) intercepts a communication between two systems. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.

This issue affects multiple versions of the Microsoft JDBC Driver for SQL Server.

Details

Module Info

• Product: Microsoft JDBC Driver for SQL Server
• Affected packages: com.microsoft.sqlserver:mssql-jdbc
• Affected versions: <10.2.4, >=11.2.0 <11.2.4, >=12.2.0 <12.2.1, >=12.4.0 <12.4.3, >=12.6.0 <12.6.5, >=12.8.0 <12.8.2, >=12.10.0 <12.10.2, >=13.2.0 <13.2.1
• GitHub repository: https://github.com/microsoft/mssql-jdbc
• Published packages: https://central.sonatype.com/artifact/com.microsoft.sqlserver/mssql-jdbc
• Package manager: Maven
• Fixed in:
  • OSS Microsoft JDBC Driver for SQL Server 10.2.4, 11.2.4, 12.2.1, 12.4.3, 12.6.5, 12.8.2, 12.10.2, 13.2.1
  • NES for Microsoft JDBC Driver for SQL Server v10.2.5

Vulnerability Info

This High-severity vulnerability is found in the com.microsoft.sqlserver:mssql-jdbc package in multiple versions of the Microsoft JDBC Driver for SQL Server. It affects every Java-version build of an affected version, such as the .jre8 and .jre11 variants.

When a connection is encrypted, trustServerCertificate is false, no custom trustManagerClass is configured and the driver is not running in FIPS mode, the driver checks the server's certificate chain against its trust store and then checks that the certificate names the host it connected to (or the hostNameInCertificate value). The HostNameOverrideX509TrustManager class performs the name check. It reads the subject distinguished name in RFC 2253 canonical form and extracts the common name with a hand-written parser:

private String parseCommonName(String distinguishedName) {
    int index;
    // canonical name converts entire name to lowercase
    index = distinguishedName.indexOf("cn=");
    if (index == -1) {
        return null;
    }
    distinguishedName = distinguishedName.substring(index + 3);
    // Parse until a comma or end is reached
    for (index = 0; index < distinguishedName.length(); index++) {
        if (distinguishedName.charAt(index) == ',') {
            break;
        }
    }
    String commonName = distinguishedName.substring(0, index);
    // ...
    return commonName;
}

indexOf("cn=") finds the first occurrence of the text cn= anywhere in the distinguished name, not the first CN attribute. The canonical form also drops the escaping on an = inside an attribute value. A certificate with the subject OU=CN\=target.com, CN=attacker.com therefore has the canonical name ou=cn=target.com,cn=attacker.com, and the parser returns target.com. Any attribute value that contains cn= and comes before the real common name works the same way.

The returned name is checked before the subject alternative names, and a match ends validation:

String nameInCertDN = cert.getSubjectX500Principal().getName("canonical");
// ...
String subjectCN = parseCommonName(nameInCertDN);

isServerNameValidated = validateServerName(subjectCN);

if (!isServerNameValidated) {
    Collection<List<?>> sanCollection = cert.getSubjectAlternativeNames();
    // ...
}

An attacker who holds a certificate that the client's trust store accepts, and whose subject carries a crafted attribute value, can present it while impersonating a different SQL Server host. The driver accepts the certificate for that host and completes the TLS handshake. An attacker in a position to intercept network traffic can then read and modify the connection, including credentials and query results.

Mitigation

Microsoft provides mainstream support for each minor version of the Microsoft JDBC Driver for SQL Server for a fixed period and ships fixes only in supported versions; versions past their end of mainstream support no longer receive updates. The 10.2 line reaches End-of-Life when its mainstream support ends on January 31, 2027. For more information, see here.

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

• Upgrade affected applications to a supported, patched version of the Microsoft JDBC Driver for SQL Server.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Nikita Markevich (finder)