{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2025-13911","assignerOrgId":"7d14cffa-0d7d-4270-9dc0-52cabd5a23a6","state":"PUBLISHED","assignerShortName":"icscert","dateReserved":"2025-12-02T17:14:36.352Z","datePublished":"2025-12-18T20:24:30.118Z","dateUpdated":"2025-12-18T20:45:07.276Z"},"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Ignition","vendor":"Inductive Automation","versions":[{"status":"affected","version":"8.1.x"},{"status":"affected","version":"8.3.x"}]}],"credits":[{"lang":"en","type":"finder","value":"Momen Eldawakhly of Samurai Digital Security Ltd reported this vulnerability to CISA"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"The vulnerability affects Ignition SCADA applications where Python \nscripting is utilized for automation purposes. The vulnerability arises \nfrom the absence of proper security controls that restrict which Python \nlibraries can be imported and executed within the scripting environment.\n The core issue lies in the Ignition service account having system \npermissions beyond what an Ignition privileged user requires. When an \nauthenticated administrator uploads a malicious project file containing \nPython scripts with bind shell capabilities, the application executes \nthese scripts with the same privileges as the Ignition Gateway process, \nwhich typically runs with SYSTEM-level permissions on Windows. \nAlternative code execution patterns could lead to similar results.\n\n<br>"}],"value":"The vulnerability affects Ignition SCADA applications where Python \nscripting is utilized for automation purposes. The vulnerability arises \nfrom the absence of proper security controls that restrict which Python \nlibraries can be imported and executed within the scripting environment.\n The core issue lies in the Ignition service account having system \npermissions beyond what an Ignition privileged user requires. When an \nauthenticated administrator uploads a malicious project file containing \nPython scripts with bind shell capabilities, the application executes \nthese scripts with the same privileges as the Ignition Gateway process, \nwhich typically runs with SYSTEM-level permissions on Windows. \nAlternative code execution patterns could lead to similar results."}],"metrics":[{"cvssV3_1":{"attackComplexity":"HIGH","attackVector":"ADJACENT_NETWORK","availabilityImpact":"HIGH","baseScore":6.4,"baseSeverity":"MEDIUM","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"HIGH","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]},{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"HIGH","attackRequirements":"NONE","attackVector":"ADJACENT","baseScore":7.3,"baseSeverity":"HIGH","exploitMaturity":"NOT_DEFINED","privilegesRequired":"HIGH","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"CVSS:4.0/AV:A/AC:H/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","version":"4.0","vulnAvailabilityImpact":"HIGH","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-250","description":"CWE-250","lang":"en","type":"CWE"}]}],"providerMetadata":{"orgId":"7d14cffa-0d7d-4270-9dc0-52cabd5a23a6","shortName":"icscert","dateUpdated":"2025-12-18T20:24:30.118Z"},"references":[{"url":"https://security.inductiveautomation.com/"},{"url":"https://www.cisa.gov/news-events/ics-advisories/icsa-25-352-01"},{"url":"https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2025/icsa-25-352-01.json"}],"source":{"advisory":"ICSA-25-352-01","discovery":"EXTERNAL"},"title":"Inductive Automation Ignition Execution with Unnecessary Privileges","workarounds":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<p>Inductive Automation encourages users to do the following in order to reduce the risk of this vulnerability:</p>\n<ol>\n<li>Create a new dedicated local Windows account that will be used \nexclusively for the Ignition service (e.g. svc-ign) (this should not be a\n domain account).</li>\n<li>Remove all group memberships from the service account (including Users and Administrators). </li>\n<li>Add to security policy to log in as a service.</li>\n<li>Add to “Deny log on locally” security policy.</li>\n<li>Provide full read/write access only to the Ignition installation directory for the service account created in step 1.</li>\n<li>Add read/write permissions to other directories in the local \nfilesystem as needed (e.g: if configured to use optional Enterprise \nAdministration Module to write automated backups to the file system). </li>\n<li>Set deny access settings for service account on other directories not needed by the Ignition service.</li>\n<li>Specifically the C:\\Windows, C:\\Users, and directories for any other\n applications in the Program Files or Program Files(x86) directories.</li>\n<li>Use java param to change temp directory to a location within the \nIgnition install directory so the Users folder can be denied access to \nthe Ignition service account.</li>\n<li>Restrict project imports to verified and trusted sources only, ideally using checksums or digital signatures.</li>\n<li>Use multiple environments (e.g. Dev, Test, Prod) with a staging \nworkflow so that new data is never introduced directly to Production \nenvironments. See Ignition Deployment Best Practices. </li>\n<li>When feasible, segment or isolate Ignition gateways from corporate resources and Windows Domains. </li>\n<li>The Ignition service account or AD server object should never need \nWindows Domain or Windows Active Directory privileges. This would only \nbe needed if an Asset Owners IT or OT department uses this for \nmanagement outside Ignition. </li>\n<li>Ignition may be federated with Active Directory environments (e.g. \nOT domains) by entering “Authentication Profile” credentials within the \nIgnition gateway itself. This could use secure LDAP, SAML, or OpenID \nConnect.  </li>\n<li>When feasible, enforce strong credential management and MFA for all \nusers with Designer permissions (8.1.x and 8.3.x), Config Page \npermissions (8.1.x), and Config Write permissions (8.3.x).</li>\n<li>When feasible, deploy Ignition within hardened or containerized environments.</li>\n</ol>\n<p>For more information and updates, users should refer to <a target=\"_blank\" rel=\"nofollow\" href=\"https://security.inductiveautomation.com\">Inductive Automation's Trust Portal</a>.</p>\n\n<br>"}],"value":"Inductive Automation encourages users to do the following in order to reduce the risk of this vulnerability:\n\n\n\n  *  Create a new dedicated local Windows account that will be used \nexclusively for the Ignition service (e.g. svc-ign) (this should not be a\n domain account).\n\n  *  Remove all group memberships from the service account (including Users and Administrators). \n\n  *  Add to security policy to log in as a service.\n\n  *  Add to “Deny log on locally” security policy.\n\n  *  Provide full read/write access only to the Ignition installation directory for the service account created in step 1.\n\n  *  Add read/write permissions to other directories in the local \nfilesystem as needed (e.g: if configured to use optional Enterprise \nAdministration Module to write automated backups to the file system). \n\n  *  Set deny access settings for service account on other directories not needed by the Ignition service.\n\n  *  Specifically the C:\\Windows, C:\\Users, and directories for any other\n applications in the Program Files or Program Files(x86) directories.\n\n  *  Use java param to change temp directory to a location within the \nIgnition install directory so the Users folder can be denied access to \nthe Ignition service account.\n\n  *  Restrict project imports to verified and trusted sources only, ideally using checksums or digital signatures.\n\n  *  Use multiple environments (e.g. Dev, Test, Prod) with a staging \nworkflow so that new data is never introduced directly to Production \nenvironments. See Ignition Deployment Best Practices. \n\n  *  When feasible, segment or isolate Ignition gateways from corporate resources and Windows Domains. \n\n  *  The Ignition service account or AD server object should never need \nWindows Domain or Windows Active Directory privileges. This would only \nbe needed if an Asset Owners IT or OT department uses this for \nmanagement outside Ignition. \n\n  *  Ignition may be federated with Active Directory environments (e.g. \nOT domains) by entering “Authentication Profile” credentials within the \nIgnition gateway itself. This could use secure LDAP, SAML, or OpenID \nConnect.  \n\n  *  When feasible, enforce strong credential management and MFA for all \nusers with Designer permissions (8.1.x and 8.3.x), Config Page \npermissions (8.1.x), and Config Write permissions (8.3.x).\n\n  *  When feasible, deploy Ignition within hardened or containerized environments.\n\n\nFor more information and updates, users should refer to  Inductive Automation's Trust Portal https://security.inductiveautomation.com ."}],"x_generator":{"engine":"Vulnogram 0.5.0"}},"adp":[{"metrics":[{"other":{"type":"ssvc","content":{"timestamp":"2025-12-18T20:44:32.471219Z","id":"CVE-2025-13911","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"total"}],"role":"CISA Coordinator","version":"2.0.3"}}}],"title":"CISA ADP Vulnrichment","providerMetadata":{"orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP","dateUpdated":"2025-12-18T20:45:07.276Z"}}]}}