The Ignition Gateway Field That Shipped Blank

On 3 September 2026 CISA published ICSA-26-246-06 against Inductive Automation Ignition: one CVE, CVE-2026-77393, a CVSS v3.1 base score of 8.8, and a weakness class of CWE-276, Incorrect Default Permissions. Everything at or below Ignition 8.1.53 is affected. The advisory's summary line says successful exploitation could allow any authenticated user to create projects.

The mechanism is a blank text box. Under the Classic authentication strategy, the Gateway's general security settings page carries a field called Create Project Role(s). You type role names into it, comma-separated, and a user needs at least one of those roles to create a new Designer project. It shipped empty. An empty requirement is satisfied by everyone who logs in.

No memory corruption, no deserialization gadget, no authentication bypass. A field with nothing in it, behaving the way a field with nothing in it behaves.

That's why this advisory is worth an hour of a controls engineer's afternoon even at a site with a disciplined patch calendar. A defect in code gets closed by a version number, and your vulnerability management process already knows how to handle version numbers. A defect in a shipped default doesn't work that way. It closes by someone opening a configuration page and typing, and it recurs on every gateway anybody stood up from the same installer. Patching 8.1.53 to 8.1.54 closes exactly one of the conditions this advisory should have you looking for.

What a new project drags onto the gateway

Projects in Ignition carry windows, views, named queries, tags, and scripts. Scripts are the part that matters here. A project's gateway event scripts execute inside the gateway's own JVM: startup and shutdown handlers, timer scripts on whatever interval you set, tag change scripts bound to any tag the gateway can see, message handlers callable from other scopes. That's Jython running server-side with system.tag and system.opc in scope and the gateway's OPC connections already established. Nothing about that is exotic; it's how half the useful logic at a process site gets written, from a nightly report job to the script that stamps a batch ID onto a CIP record.

A gateway, then, is a programmable node with a write path into the control network, and only incidentally a dashboard server. On a dairy site it's talking to the PLC that sequences the CIP skid; at a waste-to-energy plant it reads grate drive speed and ID fan current and, on most installs, writes setpoints back. A caster bay puts it in the data path of the mould-level loop. Put a new project on that machine and you've created somewhere for code to live that inherits all of it.

That's what the tail of the vector means. CISA scored CVE-2026-77393 at 8.8 under CVSS v3.1 with C:H/I:H/A:H, and 8.7 under v4.0, high on all three impact metrics in both. Confidentiality, integrity, and availability all high, because once you can place a gateway-scoped script you can read tags, write tags, and stop the thing from serving.

One term in that vector deserves attention from anyone sizing their own exposure: PR:L. Privileges required, low. Not none. An attacker needs an account that the gateway's System User Source will accept. At a lot of plants that's the cheap half of the problem.

The vendor's framing points at the right drawer

Inductive Automation told CISA this is a default-value configuration issue rather than a defect in the access control itself. The advisory records the reasoning: the control enforces exactly what the Create Project Role(s) setting specifies, and because the setting shipped blank, no role was required. Populating it, per the same advisory, fully closes the vulnerability.

A vendor saying "working as configured" about an 8.8 normally reads as deflection. Take this one at face value, though, because it tells you which drawer to open: nothing here would have been caught by a code review, a SAST run, or a dependency scan, because the access control did its job against an empty specification. There was nothing in the binary to find. So the work this advisory asks of you is a settings review, and settings reviews are the kind of task that gets deferred indefinitely because they produce no artifact anyone can point at afterward.

Which brings up the second thing the framing implies. If a shipped default can create a CVSS 8.8 condition on this page, the rest of the page is worth reading with the same suspicion.

Seven fields, and the order to read them

Work through it the way you'd commission the gateway, starting with what constrains everything downstream.

