Yaamlabs
Vulnerabilities

Ignition flaw turns a Vision login into Gateway code execution

CVE-2026-92817 lets a low-privileged Ignition user reach Designer-level access and run code on the Gateway. Fixed versions, interim steps and what to rotate.

By Yaali. October 16, 2026, 6 min read, Vulnerabilities, Patching.

Cover illustration of a server rack wired to rows of PLC modules with an open padlock floating beside it, with the Yaamlabs logo and the text: Low-privileged Ignition users can reach the Gateway, 8.1.55 and 8.3.9, the fixed Ignition versions

CISA published ICS advisory ICSA-26-286-01 on October 13 for Inductive Automation Ignition, the SCADA and HMI (supervisory control and human-machine interface) platform used across manufacturing and energy sites. The flaw, CVE-2026-92817, is an incorrect authorization bug (CWE-863) rated CVSS v3.1 8.8. The CVE record and CISA also give a CVSS v4 score of 8.7; Inductive Automation's Trust Center lists only the 8.8. Affected versions are Ignition 8.1.0 through 8.1.54 and 8.3.0 through 8.3.8.

An authenticated user who can open a Vision project can use their session to get Designer-level privileges, and from there run arbitrary code in the Ignition Gateway process. Inductive Automation says that could expose Gateway credentials and the databases and devices the Gateway connects to. CISA has no reports of public exploitation, and the CVE record marks exploitation as "none" and the attack as not automatable. The fix is Ignition 8.1.55 or 8.3.9. Any site where operators, contractors or shared screens log into Vision clients should treat this as a near-term upgrade.

How CVE-2026-92817 works: a user with access to a Vision project presents a valid Vision session identifier, the Perspective module does not check that session's privileges before granting Designer-level access, and Designer-level access allows code to run in the Gateway process, which holds database credentials and device connections

How it works

An Ignition installation centres on the Gateway, a server process that talks to PLCs (programmable logic controllers) and other devices, stores tag history in SQL databases and serves the screens people use. Operators use those screens through Vision clients, a desktop application, or through Perspective, the browser-based module. Engineers build the projects in the Designer, which is effectively an administrative tool: Designer users can edit projects and write scripts that the Gateway runs.

Because Designer access is so powerful, the Gateway gates it separately. On 8.1, Config > Security > General holds a "Designer Role(s)" setting under the Classic login strategy and "Designer Permissions" under the Identity Provider strategy. A normal operator account can log into a Vision client but should never pass that Designer check.

According to the advisory and the CVE record, the Perspective module does not properly validate session privileges when it decides whether a session has Designer-level access. A user with access to a Vision project can supply a valid Vision session identifier and be treated as having Designer-level privileges. The session is real and properly authenticated, but its privileges are never compared with what Designer access requires. With Designer-level access, the attacker can execute arbitrary code in the context of the Gateway process.

The prerequisite is the important part for OT (operational technology) teams. "Authenticated low-privileged user" covers shift operators, maintenance contractors, a shared kiosk account on the plant floor and read-only dashboard logins. Any of those accounts, or anyone who steals one, is enough to start the attack, and on many sites those credentials are the least protected in the system.

Once code runs in the Gateway, the attacker has what the Gateway has. That usually means the credentials for its database connections, its live device connections to PLCs and controllers, and anything else stored in the Gateway configuration. CISA lists the affected sectors as critical manufacturing, energy and information technology, with worldwide deployment.

What attackers are doing

Nothing has been reported. CISA says it has received no reports of known public exploitation targeting this vulnerability, and the CISA assessment in the CVE record rates exploitation as "none" and technical impact as "total". Tim Hemingway reported the issue to Inductive Automation. We found no public proof-of-concept code.

Two dates in the sources do not match. CISA's revision history lists an initial publication date of September 13, 2026, while the advisory and the CVE record both say October 13. CISA and the CVE record also list Ignition 8.3.9 as released in August 2025, which is before the CVE was reserved on September 16, 2026. Treat the version numbers as the reliable part and confirm build dates with Inductive Automation if they matter for your change records.

