The JDK PKCS12 KeyStore implementation now supports the more modern PBMAC1 algorithm for integrity protection. To use the PBMAC1 algorithm, set the keystore.pkcs12.macAlgorithm property in the java.security configuration file to a PBMAC1 algorithm, for example, PBEWithHmacSHA256. Existing PKCS12 keystore files will continue to use the integrity algorithm it was created with, but new keystore files will use the PBMAC1 algorithm.

In a future JDK release, the default value of the keystore.pkcs12.macAlgorithm security property will be changed to a PBMAC1 algorithm.

All TLS server certificates anchored by Symantec, Entrust, and Camerfirma root CAs are now distrusted, regardless of their issuing date. TLS server certificates anchored by Chunghwa root CAs will be completely distrusted as of April 19, 2027. The jdk.security.caDistrustPolicies security property in the java.security configuration file has been updated to reflect these new policies.

The com.sun.net.http.HttpServer has been updated to validate the Host request header as described in RFC 9112. HTTP/1.1 requests without a Host header or with multiple Host headers are now rejected with an HTTP 400 Bad Request response.

The validation can be disabled by setting the system property sun.net.httpserver.disableHostValidation to true.

The implementation of the WebRowSet.readXml methods has been updated to consistently report XML parsing and validation failures as SQLException.

WebRowSet.readXml validates XML input against the standard WebRowSet XML schema. Applications should expect malformed XML, schema validation failures, unsupported external entities, and other XML processing errors to be reported as SQLException. Validation can be disabled by setting the system property jdk.sql.rowset.webrowsetValidation to false.

The existing method signatures remain unchanged. No specification changes are included in this update.

The scope of the com.sun.jndi.ldap.object.trustSerialData system property is extended to cover transparent processing of URL RMI References obtained from an LDAP context.

A URL context factory is a special type of ObjectFactory that will be used to look up an object referred to from a JNDI javax.naming.Reference that does not specify any factory name, but contains a simple reference address in the form of a URL string. When deserialization of Java objects from LDAP is disabled, the JDK built-in implementation of the JNDI/LDAP provider will no longer transparently use any URL context factory when processing Reference objects containing a URL reference whose scheme is rmi.

To make it possible to have a finer-grain control over which URL schemes should be disabled when processing URL string reference addresses from the built-in JNDI/LDAP provider, a new system property, jdk.jndi.ldap.disabledURLSchemes, is introduced. The value of this property is a comma-separated list of URL schemes that are disabled. The JDK built-in implementation of the JNDI/LDAP provider will no longer transparently use any URL context factory when processing Reference objects containing a URL reference whose scheme corresponds (case insensitively) to one of the schemes in this list of disabled schemes. The default value for that property is "rmi" if trustSerialData is false (the default), and empty if trustSerialData is true. If a custom value for this new property is provided on the Java command line then only schemes listed in that property value are disabled, regardless of the value of trustSerialData.

If rmi is included in this list (the default when no custom values have been supplied for com.sun.jndi.ldap.object.trustSerialData or jdk.jndi.ldap.disabledURLSchemes), then a javax.naming.Reference object will be returned to the application instead of the object that would have been created by processing the RMI reference and looking up its URL from the context returned by a URL context factory.

An application that depends on following RMI URLs contained in a Reference obtained from a JNDI/LDAP context may need to process the Reference object explicitly, or provide a custom value for the jdk.jndi.ldap.disabledURLSchemes system property that does not include the rmi scheme.

An application that wants to prevent transparent processing of other kinds of URL schemes can now do so by supplying a custom value for the jdk.jndi.ldap.disabledURLSchemes system property that also includes them.

The following root certificate has been removed from the cacerts keystore:

+ alias name "luxtrustglobalrootca [jdk]"

  Distinguished Name: CN=LuxTrust Global Root, O=LuxTrust s.a., C=LU

Hybrid key exchange algorithms for TLS 1.3 have been implemented, enhancing the security of Java applications that require secure network communication. These algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm.

The following three new hybrid key exchange algorithms are supported: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. The X25519MLKEM768 group is enabled by default and is the most preferred group. This feature works out of the box. No API or configuration change is needed, as long as both peers support the X25519MLKEM768 group and it is the most preferred group. X25519MLKEM768 is the most widely deployed hybrid group.

To verify that a post-quantum hybrid group was negotiated by the TLS handshake, enable JSSE debugging by setting the system property javax.net.debug to ssl:handshake and inspect the contents of the key_share extension of the ServerHello message, ex:

"key_share (51)": {

  "server_share": {
    "named group": x25519mlkem768
  }
}

For more details, see JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3.

The way JShell's remote agents are invoked has changed. Existing agents will need to be updated to use the new protocol. See the jdk.jshell.execution.RemoteExecutionControl JavaDoc API documentation for the new protocol.

Deserialization of the com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl class is now disabled by default. (This is an internal class that implements the javax.xml.transform.Templates interface.) An application attempting to deserialize an instance of this class will receive UnsupportedOperationException. To re-enable deserialization of this class, set the system property jdk.xml.enableTemplatesImplDeserialization to true. To take effect, this property must be set on the command line, in the jaxp.properties file, or in a user-defined JAXP configuration file.

This release contains fixes for security vulnerabilities described in the Oracle Critical Patch Update.