Is Mirth Connect affected by Log4j Vulnerabilities?

[kpitech]

Is Mirth connect affected by Log4j Vulnerabilities? By when are they planning to move to latest version of Log4j?

[pacmano1]

Please read #4892

[jgmiller618]

So I see the previous thread and the earlier announced vulnerability's impacting 2.x builds where Mirth uses 1.x. Recently 1.x was found to have 3 new vulnerability's https://logging.apache.org/log4j/1.2/. In which the 1.x has been EoL in 2015 and with 2.x replacing it as the fix. Can these be looked at and or any workarounds provided we can implement to our 1.x implementations.

• CVE-2022-23302 is a high severity deserialization vulnerability in JMSSink. JMSSink uses JNDI in an unprotected manner allowing any application using the JMSSink to be vulnerable if it is configured to reference an untrusted site or if the site referenced can be accesseed by the attacker. For example, the attacker can cause remote code execution by manipulating the data in the LDAP store.
• CVE-2022-23305 is a high serverity SQL injection flaw in JDBCAppender that allows the data being logged to modify the behavior of the component. By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed.
• CVE-2022-23307 is a critical severity against the chainsaw component in Log4j 1.x. This is the same issue corrected in CVE-2020-9493 fixed in Chainsaw 2.1.0 but Chainsaw was included as part of Log4j 1.2.x

[tonygermano]

Let's please not start a new discussion thread about this topic. Mirth does not ship configured to use any of the components affected by the vulnerabilities you mentioned. If you really need to say something, put it on #4892.