The Issue

On December 18th, 2025, a new vulnerability was published (CVE-2025-13911) regarding Ignition software running on Windows. This allows accidental or malicious resource imports by authenticated privileged users to execute with SYSTEM level permissions on Windows.

The vulnerability affects Ignition SCADA applications where Python scripting is utilized for automation purposes. The vulnerability arises from the absence of proper security controls that restrict which Python libraries can be imported and executed within the scripting environment. The core issue lies in the Ignition service account having system permissions beyond what an Ignition privileged user requires.  When an authenticated administrator uploads a malicious project file containing Python scripts with bind shell capabilities, the application executes these scripts with the same privileges as the Ignition Gateway process, which typically runs with SYSTEM-level permissions on Windows. Alternative code execution patterns could lead to similar results.

Inductive Automation (IA) would like to thank Momen Eldawakhly of Samurai Digital Security, Ltd for reporting this vulnerability, and Cybersecurity Infrastructure Security Agency for processing this disclosure.

The Solution

IA recommends being careful when importing files, such as verifying trustworthiness, especially on production systems. Ignition privileged activities are best done using a configuration managed, process based workflow, such as using separate development, test, and production environments per Ignition 8 Deployment best practices. IA also recommends following the Ignition Security Hardening Guide. 

The following configuration actions are recommended to implement the principle of least privilege and mitigate this vulnerability:

1. Create a new dedicated local Windows account that will be used exclusively for the Ignition service (e.g. svc-ign)
   1. The best security practice is that the Ignition service should not be a domain account (unless otherwise needed). 
   2. Remove all group memberships from the service account (including Users and Administrators). 
   3. Add to security policy to log in as a service
   4. Add to “Deny log on locally” security policy
2. Provide full read/write access only to the Ignition installation directory for the service account created in #1.
   1. Add read/write permissions to other directories in the local filesystem as needed (e.g: if configured to use optional Enterprise Administration Module to write automated backups to the file system). 
3. Set deny access settings for service account on other directories not needed by the Ignition service.
   1. Specifically the C:\Windows, C:\Users, and directories for any other applications in the Program Files or Program Files(x86) directories.
   2. Use java param to change temp directory to a location within the Ignition install directory so the Users folder can be denied access to the Ignition service account.

Note: The remaining steps below are considered best practices.

4. Restrict project imports to verified and trusted sources only, ideally using checksums or digital signatures.
5. Use multiple environments (e.g. Dev, Test, Prod) with a staging workflow so that new data is never introduced directly to Production environments. See Ignition Deployment Best Practices. 
6. When feasible, segment or isolate Ignition gateways from corporate resources and Windows Domains. 
   1. The Ignition service account or AD server object should never need Windows Domain or Windows Active Directory privileges. This would only be needed if an Asset Owners IT or OT department uses this for management outside Ignition. 
   2. Ignition may be federated with Active Directory environments (e.g. OT domains) by entering “Authentication Profile” credentials within the Ignition gateway itself. This could use secure LDAP, SAML, or OpenID Connect.  
7. When feasible, enforce strong credential management and MFA for all users with Designer permissions (8.1.x and 8.3.x), Config Page permissions (8.1.x), and Config Write permissions (8.3.x).
8. When feasible, deploy Ignition within hardened or containerized environments.