java

JDK 21.0.13 Release Notes

Java SE 21.0.13 - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following sections summarize changes made in all Java SE 21.0.13 BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.

 

Changes in Java SE 21.0.13.0.1

The 21.0.13.0.1 BPR is available all users here.

Bug Fixes

Release date: October 20, 2026
BugId Category Subcategory Summary
JDK-8392377 core-libs java.time (tz) Update Timezone Data to 2026d
JDK-8392519 core-libs java.util:i18n Cherry-pick metazone changes from CLDR for tzdata2026d, for JDK update release
JDK-8392526 core-libs java.util:i18n Cherry-pick BCP 47 time zone changes from CLDR for tzdata2026d, for JDK update releases
JDK-8393337 core-libs java.time (tz) Update Timezone Data to 2026e
JDK-8343788 core-libs java.util:i18n Provide means to alter lib/tzmappings entries on Windows
JDK-8393344 core-libs java.util:i18n Cherry-pick metazone changes from CLDR to support tzdata2026e for JDK update releases
JDK-8392538 core-libs java.util:i18n Align the JDK with Microsoft's new timezone names for British Columbia/Alberta
JDK-8393848 core-libs java.util:i18n Align the JDK with Microsoft's new timezone name for Manitoba

Java™ SE Development Kit 21, Update 21.0.13 (JDK 21.0.13)

Release date: October 20, 2026

The full version string for this update release is 21.0.13+10 (where "+" means "build"). The version number is 21.0.13. This JDK conforms to version 21 of the Java SE Specification (JSR 396 2023-09-19).

 

IANA TZ Data 2026c

JDK 21.0.13 contains IANA time zone data 2026c which contains the following changes:

  • Alberta moved to permanent -06 on 2026-06-18.
  • Morocco moves to permanent +00 on 2026-09-20.

For more information, refer to Timezone Data Versions in the JRE Software.

 

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 21.0.13 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
2121.0.13+10
1717.0.21+9
1111.0.33+9
81.8.0_511-b09

 

Keeping the JDK up to Date

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 21.0.13) be used after the next critical patch update scheduled for November 17, 2026.

Java Management Service, available to all users, can help you find vulnerable Java versions in your systems. Java SE Subscribers and customers running in Oracle Cloud can use Java Management Service to update Java Runtimes and to do further security reviews like identifying potentially vulnerable third party libraries used by your Java programs. Existing Java Management Service user click here to log in to your dashboard. The Java Management Service Documentation provides a list of features available to everyone and those available only to customers. Learn more about using Java Management Service to monitor and secure your Java Installations.

 

Important Oracle JDK 21 License Update starting with JDK 21.0.13

JDK 21.0.13 is the first JDK 21 update release made available under the Oracle Technology Network License Agreement for Oracle Java SE (OTN for Java SE). This license is substantially different from the Oracle No-fee Terms and Conditions (NFTC) used in earlier JDK 21 updates. The OTN for Java SE license permits certain uses, such as personal use and development use, at no cost, but other uses authorized under the NFTC may no longer be available. Please review the terms carefully before using this product. An FAQ is available here.

A similar licensing change takes effect for JavaFX 21 updates released after September 2026.

 

New Features

security-libs/java.security
➜ Added Support for the Latest ML-KEM and ML-DSA Private Key Encodings (JDK-8347938)

The JDK now encodes ML-KEM and ML-DSA private keys in PKCS #8 format using the DER-encoded ASN.1 CHOICE formats defined in Section 6, "Private Key Format" of RFC 9935 and Section 6, "Private Key Format" of RFC 9881. Two new security properties, jdk.mlkem.pkcs8.encoding and jdk.mldsa.pkcs8.encoding, control the encoding used when generating new keys with a KeyPairGenerator or when translating keys with a KeyFactory. Valid values are seed, expandedKey, and both (case-insensitive). If a system property of the same name is also specified, it supersedes the security property value. All three formats are supported when decoding previously encoded private keys with a KeyFactory.

The default encoding for newly generated ML-KEM and ML-DSA private keys is seed. Applications that require a particular private-key encoding can configure the relevant security property or equivalent system property.

security-libs/java.security
➜ SHAKE128-256 and SHAKE256-512 as MessageDigest Algorithms (JDK-8354305)

Two new MessageDigest algorithms, SHAKE128-256 and SHAKE256-512, have been added to the SUN provider. These are fixed-length versions of the SHAKE128 and SHAKE256 Extendable-Output Functions (XOFs) defined in NIST FIPS 202. For more information, see The SUN Provider.

 

Other Notes

security-libs/java.security
➜ Policy for Distrusting Certain TLS Server Certificates has Changed (JDK-8382178 (not public))

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.

core-libs/java.net
➜ HttpServer Validates the Host Request Header (JDK-8386525 (not public))

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.

core-libs/java.sql
➜ Clarification of WebRowSet.readXml Exception Behavior (JDK-8383301 (not public))

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.

core-libs/javax.naming
➜ Extend the Scope of com.sun.jndi.ldap.object.trustSerialData System Property to cover RMI URL References Obtained From an LDAP Context (JDK-8382407 (not public))

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.