What to do

Fixed Ignition versions for the 8.1 and 8.3 lines, followed by five steps: upgrade, limit Gateway exposure, review roles and Vision access, check Designer sessions and audit logs, and rotate what the Gateway stores

1. Find every Gateway and upgrade it

List every Ignition Gateway you run, including test, edge and redundant backup Gateways, and record the version shown in each Gateway's web interface. Anything on 8.1.0 to 8.1.54 goes to 8.1.55 or newer, and anything on 8.3.0 to 8.3.8 goes to 8.3.9 or newer. The same Trust Center advisory lists a second issue fixed by these versions, CVE-2026-63252, a memory exhaustion denial of service rated CVSS 7.5. Test the upgrade and plan the outage with the plant's process owners, as you would for any change to a running control system.

2. Reduce exposure until you can upgrade

CISA and Inductive Automation both say interim measures reduce risk but do not fix the flaw. Limit Gateway access to trusted users and hosts, keep the Gateway off the internet and behind firewalls, and separate control networks from business networks. The Gateway's web server listens on HTTP port 8088 and HTTPS port 8043 by default, set as gateway.port and gateway.sslport in gateway.xml; Designers, Vision clients and Perspective sessions all use them. Check your own configuration, since many sites change these, then allow them only from the engineering and operator subnets that need them. Remote users should come in through a current VPN, not a published port.

3. Review who can reach a Vision project

The attack needs an account with Vision project access, so shrink that group. Remove stale contractor and vendor accounts, replace shared kiosk logins with named accounts where you can, and check that the Designer setting in Config > Security > General lists only engineering roles. Look at the other settings on that page too: "Gateway Config Permissions" and "Status Page Permissions" mean public access when left empty. On 8.3 the Gateway web interface changed, so find the equivalent general security settings page in your build.

4. Check whether anyone already used it

  • Status > Connections > Designers lists running Designer sessions. Any session tied to an operator, contractor or kiosk account needs explaining. The Perspective Sessions and Vision Clients pages on the same menu show who else is connected.
  • If a Gateway Audit Profile is selected in Config > Security > General, view it under Config > Security > Auditing, then More > view log, or query the audit_events table. Look for logins and project changes by accounts outside engineering, and compare them with your change records.
  • Status > Diagnostics > Running Scripts lists every Gateway script running now, with a way to stop one. A script nobody on the engineering team recognises is a strong sign. Keep the Diagnostics > Logs output from the same period before it rolls over.

If no audit profile is configured, set one up now. Without it the Gateway keeps no record of who logged in or what changed.

5. Rotate what the Gateway stores

If you find unexplained Designer activity, or you cannot rule it out on an exposed Gateway, assume the Gateway's secrets are known. Change the passwords for its database connections, the credentials on device and OPC connections where they use them, and the accounts in its user sources. Then review projects and Gateway scripts for anything added, before you trust the system again.

Watch the low-privilege accounts

OT security reviews tend to focus on the engineering workstation and the Designer, because that is where the power sits. This bug starts from the opposite end, an operator login. Named accounts, removing contractors when the job ends and an audit profile switched on cost little and make a flaw like this much harder to use quietly.

Our network penetration testing team tests how far an operator-level account can get on a control network, and safeguarding and hardening covers Gateway exposure, role design and audit logging. Open the chat and Yaali, our AI agent, will pass your question to an engineer.


Sources: CISA ICS advisory ICSA-26-286-01, CVE-2026-92817 record, Inductive Automation Trust Center, Security Boulevard, Daily OT security news, October 15, 2026, CISA bulletin, October 13, 2026, Ignition gateway.xml reference, Ignition Gateway General Security Settings, Ignition Gateway Status, Ignition auditing action reference.

Read next

Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.