Why a Blank Default Permission Is Harder to Catch Than Malware
Earlier this month, CISA published an advisory for one of the most widely deployed industrial automation platforms in the world — Inductive Automation’s Ignition, which runs SCADA, HMI, and MES workloads across manufacturing, utilities, oil and gas, and water. The finding carried a high severity score of 8.8 and a CVE. But if you go looking for the exploit, you won’t find one. There is no memory corruption, no novel injection technique, no clever bypass of an access-control algorithm.
The vulnerability is a configuration field that shipped empty.
What did CISA flag?
The finding is CVE-2026-77393, classified as CWE-276, “Incorrect Default Permissions.” In Ignition versions up to 8.1.53, the Gateway’s “Create Project Role(s)” setting shipped blank. The Gateway’s access control did exactly what it was told to do — it enforced the setting, and the setting specified no role. The result: any authenticated user could create a new project.
Inductive Automation’s own assessment is worth reading closely, because it names the cause precisely: the issue is “a default-value configuration, not a flaw in the access control itself.” Populate the field and the vulnerability closes. Upgrade to 8.1.54 (or 8.3), and project creation is restricted to Designer sessions and no longer depends on that setting at all.
But in Ignition, a project is not a document. It is executable application logic — screens, tags, scripts, and database connections that the Gateway serves to operator stations. A project created by the wrong hands can read process tags, write to the historian, and change what an operator sees on their HMI. That is the shape of the risk: not a stolen file, but a legitimate-looking application planted inside the environment that runs the plant.
Why is a default configuration harder to defend than an exploit?
An exploit announces itself. It has a technique, a payload, a pattern that vendors, researchers, and detection tools can dissect and encode. Once the community understands it, it gets a signature, a YARA rule, a detection logic block, a patch. The attack becomes knowable, and knowable attacks become blockable.
A blank default does none of those things. There is no malicious artifact to match, because nothing malicious has been written. The “attack” — if one happens — is an authenticated user doing something the system formally permitted. The platform is operating precisely as configured. To a signature-based detector, there is nothing to see, because the behavior is indistinguishable from legitimate operation at the artifact level.
This is the quiet, structural problem underneath much of OT security. The most damaging industrial incidents don’t begin with a novel zero-day; they begin with a legitimate credential, a legitimate tool, and a configuration that never got reviewed. The vulnerability is the absence of a restriction, and absence is the one thing a signature can’t match.
Why can’t signatures catch a blank default?
Signatures only catch what has been seen before. They are a catalog of known-bad, and they are excellent at it — but a default configuration is not known-bad. It is known-nothing. There is no malware hash, no command-and-control domain, no exploit payload to write a rule for. If someone uses the blank setting to create a project, the individual actions — an authenticated login, a project-create request, a normal Gateway operation — are each legitimate on their own.
It gets worse in OT. When a vulnerability is a configuration, the fix is a setting, not a patch. That means the exposure window isn’t closed by a patch cycle a security team can track in a CVE dashboard; it stays open in every deployment where an administrator never noticed the blank field. The gap between “a fix exists” and “the fix is applied everywhere” is where operational risk actually lives.
What does “any authenticated user” mean in a real plant?
The phrase is easy to skim past, but it deserves to sit in the foreground, because it describes the way industrial environments actually operate. Plants run on shared operator accounts, vendor support credentials that outlive the support contract, integrator logins from the last commissioning job, and service accounts with more privilege than anyone remembers granting. “Authenticated user” does not mean “trusted user” — it means someone who found their way to a valid login, which is a far larger and looser population than any asset register would suggest.
That is the second lesson of this finding. The boundary that mattered was not the network perimeter or the authentication prompt; it was an internal, role-based restriction that was never turned on. When that restriction is blank, the distinction between “authorized” and “allowed” collapses — and in an industrial setting, that distinction is the whole game.
How do you detect the abuse of a blank default?
If signatures can’t see the flaw and the platform itself says the behavior is permitted, what’s left? The answer is the same thing that catches an insider and a compromised credential: the pattern of behavior around the action, rather than the content of the action.
In a healthy plant, projects are created rarely, by a small number of known engineers, during normal working hours, from known engineering workstations. A detection system that learns that normal can flag the deviation: a fourth account creating a project when three engineers are the norm, a project-created event at 02:00, a creation originating from a subnet or workstation that has never touched the Gateway’s project service before. None of these is “malicious” in isolation — but together, and measured against a passively learned baseline of what this particular plant does, they are exactly the signal that a blank default is being turned into a foothold.
There is an important distinction here about baselines. We freeze the baseline, not the detection — the attack is still fully caught. The baseline is the reference of normal; the detection stays live against it. Someone who tries to poison the reference by behaving slowly over weeks is still caught in the act, and the act is explainable: which asset, which account, which protocol, mapped to the right level of the Purdue model and to MITRE ATT&CK for ICS.
That is the deeper point. A blank default permission doesn’t need an exploit to become a breach — it needs a quiet, legitimate-looking step that nobody notices. The only defense that meets that threat on its own terms is passive, behavioral detection that watches how a trusted device behaves, not just whether its traffic matches something known to be bad.
The Ignition finding is not a story about a broken product. It’s a story about where risk actually lives in operational technology — in defaults, in permissions, in the long tail of configurations that never get revisited after commissioning. The question every operator should ask isn’t whether their platform has a blank field somewhere; it’s whether anything in their network would notice if that field got used.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.