# Apache Log4J Vulnerability - CVE-2021-44228

**URL:** <https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050>\
**Category:** Ignition\
**Tags:** ignition79, ignition80, ignition81\
**Created:** [December 13, 2021, 2:50pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050 "2021-12-13T14:50:51Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 13, 2021, 2:50pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/1 "2021-12-13T14:50:51Z")

</div>

> On December 9th, 2021, a new vulnerability was reported ([CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)) against a common Java logging library, “log4j”. This vulnerability makes affected systems susceptible to having remote attackers be able to run malicious programs on said systems. This is also known as an RCE, or Remote Code Execution attack.
> 
> 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.
> 
> **No action is required by any Ignition user on any version of Ignition, LTS or not, to mitigate the effects of CVE-2021-44228.**

> **[Regarding CVE-2021-44228 - Log4j RCE 0-day](https://support.inductiveautomation.com/hc/en-us/articles/4416204541709-Regarding-CVE-2021-44228-Log4j-RCE-0-day)**
>
> On December 9th, 2021, a new vulnerability was reported (CVE-2021-44228) against a common Java logging library, “log4j”. This vulnerability makes affected systems susceptible to having remote attac...

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 13, 2021, 2:51pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/2 "2021-12-13T14:51:27Z")

</div>



---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 13, 2021, 4:27pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/4 "2021-12-13T16:27:32Z")

</div>



---

<div class="post-metadata">

**Author:** ![guanghui](https://avatars.discourse-cdn.com/v4/letter/g/43a26b/32.png) [@guanghui](https://forum.inductiveautomation.com/u/guanghui)\
**Post date:** [December 14, 2021, 2:45am UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/5 "2021-12-14T02:45:29Z")

</div>

Great! But is it possible to use log4j in third-party modules? if yes , will that be unsafe?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 14, 2021, 2:48am UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/6 "2021-12-14T02:48:39Z")

</div>

> [@Log4j vulnerability and third-party modules](https://forum.inductiveautomation.com/t/log4j-vulnerability-and-third-party-modules/54025/2):
>
> 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.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [December 14, 2021, 10:57am UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/7 "2021-12-14T10:57:15Z")

</div>

> [@guanghui](#):
>
> use log4j in third-party

Module install files are just zip files. You can just open them and look.

---

<div class="post-metadata">

**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\
**Post date:** [December 14, 2021, 3:41pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/8 "2021-12-14T15:41:45Z")

</div>

Over on their forum, CirrusLink confirmed that their Ignition modules and Chariot MQTT broker are safe.

> **[Log4j vulnerability (log4shell)](https://forum.cirrus-link.com/t/log4j-vulnerability-log4shell/139)**
>
> 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...

---

<div class="post-metadata">

**Author:** ![Kyle\_Chase](https://avatars.discourse-cdn.com/v4/letter/k/9de0a6/32.png) [@Kyle\_Chase](https://forum.inductiveautomation.com/u/Kyle_Chase)\
**Post date:** [December 15, 2021, 6:54pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/9 "2021-12-15T18:54:54Z")

</div>

Modules from Kymera Systems are also not affected by the Log4J vulnerability.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [December 15, 2021, 8:15pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/10 "2021-12-15T20:15:11Z")

</div>

So too with all of Automation Professionals’ modules.

---

<div class="post-metadata">

**Author:** ![richardNZ15](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/richardnz15/32/33373_2.png) [@richardNZ15](https://forum.inductiveautomation.com/u/richardNZ15)\
**Post date:** [December 15, 2021, 9:18pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/11 "2021-12-15T21:18:02Z")

</div>

I just received a report from a customer that use Crowdstrike for vulnerability management, and they provided the following details in their report:

> Here are the details of Log4j that have been detected -
> 
> Version: log4j-over-slf4j-1.7.26.

It looks like the log4j library is detected here:  
lib/core/common/log4j-over-slf4j-1.7.26.jar

This is on Ignition 8.1.7.

Sounds like the vulnerability is only for log4j versions 2.0.1 to 2.15.0, which would make this version used by Ignition ok?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 15, 2021, 9:28pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/12 "2021-12-15T21:28:54Z")

</div>

False positive.

> [@Log4J on Linux & Windows](https://forum.inductiveautomation.com/t/log4j-on-linux-windows/54005/4):
>
> Yes, should be good to go. The last version of Ignition that used log4j was 7.8, and it used something like log4j version 1.2.x, which isn’t affected by this CVE. Those who snoop around may find an artifact called log4j-over-slf4j, but this just a bridge that let us move from log4j to slf4j/logback without modifying every single file that had used a log4j logger.

---

<div class="post-metadata">

**Author:** ![dion.botha](https://avatars.discourse-cdn.com/v4/letter/d/46a35a/32.png) [@dion.botha](https://forum.inductiveautomation.com/u/dion.botha)\
**Post date:** [January 13, 2022, 11:08pm UTC](https://forum.inductiveautomation.com/t/apache-log4j-vulnerability-cve-2021-44228/54050/13 "2022-01-13T23:08:55Z")

</div>

I was asked about this by our IT security department a few days after the venerability was discovered. Just wanted to give a shout out to IA, it was super easy to find and share this post which alleviated immediate concern and probably installed greater approval in the Ignition platform from their perspective!