hotspot/runtime
➜ Make TrimNativeHeapInterval a Product Switch (JDK-8325496)

(Only available on Linux with glibc.) TrimNativeHeapInterval has been made an official product switch. It allows the JVM to trim the native heap at periodic intervals.

security-libs/java.security
➜ SHA3 Performance Improved (JDK-8333867)

The performance of the MessageDigest implementations that belong to the SHA3 family (SHA3-224, SHA3-256, SHA3-384, and SHA3-512) has been improved by 6-27%, depending on digested message length and on the platform used. An additional 30-40% can be experienced on AVX-512 capable platforms due to new intrinsic implementations on that platform.

security-libs/java.security
➜ LuxTrust Global Root CA Removed (JDK-8387123)

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

tools/jshell
➜ New JShell Remote Agent Launch Protocol (JDK-8384736 (not public))

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.

xml/jaxp
➜ JAXP Templates Class Deserialization Is Disabled (JDK-8384654 (not public))

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. Prior to this change, deserialization was enabled by default, unless the Security Manager was enabled. The state of the Security Manager is no longer considered in determining whether deserialization is enabled.

 

Fixes

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

➜ Issues fixed in 21.0.13:
# JBS Component/Subcomponent Summary
1JDK-8385490client-libs/2dUpdate HarfBuzz to 14.2.0
2JDK-8385390client-libs/2dUpdate FreeType to 2.14.3
3JDK-8387593client-libs/2dUsing XOR mode to clear the content leaves some traces in metal
4JDK-8384902client-libs/java.awtUpdate GIFlib to 6.1.3
5JDK-8384495client-libs/java.awtUpdate Libpng to 1.6.58
6JDK-8332020core-libs/java.netjwebserver tool prints invalid URL in case of IPv6 address binding
7JDK-8377992core-libs/java.nio(zipfs) Align ZipFileSystem END header validation with the ZipFile implementation
8JDK-8391807core-libs/java.timeInconsistent TimeZone Names Displayed across JDK release trains
9JDK-8341625core-libs/java.util.jarImprove ZipFile validation of the END header
10JDK-8381379core-libs/java.util:i18nSupport std/dstOffset attributes in CLDR's metazone definitions
11JDK-8390388core-libs/java.util:i18nCherry-pick tz attributes from newer CLDR data for jdk25u and earlier
12JDK-8390380core-libs/java.util:i18nCherry-pick metazone changes from CLDR to support tzdata2026c for JDK update releases
13JDK-8352020hotspot/compiler[CompileFramework] enable compilation for VectorAPI
14JDK-8336702hotspot/compilerC2 compilation fails with "all memory state should have been processed" assert
15JDK-8349721hotspot/compilerAdd aarch64 intrinsics for ML-KEM
16JDK-8351412hotspot/compilerAdd AVX-512 intrinsics for ML-KEM
17JDK-8354926hotspot/compilerRemove remnants of debugging in the fix for JDK-8348561 and JDK-8349721
18JDK-8351034hotspot/compilerAdd AVX-512 intrinsics for ML-DSA
19JDK-8341527hotspot/compilerAVX-512 intrinsic for SHA3
20JDK-8348561hotspot/compilerAdd aarch64 intrinsics for ML-DSA
21JDK-8386578hotspot/compilerdouble_keccak stub does not set its return value on x86
22JDK-8364106hotspot/runtimeInclude java.runtime.version in thread dump output
23JDK-8375125hotspot/runtimeassert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer
24JDK-8353478performance/librariesUpdate crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms
25JDK-8340327security-libs/java.securityA common framework to support public key algorithms with standard parameter sets
26JDK-8320192security-libs/java.securitySHAKE256 does not work correctly if n >= 137
27JDK-8338587security-libs/java.securityInternal XOF Methods for SHAKE128 and SHAKE256
28JDK-8381771security-libs/java.securityAdd a check for DNS label not to end with a hyphen
29JDK-8356051security-libs/java.securityUpdate SignatureUtil.java with the new KnownOIDs
30JDK-8347606security-libs/java.securityOptimize Java implementation of ML-DSA
31JDK-8298387security-libs/java.securityImplement JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
32JDK-8345533security-libs/java.securitySwitch ML-DSA implementation to FIPS 204 final
33JDK-8367008security-libs/java.securityAlgorithm identifiers for HmacSHA* should always have NULL as params
34JDK-8298390security-libs/javax.cryptoImplement JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
35JDK-8347608security-libs/javax.cryptoOptimize Java implementation of ML-KEM
36JDK-8350589security-libs/javax.cryptoInvestigate cleaner implementation of AArch64 ML-DSA intrinsic introduced in JDK-8348561
37JDK-8189441security-libs/javax.cryptoDefine algorithm names for keys derived from KeyAgreement
38JDK-8374755security-libs/javax.cryptoML-KEM's 12-bit decompression can be simplified on aarch64
39JDK-8368694security-libs/javax.crypto:pkcs11PKCS11-NSS generic keys generated by DH have leading zeroes stripped