Back to Intelligence

CVE-2026-77393: Inductive Automation Ignition Lets Any Authenticated User Create Projects — Detection and Remediation Guide

SA
Security Arsenal Team
September 4, 2026
12 min read

CISA has published ICS Advisory ICSA-26-246-06 covering an incorrect default permissions flaw in Inductive Automation Ignition, one of the most widely deployed SCADA/IIoT gateway platforms on the planet. The flaw — tracked as CVE-2026-77393 (CVSS v3 8.8, High) — affects Ignition 8.1.53 and all earlier versions and is fixed in 8.1.54.

The root cause is deceptively simple: the Gateway's "Create Project Role(s)" setting shipped blank. In Ignition's permission model, a blank role list for this setting means no role restriction at all — so any authenticated user who can execute gateway scripts could create new projects on the Gateway. In an OT environment, project creation is not a paperwork function. Projects define tags, database connections, device bindings, and gateway-scoped Python scripts. Giving that capability to every authenticated account — including read-only operator accounts and low-privilege service identities — is a privilege-escalation and persistence opportunity inside your most sensitive control systems.

Ignition is deployed worldwide across Critical Manufacturing, Energy, and Information Technology sectors. If you run Ignition Gateways anywhere near your OT or converged IT/OT environment, this advisory demands immediate attention.

Technical Analysis

Affected Products and Versions

AttributeDetail
VendorInductive Automation (US-headquartered)
ProductIgnition (Gateway / platform)
Affected versions8.1.53 and earlier
Fixed version8.1.54
CVECVE-2026-77393
Weakness classCWE-276 (Incorrect Default Permissions)
CVSS v38.8 (High) — network-adjacent authenticated attack with high confidentiality/integrity/availability impact
AdvisoryICSA-26-246-06

How the Vulnerability Works — Defender's View

Ignition Gateways use a role-based permission model for administrative and design operations. The "Create Project Role(s)" Gateway setting is intended to enumerate which user roles are permitted to create new projects. Prior to 8.1.54, the factory default value for this setting was empty. In Ignition's configuration semantics, an empty role list on this control does not mean "nobody" — it means "no restriction".

The exploitation chain from a defender's perspective:

  1. Prerequisite — authentication. The attacker needs any valid Gateway credential. This is a low bar: operator accounts, auditor accounts, or compromised credentials from credential-stuffing against the Gateway's web interface all qualify. Given how frequently we see shared or weak OT credentials in assessments, assume the prerequisite is easily met.
  2. Prerequisite — gateway script execution context. Per the advisory, the issue is reachable where the user "can execute gateway scripts." This typically means access to the Gateway's scripting interfaces (e.g., the Designer, Gateway web configuration scripting surfaces, or REST-adjacent internal APIs that invoke script execution).
  3. Privilege escalation via project creation. With project creation open to any authenticated user, the attacker creates a new project. Projects are the unit of deployment in Ignition — they carry gateway event scripts, tag providers, database and device connections, and Perspective/Vision resources.
  4. Code execution and persistence. A newly created project can contain gateway startup scripts and event scripts written in Jython (Python) that execute with the privileges of the Ignition service account. This converts "authenticated low-privilege user" into arbitrary code execution on the Gateway host — a gateway that often bridges IT and OT networks, holds device credentials, and communicates directly with PLCs and historians.
  5. Post-exploitation. From the Gateway host, an attacker has a launch point into the control network: HMI manipulation, tag poisoning, historian tampering, and lateral movement using credentials cached in Ignition's database and device connection configurations.

This is the exact pattern we've seen abused in real IR engagements: a "configuration oversight" that turns a low-value credential into full control of the OT demarcation point. An 8.8 CVSS score is entirely justified.

Exploitation Status

As of publication of ICSA-26-246-06, there is no confirmed in-the-wild exploitation reported by CISA, and the CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog at this time. However, the flaw is trivially reachable by any authenticated user, requires no special tooling, and Ignition is a known reconnaissance target for threat actors focused on industrial environments. Treat this as preemptively weaponizable — patch before someone writes the one-liner.

Detection & Response

The defensive observables here cluster in three places: (1) Gateway logs — project creation and script execution events are logged in Ignition's wrapper log; (2) host behavior — the Ignition Java service spawning unexpected child processes is a strong signal of gateway-script-based code execution; and (3) configuration state — the blank role setting itself is detectable and should be audited.

Sigma Rules

The highest-fidelity host-based signal for post-exploitation of this flaw is the Ignition Gateway's Java process spawning shell interpreters, scripting engines, or download utilities — behavior consistent with a malicious project's gateway event scripts executing OS commands via system.util.execute() or Jython's subprocess.

