High · CVSS 6.4CVE-2025-13911

Inductive Automation Ignition Execution with Unnecessary PrivilegesCVE-2025-13911

Answer in brief

CVE-2025-13911 records a High severity (CVSS 6.4) vulnerability in Inductive Automation Ignition Execution with Unnecessary Privileges. The current sources do not mark it as known exploited. The current feed maps Inductive Automation/Ignition (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Dec 18, 2025Updated Aug 28, 2026Source checked Oct 12, 2026First seen by HOL Aug 28, 2026Material review Aug 28, 2026

Upstream Advisory

Key facts

Risk: High · CVSS 6.4
Exploitation: Not marked as known exploited
Affected software: 1 mapped package or product
Fix availability: Not reported

Why this deserves its current priority

CVSS is 6.4. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Inductive Automation/Ignition (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Inductive Automation/Ignitiongeneric	8.1.x \|\| 8.3.x	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Inductive Automation/Ignition.
Review the reported fix. Source-reported workarounds: Inductive Automation encourages users to do the following in order to reduce the risk of this vulnerability: * Create a new dedicated local Windows account that will be used exclusively for the Ignition service (e.g. svc-ign) (this should not be a domain account). * Remove all group memberships from the service account (including Users and Administrators). * Add to security policy to log in as a service. * Add to “Deny log on locally” security policy. * Provide full read/write access only to the Ignition installation directory for the service account created in step 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). * Set deny access settings for service account on other directories not needed by the Ignition service. * Specifically the C:\Windows, C:\Users, and directories for any other applications in the Program Files or Program Files (x86) directories. * 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. * Restrict project imports to verified and trusted sources only, ideally using checksums or digital signatures. * 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. * When feasible, segment or isolate Ignition gateways from corporate resources and Windows Domains. * 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. * 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. * 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). * When feasible, deploy Ignition within hardened or containerized environments. Mitigation guidance covering OS-level service account hardening for both Windows and Linux is available in Annex A of the Ignition Security Hardening Guide. Application-level controls under a default installation are in development. For more information and updates, users should refer to Inductive Automation's Trust Portal https://security.inductiveautomation.com .

Evidence timeline and material changes

Published upstream
Dec 18, 2025
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Aug 28, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Aug 28, 2026

Sources and claim methodology

Upstream source description

Ignition by Inductive Automation, when installed with default OS service account settings, may expose the host system to an elevated code execution risk via the gateway backup restore functionality. An authenticated user with Gateway Administrator privileges can import a malicious gateway backup (.gwbk) file containing crafted project resources, scripts, or modules, resulting in code execution on the host system. This affects both Windows and Linux installations. On Windows, default installations often run the Ignition service as NT AUTHORITY\SYSTEM, resulting in code execution with full local system privileges. On Linux, default installations commonly run the Ignition service as root or with elevated privileges. Specific privilege level depends on installation configuration.

Quoted source text, attributed separately from HOL analysis.