1. The version, from the Gateway web interface. You need the full build, not "8.1". The 8.3 series isn't affected. Releases from 8.1.54 onward restrict project creation to Designer sessions and no longer consult the setting at all. Anything at 8.1.53 or below is in scope, including the long-lived installs still running whichever 8.1 build the integrator left behind when the line was commissioned. You'll find the build on the gateway's web interface, which also hosts the settings page everything below refers to, on port 8088 for HTTP or 8043 for HTTPS unless somebody moved them.
2. The Designer Authentication Strategy, set to Classic or to Identity Provider. That choice decides which half of the security page is even live, and plenty of engineers have never looked at it because the Designer login has worked for years. Classic authenticates against the System User Source with a username and password in the Designer's own login form. Identity Provider bounces the user to a browser and an IdP.
3. Designer Role(s) and Create Project Role(s), if you're on Classic. These are the two fields the CVE lives between. Create Project Role(s) is the one named in the advisory; the vendor's suggested interim fix is to set it to match whatever your Designer Role already is, so that only users who can open the Designer can create a project in it.
4. Designer Permissions and Create Project Permissions, if you're on Identity Provider. Same two gates, expressed as security level paths rather than role names.
5. Gateway Config, Status Page, and Home Page Permissions. These three apply regardless of which authentication strategy you picked, which makes them the fields most likely to be stale.
6. The System User Source roster. Everyone in it is an authenticated user as far as PR:L is concerned.
7. The Gateway Audit Profile, a dropdown. If nothing is selected, gateway-scoped actions have nowhere to log.

Six of those seven take a few minutes each. The roster takes longer and is the one that tells you something about your plant rather than about Ignition.

The caution the documentation prints five times

Read Inductive Automation's own page for those settings and a pattern shows up. Five of the seven fields carry an explicit warning about what happens when you leave them blank. Two don't.

The warning on those five reads, in the vendor's words:

Empty value in this field means "Public" security level: Access will be unrestricted.

So the semantics were documented. Blank is permit-all, stated outright, five times on one page. What the documentation didn't spell out was the same behaviour on the two Classic role fields, and one of those two happened to ship blank. The advisory is the overlap of those two facts.

Now follow that forward. Upgrading to 8.1.54 removes the dependence on one field out of seven. The three that apply under either strategy are untouched by the upgrade, and all three are documented as unrestricted when empty, with the Gateway Config section being the one that lets a visitor reconfigure the gateway. A normal install doesn't leave those blank. If you find one blank, a person cleared it, and the useful question is which commissioning week that happened in and what else got cleared alongside it.

I'd put the same suspicion on the Designer Role(s) field. Nothing in the advisory touches it, and 8.1.54 doesn't change it. But if it's empty on a Classic gateway, every account in the System User Source can open the Designer, and the interim mitigation the vendor recommends for Create Project Role(s) (match it to the Designer Role) resolves to nothing at all.

Who counts as authenticated on a plant gateway

So who, on your site, satisfies PR:L? Go through the System User Source roster line by line and the answer is usually wider than the org chart suggests.

Shared operator logins at the HMI terminals, because three shifts and a relief operator wouldn't each remember a password. Contractor accounts from the packaging line install, still enabled two years later. A commissioning account belonging to the integrator, created with an Administrator role for one week of work. Service accounts for the reporting stack, the historian bridge, and the OEE display in the canteen corridor. An AD group mapped in wholesale when Perspective dashboards went out to the office network, which is how a scheduler in logistics ends up authenticated against a gateway that writes to a boiler.

Each of those is an authenticated user. On an 8.1.53 gateway with the field blank, each of them could create a project. Not one of them appears on a network diagram, and the only place the full list exists is the user source itself.

This is also where monitoring and analytics couplings get sloppy, including ours. When we connect an analytics layer to a plant gateway, it gets a dedicated user in the System User Source with a read-only role, no Designer Role, and no project-creation role. The temptation during a two-day integration is to reuse the engineering account because it already works, and that temptation is why access-control findings keep landing on systems whose owners believe nobody holds credentials they shouldn't.

Cleaning the roster is the part of this job with lasting value. The CVE gets patched once. The roster rots continuously, and it's the input to every access-control requirement in IEC 62443 you'll ever be audited against.

Populating the field versus taking the restart

Here the operational asymmetry matters more than the security one, and it's where a plant's answer diverges from an IT department's.

