CWE-611 Improper Restriction of XML External Entity Reference vulnerability exists that could cause information disclosure of server-side file contents when an attacker with a Data Center Expert user account submits crafted XML payloads to SOAP service endpoints.

A CWE-94: Improper Control of Generation of Code ('Code Injection') vulnerability exists that could cause remote code execution when an admin user on DCE tampers with backups which are then manually restored.

A CWE-94: Improper Control of Generation of Code ('Code Injection') vulnerability exists that could cause remote code execution when an admin user on DCE uploads or tampers with install packages.

A CWE-89: Improper Neutralization of Special Elements vulnerability used in an SQL Command ('SQL Injection') vulnerability exists that could allow a user already authenticated on DCE to access unauthorized content, change, or delete content, or perform unauthorized actions when tampering with the mass configuration settings of endpoints on DCE.

A CWE-89: Improper Neutralization of Special Elements vulnerability used in an SQL Command ('SQL Injection') vulnerability exists that could allow a user already authenticated on DCE to access unauthorized content, change, or delete content, or perform unauthorized actions when tampering with the alert settings of endpoints on DCE.

Last updated 25 August 2025

Last updated 25 August 2025

It was discovered that the Security component of OpenJDK did not correctly perform merging of multiple sections for the same file listed in the JAR archive file manifest. An attacker could possibly use this flaw to alter certain attributes specified in the manifest without changing archive signature.

It was discovered that the RMI component of OpenJDK enabled HTTP transport for RMI servers by default. This could possibly expose RMI services to attackers who can not connect to them directly by attacking web browsers of users able to directly connect to the services.

The fix for this issue disables the use of RMI HTTP transport by default. System properly java.rmi.server.disableIncomingHttp (with the default value of "true") can be used to enable HTTP transport.

It was discovered that the implementation of the PriorityBlockingQueue class in the Concurrency 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 TabularDataSupport class in the JMX 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 Container class 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 NamedNodeMapImpl class in the JAXP 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 StubIORImpl class in the Serialization 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 deserialization of multiple classes in the Security component of OpenJDK did not properly ensure consistency of the instances created form the 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 Security component of OpenJDK did not restrict which classes could be used when deserializing keys form the JCEKS key stores. A specially crafted JCEKS key store could possibly use this flaw to execute arbitrary code with the privileges of an application reading data form the key store.

The fix adds support for a new security property jceks.key.serialFilter which can be used to specify classes that can be used when deserializing data from the JCEKS key stores.

A flaw was found in the way the Hotspot component of OpenJDK handled clones of the java.lang.ref.Reference objects. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions (a commonly used performance optimization).

It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory read from address to which a recent memory write has occurred may see an older value and subsequently cause an update into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire).

As a result, an unprivileged attacker could use this flaw to read privileged memory by conducting targeted cache side-channel attacks.

It was discovered that the LDAPCertStore class in the JNDI component of OpenJDK failed to securely handle LDAP referrals. An attacker could possibly use this flaw to make the LDAPCertStore fetch attacker-controlled certificate data.

It was discovered that the JMX component of OpenJDK failed to properly set the deserialization filter for the SingleEntryRegistry in certain cases. A remote attacker could possibly use this flaw to bypass intended deserialization restrictions.

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.