A JNDI rebind operation in the default ORB listener in Payara Server 4.1.2.191 (Enterprise), 5.20.0 and newer (Enterprise), and 5.2020.1 and newer (Community), when Java 1.8u181 and earlier is used, allows remote attackers to load malicious code on the server once a JNDI directory scan is performed.

Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via IIOP, T3 to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in takeover of Oracle WebLogic Server. Note: The patch for this issue will address the vulnerability only if the WLS instance is using JDK 1.7.0191 or later, or JDK 1.8.0181 or later. CVSS 3.0 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Vulnerability in the Java SE component of Oracle Java SE (subcomponent: Windows DLL). The supported version that is affected is Java SE: 8u202. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. While the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.0 Base Score 9.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).

Vulnerability in the Java SE component of Oracle Java SE (subcomponent: Java DB). Supported versions that are affected are Java SE: 6u191, 7u181 and 8u172. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. While the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVE-2018-2938 addresses CVE-2018-1313. CVSS 3.0 Base Score 9.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).

It was found that the Hotspot component of OpenJDK did not perform loader constraints checks in certain cases when handling ivokespecial JVM instruction. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

A flaw was found in the privileged code used to handle unreferenced objects in the Target class in the RMI component of OpenJDK. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Oracle Java SE 7u151 and 8u141 fixes an unspecified vulnerability in the JavaFX component (CVE-2017-10086). Upstream has CVSS scored this issue as: 9.6/CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

External Reference:

http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html#AppendixJAVA

It was discovered that the DCG (Distributed Garbage Collector) implementation in the RMI component of OpenJDK failed to correctly handle references. A remote attacker could possibly use this flaw to execute arbitrary code with the privileges of RMI registry or a Java RMI application.

It was discovered that the implementation of the TransformerException class in the JAXP component of OpenJDK failed to properly perform access control checks, related to handling of the DTM exceptions. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

It was discovered that the JAXP component of OpenJDK failed to restrict access to certain internal classes. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

The fix for this issue adds the following packages to the package.access security property, which defines the list of restricted internal packages not accessible to untrusted code:

com.sun.org.apache.xml.internal.resolver.helpers. com.sun.org.apache.xml.internal.resolver.readers.

It was discovered that the LambdaFormEditor class in the Libraries component of OpenJDK did not correctly perform bounds checks in the permuteArgumentsForm() function. An untrusted Java application or applet could use this flaw to corrupt JVM memory and cause it to crash or, possibly, execute arbitrary code, bypassing Java sandbox restrictions. The problem is triggered when using MethodHandle.permuteArguments().

Upstream report:

https://bugs.openjdk.java.net/browse/JDK-8184119 http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-July/005915.html

OpenJDK 9 upstream commit:

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9003926e4a8a

It was discovered that the implementation of the ImageWatched class in the AWT component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

It was discovered that the implementation of the ThreadPoolExecutor class in the java.util.concurrent package of the Libraries component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

It was discovered that the implementation of the AsynchronousChannelGroupImpl class in the java.nio.channels package of the Libraries component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

It was discovered that the implementation of the ServiceRegistry class in the ImageIO component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

It was discovered that the implementation of the ActivationID class in the RMI component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Unspecified vulnerability in Oracle Java SE 6u121, 7u111, and 8u102 allows remote attackers to affect confidentiality, integrity, and availability via vectors related to AWT.

Oracle Java SE 6u131, 7u121, and 8u111 fixes an unspecified vulnerability in the 2D component (CVE-2016-5556). Upstream has CVSS scored this issue as: 9.6/CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

External Reference:

http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html#AppendixJAVA

It was discovered that the Hotspot component of OpenJDK did not check types of System.arraycopy() function arguments src and dest in certain cases. An untrusted Java application or applet could use this flaw to corrupt virtual machine's memory and bypass Java sandbox restrictions.

It was discovered that the filterReturnValue() method of the MethodHandles in the Libraries component of OpenJDK did not properly check filter MethodHandle parameter count. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

It was discovered that the Hotspot component of OpenJDK did not properly restrict access to the invokeBasic() method of the MethodHandle class. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

A flaw was found in the way the dropArguments() method of the MethodHandles class in the Libraries component of OpenJDK handled its valueTypes argument. As it did not create a copy of the list, caller could modify it after it was checked by the dropArguments() method. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

It was discovered that the bytecode verifier in the Hotspot component of OpenJDK did not properly verify correctness of the bytecode in the loaded class files. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Oracle Java SE 6u115, 7u101 and 8u91 fixes an unspecified vulnerability in the 2D component (CVE-2016-3443). Upstream has CVSSv2 scored this issue as: 10.0/AV:N/AC:L/Au:N/C:C/I:C/A:C

External Reference:

http://www.oracle.com/technetwork/topics/security/cpuapr2016-2881694.html#AppendixJAVA

It was discovered that the Hotspot component of OpenJDK did not properly handle byte types. An untrusted Java application or applet could use this flaw to corrupt Java virtual machine memory and possibly execute arbitrary code, bypassing Java sandbox restrictions.

It was discovered that the ObjectInputStream class in the Serialization component of OpenJDK failed to properly ensure thread consistency when deserializing serialized input. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Unspecified vulnerability in Oracle Java SE 7u97, 8u73, and 8u74 allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to the Hotspot sub-component.

It was discovered that the JPEG decoder in the AWT component of OpenJDK did not use correct buffer boundary in certain cases when decoding JPEG files. A specially crafted JPEG file could cause a Java application to corrupt its memory and possibly execute arbitrary code when opened. An untrusted Java application or applet could also use this flaw to bypass Java sandbox restrictions.

Integer signedness issues were discovered in IndicRearrangementProcessor and IndicRearrangementProcessor2 in the ICU Layout Engine. A specially crafted font file could cause an application using ICU to parse untrusted fonts to crash and, possibly, execute arbitrary code.

ICU code is embedded the 2D component in OpenJDK and used by FontManager. An untrusted Java application or applet could use this flaw to execute arbitrary code with Java Virtual Machine privileges and bypass Java sandbox restrictions.

It was discovered that the ObjectStreamClass in the Serialization component of OpenJDK failed to ensure that the object is fully initialized before allowing calls of certain methods. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.