CVE’s

FactoryTalk Linx versions 6.00, 6.10, and 6.11, RSLinx Classic v4.11.00 and prior,Connected Components Workbench: Version 12 and prior, ControlFLASH: Version 14 and later, ControlFLASH Plus: Version 1 and later, FactoryTalk Asset Centre: Version 9 and later, FactoryTalk Linx CommDTM: Version 1 and later, Studio 5000 Launcher: Version 31 and later Stud, 5000 Logix Designer software: Version 32 and prior is vulnerable. The parsing mechanism that processes certain file types does not provide input sanitation. This may allow an attacker to use specially crafted files to traverse the file system and modify or expose sensitive data or execute arbitrary code.

The affected product is vulnerable to the handling of serialized data. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data on the Ignition 8 Gateway (versions prior to 8.0.10) and Ignition 7 Gateway (versions prior to 7.9.14), allowing an attacker to obtain sensitive information.

A remote code execution vulnerability exists in Microsoft SharePoint when the software fails to check the source markup of an application package, aka 'Microsoft SharePoint Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2020-1210, CVE-2020-1452, CVE-2020-1453, CVE-2020-1576, CVE-2020-1595.

FactoryTalk Linx versions 6.00, 6.10, and 6.11, RSLinx Classic v4.11.00 and prior,Connected Components Workbench: Version 12 and prior, ControlFLASH: Version 14 and later, ControlFLASH Plus: Version 1 and later, FactoryTalk Asset Centre: Version 9 and later, FactoryTalk Linx CommDTM: Version 1 and later, Studio 5000 Launcher: Version 31 and later Stud, 5000 Logix Designer software: Version 32 and prior is vulnerable. An exposed API call allows users to provide files to be processed without sanitation. This may allow an attacker to specify a filename to execute unauthorized code and modify files or data.

A regression has been introduced in the commit preventing JMX re-bind. By passing an empty environment map to RMIConnectorServer, instead of the map that contains the authentication credentials, it leaves ActiveMQ open to the following attack: https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html "A remote client could create a javax.management.loading.MLet MBean and use it to create new MBeans from arbitrary URLs, at least if there is no security manager. In other words, a rogue remote client could make your Java application execute arbitrary code." Mitigation: Upgrade to Apache ActiveMQ 5.15.13

Apache Guacamole 1.2.0 and earlier do not consistently restrict access to connection history based on user visibility. If multiple users share access to the same connection, those users may be able to see which other users have accessed that connection, as well as the IP addresses from which that connection was accessed, even if those users do not otherwise have permission to see other users.

A specially crafted sequence of HTTP/2 requests sent to Apache Tomcat 10.0.0-M1 to 10.0.0-M5, 9.0.0.M1 to 9.0.35 and 8.5.0 to 8.5.55 could trigger high CPU usage for several seconds. If a sufficient number of such requests were made on concurrent HTTP/2 connections, the server could become unresponsive.

A deserialization vulnerability existed in dubbo 2.7.5 and its earlier versions, which could lead to malicious code execution. Most Dubbo users use Hessian2 as the default serialization/deserialization protool, during Hessian2 deserializing the HashMap object, some functions in the classes stored in HasMap will be executed after a series of program calls, however, those special functions may cause remote command execution. For example, the hashCode() function of the EqualsBean class in rome-1.7.0.jar will cause the remotely load malicious classes and execute malicious code by constructing a malicious request. This issue was fixed in Apache Dubbo 2.6.9 and 2.7.8.

Server-Side Template Injection and arbitrary file disclosure on Camel templating components

Apache HTTP Server versions 2.4.20 to 2.4.43 When trace/debug was enabled for the HTTP/2 module and on certain traffic edge patterns, logging statements were made on the wrong connection, causing concurrent use of memory pools. Configuring the LogLevel of mod_http2 above "info" will mitigate this vulnerability for unpatched servers.