Artem Smotrakov

**Name of the Vulnerable Software and Affected Versions** Java SE versions 7u311, 8u301, 11.0.12, 17 Oracle GraalVM Enterprise Edition versions 20.3.3 and 21.2.0 **Description** The issue is related to the JSSE component and allows an unauthenticated attacker with network access via TLS to compromise Java SE and Oracle GraalVM Enterprise Edition, resulting in unauthorized read access to a subset of accessible data. This typically affects Java deployments that load and run untrusted code and rely on the Java sandbox for security. The vulnerability can also be exploited through APIs in the specified component. **Recommendations** For Java SE versions 7u311, 8u301, 11.0.12, 17, update to a version that includes the fix for this issue. For Oracle GraalVM Enterprise Edition versions 20.3.3 and 21.2.0, update to a version that includes the fix for this issue. As a temporary workaround, consider restricting access to the JSSE component until a patch is available. Avoid using APIs in the specified component that supply data to untrusted sources until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Apache jUDDI versions prior to 3.3.10 **Description** The issue is related to the use of Java's Remote Method Invocation (RMI) in Apache jUDDI, which provides an alternate transport for accessing UDDI services. RMI uses the default Java serialization mechanism to pass parameters in RMI invocations. A remote attacker can send a malicious serialized object to the RMI entries, and the objects get deserialized without any check on the incoming data. This may allow the attacker to run arbitrary code remotely. The usage of RMI is disabled by default in both jUDDI web service applications and jUDDI clients, and the likelihood of impact is low. **Recommendations** For versions prior to 3.3.10, consider disabling the RMI feature to minimize the risk of exploitation, as all RMI related code was removed starting with version 3.3.10. At the moment, there is no information about additional mitigation measures for this vulnerability.

Name of the Vulnerable Software and Affected Versions: OpenNMS Meridian versions 2016 through 2018 before 2018.1.25 OpenNMS Meridian versions 2019 before 2019.1.16 OpenNMS Meridian versions 2020 before 2020.1.5 OpenNMS Horizon versions 1.2 through 27.0.4 OpenNMS Newts versions prior to 1.5.3 Description: The issue allows for local and remote code execution using JEXL expressions due to incorrect access control. Recommendations: For OpenNMS Meridian versions 2016 through 2018 before 2018.1.25, update to version 2018.1.25 or later. For OpenNMS Meridian versions 2019 before 2019.1.16, update to version 2019.1.16 or later. For OpenNMS Meridian versions 2020 before 2020.1.5, update to version 2020.1.5 or later. For OpenNMS Horizon versions 1.2 through 27.0.4, update to a version later than 27.0.4. For OpenNMS Newts versions prior to 1.5.3, update to version 1.5.3 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Olingo versions 4.0.0 through 4.7.0 **Description** The issue allows for a potential Server-Side Request Forgery (SSRF) attack. This occurs because the AsyncRequestWrapperImpl class reads a URL from the Location header and then sends a GET or DELETE request to this URL. An attacker could trick a client into connecting to a malicious server, which could then make the client call any URL, including internal resources that are not directly accessible to the attacker. **Recommendations** For Apache Olingo versions 4.0.0 through 4.7.0, consider restricting access to the AsyncRequestWrapperImpl class until a patch is available, or implement validation on the URLs read from the Location header to prevent requests to internal or unauthorized resources.

**Name of the Vulnerable Software and Affected Versions** Apache Olingo versions 4.0.0 through 4.6.0 **Description** The issue concerns the AbstractService class in Apache Olingo, which uses ObjectInputStream without checking the classes being deserialized. This could allow an attacker to execute malicious code if they can provide malicious metadata to the class. **Recommendations** For Apache Olingo versions 4.0.0 through 4.6.0, consider restricting access to the AbstractService class until a patch is available. As a temporary workaround, avoid using the ObjectInputStream functionality in the AbstractService class to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Apache Olingo versions 4.0.0 through 4.6.0 **Description** The issue allows a malicious server to potentially implement a Denial of Service (DoS) attack by returning a large value in the Retry-After header, which is then passed to the Thread.sleep() method without any validation. **Recommendations** For Apache Olingo versions 4.0.0 through 4.6.0, consider implementing input validation for the Retry-After header to prevent excessively large values from being passed to the Thread.sleep() method. As a temporary workaround, consider restricting access to the AsyncResponseWrapperImpl class until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Java SE versions 6u201, 7u191, 8u182 and 11 Java SE Embedded version 8u181 **Description** The issue allows an unauthenticated attacker with network access via multiple protocols to compromise Java SE and Java SE Embedded. Successful attacks require human interaction from a person other than the attacker and can result in unauthorized read access to a subset of Java SE and Java SE Embedded accessible data. This issue applies to Java deployments that load and run untrusted code and rely on the Java sandbox for security, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets. **Recommendations** For Java SE versions 6u201, 7u191, 8u182 and 11, update to a version that includes the fix for this issue. For Java SE Embedded version 8u181, update to a version that includes the fix for this issue. As a temporary workaround, consider restricting access to untrusted code in Java deployments to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.