YAML
---
title: Ignition Gateway Java Process Spawning Shell or Script Interpreter
id: 8b3e1f47-2c6a-4d95-ae71-9f0c4b2d8e53
status: experimental
description: Detects the Ignition Gateway Java service spawning command interpreters, scripting engines, or download utilities — consistent with malicious gateway event scripts in an attacker-created project executing OS commands via CVE-2026-77393 (ICSA-26-246-06).
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-246-06
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/03
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\java.exe'
    ParentCommandLine|contains:
      - 'Ignition'
      - 'inductiveautomation'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\curl.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\wmic.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare legitimate Ignition modules that shell out for reporting or integration tasks; baseline per Gateway host and allowlist known module behavior
level: high
---
title: Ignition Gateway Service Spawning Shell on Linux
id: 4d7a92c1-6e58-4b3f-9c12-7a0e5d3b6f81
status: experimental
description: Detects the Ignition Gateway Java process on Linux spawning shells or download utilities — indicator of code execution through an attacker-created project exploiting the blank Create Project Role(s) default (CVE-2026-77393).
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-246-06
  - https://attack.mitre.org/techniques/T1059/004
author: Security Arsenal
date: 2026/09/03
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith: '/java'
    ParentCommandLine|contains:
      - 'ignition'
      - 'inductive'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate Ignition integrations invoking system utilities; audit and allowlist known paths per Gateway deployment
level: high

Tuning guidance: If your environment legitimately uses system.util.execute() in gateway scripts (some barcode, printing, and ERP-integration projects do), don't disable the rule — scope it by excluding known command lines and known projects, not by turning it off. A disabled rule on an OT gateway is worse than a noisy one.

KQL — Microsoft Sentinel Hunt

Ignition Gateways forward their wrapper logs via Syslog in most mature OT monitoring architectures, and Defender for Endpoint (if deployed on the Gateway host) surfaces process telemetry. This hunt looks for both signals: project creation events in Gateway logs by unexpected accounts, and the Java service spawning shells.

KQL — Microsoft Sentinel / Defender
// Hunt 1: Suspicious child processes spawned by Ignition Gateway Java service (Defender for Endpoint)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "java.exe"
   and (InitiatingProcessCommandLine has_any ("Ignition", "inductiveautomation")
        or InitiatingProcessFolderPath has_any ("Inductive Automation", "Ignition"))
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","curl.exe","certutil.exe","bitsadmin.exe","mshta.exe","rundll32.exe","wmic.exe")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, SHA256
| order by TimeGenerated desc;

// Hunt 2: Project creation / gateway script events in Ignition wrapper logs ingested via Syslog
Syslog
| where TimeGenerated > ago(7d)
| where Computer has "ignition" or ProcessName has "ignition" or SyslogMessage has "Ignition"
| where SyslogMessage has_any ("project created","Creating project","createProject","Project created by","gateway script")
| project TimeGenerated, Computer, HostIP, SyslogMessage
| order by TimeGenerated desc;

// Hunt 3: Gateway web interface hits to project/config endpoints from non-admin hosts (via CEF/web proxy ingestion)
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has_any ("/data/projects","/main/web/config","/system/gwcmd") or RequestContext has "ignition"
| where RequestMethod in ("POST","PUT")
| summarize RequestCount = count(), DistinctSources = dcount(SourceIP) by SourceIP, DestinationHostName, RequestURL, bin(TimeGenerated, 1h)
| where RequestCount > 20
| order by RequestCount desc;

Analyst note on Hunt 2: The critical follow-up question for any project-creation event is which account did it. In a hardened environment, project creation should trace to a short allowlist of engineering/admin roles. Any event attributed to operator, viewer, or service accounts is an immediate escalation.

Velociraptor VQL — Gateway Host Forensics

This hunt artifact checks whether a suspected Ignition Gateway is running a vulnerable version (by locating the installation and reading version metadata) and enumerates child processes spawned by the Gateway's Java process — useful for both exposure scoping and compromise assessment on the same pass.

VQL — Velociraptor
-- Ignition Gateway exposure + compromise assessment for CVE-2026-77393
-- 1) Identify running Ignition Java service and its child processes
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)ignition|inductiveautomation'
   OR Ppid IN (SELECT Pid FROM pslist() WHERE CommandLine =~ '(?i)ignition')

-- 2) Locate Ignition installation version file (Windows + Linux paths)
SELECT FullPath, Size, Mtime, read_file(filename=FullPath, length=4096) AS VersionInfo
FROM glob(globs=[
  'C:/Program Files/Inductive Automation/Ignition/**/*.txt',
  'C:/Program Files/Inductive Automation/Ignition/version*',
  '/usr/local/bin/ignition/**/version*',
  '/opt/ignition/**/version*',
  '/usr/local/ignition/**/version*'
])

-- 3) Recent project artifacts — attacker-created projects land in the Gateway's projects directory
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs=[
  'C:/Program Files/Inductive Automation/Ignition/data/projects/**',
  '/usr/local/bin/ignition/data/projects/**',
  '/opt/ignition/data/projects/**'
])
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

Field note: Part 3 is where this hunt pays for itself. In a stable OT environment, new project directories are rare and always tied to a change ticket. A project directory created or modified in the last 7 days with no corresponding change record is a red flag that deserves a full memory acquisition of the Gateway host.

