Last updated 25 August 2025

A use-after-free flaw was found in the way the AWT component of OpenJDK performed loading of the GTK library. An untrusted Java application or applet could use this flaw to possibly bypass certain Java sandbox restrictions.

It was discovered that the DHKeyAgreement and P11KeyAgreement implementations in the JCE component of OpenJDK did not guarantee sufficient strength of used keys to adequately protect generated shared secret. This could make it easier to break encryption by attacking key agreement rather than the encryption using the negotiated key.

The patch for this issue causes classes' method generateSecret(String algorithm) to fail unless it's call for "TlsPremasterSecret", or the "jdk.crypto.KeyAgreement.legacyKDF" system property is set to true.

It was discovered that the JGSS component of OpenJDK failed to properly handle GSS context in the native GSS library wrapper in certain cases. A remote attacker could possibly make a Java application using JGSS to use previously freed context.

It was discovered that the DerValue class in the Libraries component of OpenJDK failed to sufficiently limit the amount of memory allocated when reading DER (Distinguished Encoding Rules) encoded input. It could allocate a large amount of memory even when processing short input. A remote attacker could possibly use this flaw to make a Java application use an excessive amount of memory if it parsed attacker-supplied DER encoded input.

It was discovered that the implementation of the ArrayBlockingQueue class in the Libraries component of OpenJDK did not check that all assumed invariants were satisfied after creating object instance from a serialized form, leaving the instance in an inconsistent state. If a Java application deserialized a specially-crafted input, this could cause it to raise an unexpected exceptions or allocate an excessive amount of memory.

It was discovered that the implementation of the Path2D and CSS classes in the AWT component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

It was discovered that the implementation of the BasicAttributes class in the JDNI component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.