Log4j vulnerability (log4shell)

Does CirrusLink have any statement on whether any of their products are affected by the log4j vulnerability, and if vulnerable how customers can mitigate any exposure in the short term, and when we can expect long term fixes?

I suspect the Ignition modules probably build on the logging system provided by Ignition, which Kevin Herron has informally stated is not affected in these two forum posts:

The Cirrus Link modules do use Ignition’s log system which is SLF4J - not Log4J. As a result, the modules are unaffected by this CVE. We did discover that some of the modules do unnecessarily include log4j jar files. But, these are never loaded/used and are as a result, benign. These jars will be removed in future versions.

1 Like

Sounds good. :+1:

How about standalone apps like Chariot?

Chariot includes an older version of log4j (1.2.17) that is not affected by this CVE. Like the modules, it is not used and will be removed in future versions.

1 Like

I know future versions will not include the log4j anymore.

To prevent false positives any time IT scans the machine; are we able to just delete the jar file? I assume since it not used it is never loaded and should not be care if the file exist.

Deleting the jar file is not a viable option because the modules are signed. For builds with the log4j jar excluded the nightly builds have been updated here:


Future GA releases will also exclude this jar. It is also important to note this version of log4j that was included was not affected by this CVE.

1 Like

All references to any version of log4j have been removed in the latest versions of our modules. They are available here:

Compatibility for the new module versions are shown here:

1 Like