Remediation & Verification Script

Run this on Windows-hosted Ignition Gateways to verify the installed version, confirm the Gateway service state, and sweep the wrapper log for project-creation events attributed to unexpected accounts. (For Linux Gateways, the same logic applies against /usr/local/bin/ignition/data/log/wrapper.log with grep.)

PowerShell
# CVE-2026-77393 — Ignition Gateway exposure & indicator check (Windows)
# Run elevated on the Ignition Gateway host.

$installRoot = "C:\Program Files\Inductive Automation\Ignition"

# 1) Confirm installation presence
if (-not (Test-Path $installRoot)) {
    Write-Host "[-] Ignition installation not found at $installRoot — check alternate path." -ForegroundColor Yellow
    exit 0
}

# 2) Report installed version (vulnerable: <= 8.1.53; fixed: 8.1.54+)
$versionFiles = Get-ChildItem -Path $installRoot -Recurse -Filter "*version*" -ErrorAction SilentlyContinue
foreach ($vf in $versionFiles) {
    Write-Host "[i] $($vf.FullName):" -ForegroundColor Cyan
    Get-Content $vf.FullName -TotalCount 10
}

# 3) Check Gateway service status
Get-Service -Name "Ignition" -ErrorAction SilentlyContinue |
    Select-Object Name, Status, StartType | Format-Table -AutoSize

# 4) Sweep wrapper log for project creation and script execution events (last 30 days of rotated logs)
$logDir = Join-Path $installRoot "data\log"
$cutoff = (Get-Date).AddDays(-30)
Get-ChildItem -Path $logDir -Filter "wrapper*.log" -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -ge $cutoff } |
  ForEach-Object {
    $hits = Select-String -Path $_.FullName -Pattern "project created|Creating project|createProject" -AllMatches
    foreach ($h in $hits) {
        Write-Host "[!] $($h.Filename):$($h.LineNumber): $($h.Line)" -ForegroundColor Red
    }
  }

# 5) List recently created/modified project directories — reconcile against change tickets
$projectsDir = Join-Path $installRoot "data\projects"
if (Test-Path $projectsDir) {
    Get-ChildItem -Path $projectsDir -Directory -ErrorAction SilentlyContinue |
      Where-Object { $_.CreationTime -ge $cutoff -or $_.LastWriteTime -ge $cutoff } |
      Select-Object Name, CreationTime, LastWriteTime | Format-Table -AutoSize
}

Write-Host "[i] Next step: In Gateway Web UI > Config > Gateway Settings, confirm 'Create Project Role(s)' is explicitly set (NOT blank) and restricted to engineering/admin roles only." -ForegroundColor Green

Remediation

1. Patch — this is the fix. Upgrade all Ignition Gateways to 8.1.54 or later, which restricts project creation permissions by default. Coordinate with operations for maintenance windows — but do not let "OT change control" become an excuse for indefinite deferral on an 8.8 CVSS authenticated-to-RCE path. Vendor advisory and downloads: Inductive Automation's release notes for 8.1.54, and the CISA advisory at ICSA-26-246-06.

2. Configuration hardening (do this today, even before patching). In the Gateway web interface, navigate to Config > Gateway Settings and explicitly populate "Create Project Role(s)" with only your authorized engineering/administrator roles. A blank value is the vulnerability. While you're there, audit every Gateway setting that accepts role lists for blank defaults — this class of error rarely exists in isolation.

3. Restrict gateway script execution. The advisory explicitly conditions exploitation on the ability to "execute gateway scripts." Audit which roles have Designer access and scripting capabilities, and strip those rights from operator and read-only accounts. Enforce this in your Ignition identity provider integration (AD/IdP), not just locally.

4. Inventory and identity hygiene. Enumerate every account that can authenticate to every Ignition Gateway. Disable stale accounts, rotate shared credentials, and enforce MFA at the network boundary in front of the Gateway web interface. The exploitation prerequisite is any valid credential — shrink that pool.

5. Network segmentation. Gateways should not be reachable from general user VLANs. Restrict access to Gateway web ports (default 8088/8043) to engineering workstations and jump hosts via firewall policy. This converts a network-reachable authenticated attack into one requiring prior foothold on a controlled segment.

6. Validate and monitor. After patching and hardening, run the verification script above, confirm the role setting is populated, and forward wrapper logs to your SIEM with alerting on project-creation events by non-engineering accounts. Add the two Sigma rules to your Gateway host detection coverage.

7. Backup before you touch anything. Take a Gateway backup (gateway backup via the Gateway Control Utility or the web UI) before upgrading. In OT, rollback capability is non-negotiable.

CISA's standard ICS guidance applies: minimize network exposure for all control system devices, locate control system networks behind firewalls isolated from business networks, and use secure remote access methods (updated VPNs with MFA) where remote access is required. Until 8.1.54 is deployed and the role setting is verified non-blank on every Gateway, treat every authenticated session on those Gateways as potentially privileged.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.