Typing a role name into Create Project Role(s) is a configuration change on a running gateway. No installer, no module reload, no new binaries. Upgrading 8.1.53 to 8.1.54 is a different animal: the gateway service stops and starts, Vision clients and Perspective sessions drop, OPC connections tear down and re-establish, and anything the gateway was logging to history carries a gap across the restart. On a site where the historian feeds a regulatory report, that gap needs a note against it. On a packaging line you take that during a changeover. On a continuous caster, a UHT line, or a waste-to-energy boiler running its own availability contract, a gateway restart is a planned-outage conversation with the production manager, and the next slot might be six weeks out.

Since the vendor states that populating the field fully closes the vulnerability, the sequence for a continuous process is straightforward. Set the field now under normal change control. Schedule 8.1.54 for the window you already have booked, and treat the version as hygiene rather than as the remediation.

Two details that catch people on that path. Redundant gateway pairs need the change on both nodes and the upgrade on both, and the backup inherits project configuration from the master, so a project created on one doesn't stay on one. And verify the field took effect by testing it, not by reading it: log in as a non-Designer account and try to create a project. A settings page that displays the right value and a gateway that enforces it are two separate claims, and only one of them is cheap to check.

No change-control form says "a project appeared"

Most plants run tight change control over PLC program downloads. Signed MOC, backup of the running program, a second engineer, a printed record of the version that went in. SCADA gets thinner coverage, usually limited to modifications of the project that's already live: a new view, a retagged alarm, a changed scale factor.

Project creation sits outside that frame entirely. The MOC form has no row for it, and nothing in the daily operations report counts projects. On a gateway with no audit profile selected, there's no queryable record that a project appeared at all, which is the practical reason step 7 in the check order belongs in the list despite having nothing to do with CVE-2026-77393. An unexploited vulnerability and an unobserved one look identical from the control room.

An audit profile costs a database table and a dropdown selection, and it turns gateway-scoped actions into rows you can query by timestamp. Point it at a dedicated schema rather than the same database your tag history lives in, because the retention you want for an audit trail and the retention you want for a 1-second tag are not the same number. Then add project creation to whatever your site treats as a reviewable change, alongside the program downloads it already covers.

CISA's recommended practices for this advisory are the standard set: keep control system devices off the internet, put control networks behind firewalls and separate them from business networks, and use a VPN for remote access while remembering a VPN is only as secure as the device on the other end. That guidance reads as generic because it is, but it's load-bearing for this particular CVE. The vector is AV:N. Network reach to the gateway's web ports is the difference between a finding that needs an account and a finding that needs an account plus a route, and at most plants it's the published Perspective dashboards that quietly provide the route.

CISA adds that it has received no reports of this CVE being exploited in the wild. That's useful for prioritisation and worthless as reassurance about what a credentialed insider can do with an afternoon.

Where this review stops being worth the hour

Single-gateway sites get very little out of this: one Administrator account, a flat control VLAN, no path in from the business network. AV:N needs a network route and PR:L needs an account, and a site with four accounts and no route has neither. The settings review comes back clean. The upgrade was due anyway, and the hour buys a tick in a column rather than a reduction in risk. Sites on the 8.3 series sit outside the advisory altogether and have a different field model on that page, so the table above won't match what they see.

The method also doesn't survive scale. Clicking through seven fields on one gateway is a sensible afternoon; doing it across thirty gateways at eleven sites is not a procedure, it's a backlog that never clears. At that point you want the configuration pulled and diffed against a baseline, with drift raised as an alarm instead of discovered by the next advisory. That's a project of its own. What an afternoon realistically covers is one gateway, read carefully, with the roster written down somewhere it can be checked again.

Notes

The field names and empty-value behaviour above describe the Classic and Identity Provider strategies as documented for the Ignition 8.1 series; the 8.3 series isn't covered by the advisory and presents these settings differently, so don't read the table against an 8.3 gateway. Whether the interim mitigation is sufficient for your site depends on what your Designer Role contains, so check that field before copying it into Create Project Role(s).

• CISA ICSA-26-246-06, Inductive Automation Ignition, 3 September 2026
• Gateway General Security Settings, Inductive Automation Ignition 8.1 documentation