I’ve seen the answers from Kevin regarding the log4j exploit being a non-issue for the core Ignition platform (here and here), thank you for those responses they really help ease concerns.
Given Ignition’s modular structure, it still seems theoretically possible that third party modules may introduce this vulnerability. Is there any way to confirm that at the very least the modules listed on the downloads page don’t introduce this vulnerability? These include:
EAM
Perspective
Reporting
SFC
SQL Bridge
Symbol Factory
Tag Historian
Vision
Web Browser
Web Dev
AB
Logix5000
BACnet
DNP3
Modbus
OPC COM
OPC-UA
Omicron
OpcCom Tunneller
SECS/GEM
Serial Support Client
Serial Support Gateway
Siemens
UDP and TCP
Alarm
SMS
Twilio
Voice
Is there a plan in place to vet the strategic partner modules listed on the Inductive Automation website to ensure that this vulnerability was not introduced by them as well? Any information on this attack vector is appreciated.
We can talk to our strategic partners, but all the modules you listed are ours and they do not include log4j.
The whole idea of a 3rd party bringing log4j as a dependency is very unusual - the logging backend is provided by the Ignition platform and anybody who knows what they are doing would log using the SLF4J logging API and not introduce a parallel logging backend, which would result in an additional set of logs/files being generated.
Since this is one of the top search engine results, I thought I'd share our official response.
The most relevant paragraph:
Inductive Automation has conducted a full audit of Ignition’s direct and transitive dependencies to confirm that log4j is not used or included in any supported or unsupported release of Ignition, and as such it is not vulnerable to the RCE outlined in CVE-2021-44228. This includes LTS versions 7.9 and 8.1, as well as all past and non-LTS versions. While Ignition versions 7.8 and prior did use log4j for its logging backend, the version used (1.2.x) is not affected.