# Java concerns with Ignition

**URL:** <https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996>\
**Category:** General Discussion\
**Created:** [April 4, 2022, 2:43pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996 "2022-04-04T14:43:12Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![Curlyandshemp](https://avatars.discourse-cdn.com/v4/letter/c/bcef8e/32.png) [@Curlyandshemp](https://forum.inductiveautomation.com/u/Curlyandshemp)\
**Post date:** [April 4, 2022, 2:43pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/1 "2022-04-04T14:43:12Z")

</div>

I have a customer that has concerns about Java and the security concerns around Java. Is there a white paper or article that can address this?  
This customer’s IT department is hestitant to install Ignition on their server.

---

<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:** [April 4, 2022, 3:03pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/2 "2022-04-04T15:03:39Z")

</div>

> **[Java Security and Ignition](https://www.inductiveautomation.com/resources/article/java-security-and-ignition)**
>
> Java has been in the headlines of late for all the wrong reasons and recent Java security concerns have raised some eyebrows among the Ignition user community. In an effort to help put those concerns to rest, this white paper will cut through the...

---

<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:** [April 4, 2022, 3:12pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/3 "2022-04-04T15:12:17Z")

</div>

That’s a really old document. Even pitches java webstart as if it is current. Probably time to update it. A pointer to the log4j statement might be more helpful.

---

<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:** [April 4, 2022, 3:14pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/4 "2022-04-04T15:14:40Z")

</div>

Yep, probably should…

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [April 4, 2022, 3:14pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/5 "2022-04-04T15:14:54Z")

</div>

There was an announcement the last Thursday (2022-03-31, as of this writing) on a zero-day using Spring Framework. I don’t know if it applies to anything IA related.

> **[Spring Framework RCE, Early Announcement](https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement)**
>
> Updates  
>   
> \[04-04 10:45 BST\] Updated Am I Impacted with improved description for deployment requirements  
> \[04-01 16:35 BST\] Updated Am I Impacted with additional notes  
> \[04-01 13:05 BST\] Updated Suggested Workarounds section for Apache...

---

<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:** [April 4, 2022, 3:15pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/6 "2022-04-04T15:15:39Z")

</div>

> [@JordanCClark](#):
>
> I don’t know if it applies to anything IA related.

It does not.

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [April 4, 2022, 3:17pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/7 "2022-04-04T15:17:45Z")

</div>

Didn’t think so, but I’m sure there will be a flood of new threads…

EDIT: Link to the Log4J statement

> **[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:** [April 4, 2022, 3:19pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/8 "2022-04-04T15:19:58Z")

</div>

Perhaps. I wrote a one-line response last week and we’re prepared with an official response if necessary, but unless inbound inquiries ramp up to the log4j CVE levels I don’t think we’ll explicitly announce anything.

So far there’s been almost no chatter about this.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 4, 2022, 3:30pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/9 "2022-04-04T15:30:54Z")

</div>

The overall tl;dr on Java “security” is that it’s a lot of FUD that mostly dates back to when applets were an extant thing. In that context, running arbitrary code on your machine that can freely access your filesystem just by visiting a webpage _was_ terrible for security…but it’s not really Java that’s culpable, but the entire notion of applets.

Ignition 8.X versions ship with their own Java distribution (an up-to-date patch release of Java 11 at time of Ignition release). This Java distribution isn’t “installed” onto the OS of the gateway, Vision clients, designers, or Perspective sessions in any way; it’s just a flat series of files made available to the parts of Ignition that need it.

---

<div class="post-metadata">

**Author:** ![mathieurleblanc33](https://avatars.discourse-cdn.com/v4/letter/m/e19adc/32.png) [@mathieurleblanc33](https://forum.inductiveautomation.com/u/mathieurleblanc33)\
**Post date:** [April 6, 2022, 6:26pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/10 "2022-04-06T18:26:09Z")

</div>

I have 2 clients who are asking if Ignition is impacted by Zero-Day RCE Vulnerability. I was able to provide them IA’s official response in regards to the Log4J and this satisfied their IT department. Do you have any official or un-official comments if Ignition is impacted?

---

<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:** [April 6, 2022, 6:28pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/11 "2022-04-06T18:28:34Z")

</div>

> [@mathieurleblanc33](#):
>
> I have 2 clients who are asking if Ignition is impacted by Zero-Day RCE Vulnerability.

This isn't specific enough to answer your question.

> [@mathieurleblanc33](#):
>
> I was able to provide them IA’s official response in regards to the Log4J and this satisfied their IT department.

This is fine, but they may have been asking about the more recent one involving Spring Framework.

In either case Ignition is not impacted.

---

<div class="post-metadata">

**Author:** ![ben.hutche](https://avatars.discourse-cdn.com/v4/letter/b/9fc348/32.png) [@ben.hutche](https://forum.inductiveautomation.com/u/ben.hutche)\
**Post date:** [May 15, 2025, 2:17pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/12 "2025-05-15T14:17:39Z")

</div>

I still love GE's attempt at discrediting Java being used in SCADA products. Labelled 'Java-Based HMI/SCADA: Is It Worth the Risk?' I think they have since pulled it, but certainly a good read.

---

<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:** [May 15, 2025, 2:22pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/13 "2025-05-15T14:22:07Z")

</div>

> [@ben.hutche](#):
>
> GE's attempt at discrediting Java

Applied to Ignition, it's laughable. Applied to Honeywell's Niagara/JACE products, it is a serious concern. Last time I touched the latter, I had go way back in time in a VM to run the corresponding tools.

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [May 15, 2025, 3:12pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/14 "2025-05-15T15:12:31Z")

</div>

> [@pturmel](#):
>
> Honeywell's Niagara/JACE products

Also (now) Rockwell's Mach2, which is their Niagara-based "MES" software for Plex ERP. Plex has been on our facility for a couple of years and Mach2 is still running under Java 8 and using OPC-DA.

---

<div class="post-metadata">

**Author:** ![patrixmith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/patrixmith/32/75926_2.png) [@patrixmith](https://forum.inductiveautomation.com/u/patrixmith)\
**Post date:** [May 15, 2025, 3:35pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/15 "2025-05-15T15:35:12Z")

</div>

Oof, I might need to pick your brain. I am going to be putting half a dozen Opto22 EPIC controllers with Ignition Edge onboard to poll tags from Honeywell Niagara/JACE stuff here soon. Any hesitations or insights?

---

<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:** [May 15, 2025, 3:38pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/16 "2025-05-15T15:38:54Z")

</div>

It was a communication nightmare. Use the BACnet/IP driver if you can.

---

<div class="post-metadata">

**Author:** ![patrixmith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/patrixmith/32/75926_2.png) [@patrixmith](https://forum.inductiveautomation.com/u/patrixmith)\
**Post date:** [May 15, 2025, 3:51pm UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/17 "2025-05-15T15:51:23Z")

</div>

Ok, that makes me feel better. They are already using BACnet/IP to their existing Niagara HMI. I am replacing it with Ignition. So, hopefully we don't run into too many issues. We are just in the investigation stage.

---

<div class="post-metadata">

**Author:** ![ben.hutche](https://avatars.discourse-cdn.com/v4/letter/b/9fc348/32.png) [@ben.hutche](https://forum.inductiveautomation.com/u/ben.hutche)\
**Post date:** [May 16, 2025, 12:25am UTC](https://forum.inductiveautomation.com/t/java-concerns-with-ignition/57996/18 "2025-05-16T00:25:28Z")

</div>

I suppose at least with Java you have a client facing measure of if a codebase is being maintained 🙂

I know a few SCADA systems that have basically flat lined with the bare minimum of maintenance updates done to them.
