Artem Smotrakov

**Nome do software vulnerável e versões afetadas** Versões 7u311, 8u301, 11.0.12 e 17 do Java SE Versões 20.3.3 e 21.2.0 do Oracle GraalVM Enterprise Edition **Descrição** O problema está relacionado ao componente JSSE e permite que um invasor não autenticado com acesso à rede via TLS comprometa o Java SE e o Oracle GraalVM Enterprise Edition, resultando em acesso de leitura não autorizado a um subconjunto de dados acessíveis. Isso normalmente afeta implantações Java que carregam e executam código não confiável e dependem da sandbox do Java para segurança. A vulnerabilidade também pode ser explorada por meio de APIs no componente especificado. **Recomendações** Para as versões 7u311, 8u301, 11.0.12 e 17 do Java SE, atualize para uma versão que inclua a correção para este problema. Para as versões 20.3.3 e 21.2.0 do Oracle GraalVM Enterprise Edition, atualize para uma versão que inclua a correção para este problema. Como solução alternativa temporária, considere restringir o acesso ao componente JSSE até que um patch esteja disponível. Evite usar APIs no componente especificado que forneçam dados a fontes não confiáveis até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** Versões do Apache jUDDI anteriores à 3.3.10 **Descrição** O problema está relacionado ao uso da Invocação Remota de Métodos (RMI) do Java no Apache jUDDI, que oferece um meio alternativo de acesso aos serviços UDDI. A RMI utiliza o mecanismo padrão de serialização do Java para passar parâmetros nas invocações RMI. Um invasor remoto pode enviar um objeto serializado malicioso para as entradas RMI, e os objetos são deserializados sem qualquer verificação dos dados recebidos. Isso pode permitir que o invasor execute código arbitrário remotamente. O uso do RMI está desativado por padrão tanto nos aplicativos de serviço web do jUDDI quanto nos clientes do jUDDI, e a probabilidade de impacto é baixa. **Recomendações** Para versões anteriores à 3.3.10, considere desativar o recurso RMI para minimizar o risco de exploração, já que todo o código relacionado ao RMI foi removido a partir da versão 3.3.10. No momento, não há informações sobre medidas de mitigação adicionais para esta vulnerabilidade.

**Nome do software vulnerável e versões afetadas: OpenNMS Meridian, versões de 2016 a 2018 anteriores à 2018.1.25 OpenNMS Meridian, versões de 2019 anteriores à 2019.1.16 OpenNMS Meridian, versões de 2020 anteriores à 2020.1.5 Versões do OpenNMS Horizon de 1.2 a 27.0.4 Versões do OpenNMS Newts anteriores à 1.5.3 Descrição: A vulnerabilidade permite a execução de código local e remota usando expressões JEXL devido a um controle de acesso incorreto. Recomendações: Para as versões do OpenNMS Meridian de 2016 a 2018 anteriores à 2018.1.25, atualize para a versão 2018.1.25 ou posterior. Para as versões do OpenNMS Meridian 2019 anteriores à 2019.1.16, atualize para a versão 2019.1.16 ou posterior. Para as versões do OpenNMS Meridian 2020 anteriores à 2020.1.5, atualize para a versão 2020.1.5 ou posterior. Para as versões do OpenNMS Horizon de 1.2 a 27.0.4, atualize para uma versão posterior à 27.0.4. Para as versões do OpenNMS Newts anteriores à 1.5.3, atualize para a versão 1.5.3 ou posterior.

**Nome do software vulnerável e versões afetadas** Apache Olingo, versões 4.0.0 a 4.7.0 **Descrição** A vulnerabilidade permite um potencial ataque de falsificação de solicitação do lado do servidor (SSRF). Isso ocorre porque a classe AsyncRequestWrapperImpl lê uma URL do cabeçalho Location e, em seguida, envia uma solicitação GET ou DELETE para essa URL. Um invasor poderia induzir um cliente a se conectar a um servidor malicioso, o que poderia fazer com que o cliente chamasse qualquer URL, incluindo recursos internos que não são diretamente acessíveis ao invasor. **Recomendações** Para as versões 4.0.0 a 4.7.0 do Apache Olingo, considere restringir o acesso à classe AsyncRequestWrapperImpl até que um patch esteja disponível ou implemente a validação das URLs lidas do cabeçalho Location para impedir solicitações a recursos internos ou não autorizados.

**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.