The Block Password That Isn't a Password: When OT Security Controls Fail Silently
An engineer sets a password on a block of PLC logic. That password is the protection — the thing the plant points to when asked how the controller’s program is kept safe. Enter the right password and the logic can be changed; enter the wrong one and it can’t. The entire engineering workflow rests on that assumption.
On September 17, 2026, CISA published an advisory that quietly undid it. In Mitsubishi Electric’s GX Works3 engineering software — the tool used to author control programs for Mitsubishi’s MELSEC controllers — a flaw in the authentication algorithm means a local attacker can authenticate with an invalid block password. The password is still being asked for. It just isn’t being checked the way everyone believes it is.
The same day, a second advisory described the other end of the same problem. A crafted FTP command sent to a Schneider Electric Modicon M340 controller or its communication modules causes a denial of service. The controller’s own file-transfer service — a legitimate feature used to move firmware and configuration — becomes the lever that takes the device offline.
Neither of these will make an evening news headline. Both are exactly the kind of finding that quietly erodes a plant’s security model.
The two ends of the engineering toolchain
The two flaws sit at opposite ends of one workflow.
The Mitsubishi issue (CVE-2026-15688, rated 8.8 High under the vendor’s CVSS v3.1 scoring) lives on the engineering workstation — the machine where control logic is written, compiled, and downloaded. A local attacker who can run code there can modify part of the tool’s executable in memory, bypass the block-password check, and then view, tamper with, destroy, or delete the control programs the password was meant to protect. The attack requires the workstation to be compromised first — a realistic consequence of a phishing message or a removable-media drop, and precisely the scenario the block password was supposed to contain.
The Schneider Electric issue (CVE-2025-6625, rated 7.5 High) lives on the controller itself and is reachable over the network. It needs no prior compromise — only the ability to reach the device’s FTP service, which is present across the affected Ethernet, serial RTU, and Modbus/TCP modules. A specifically crafted command is enough to make the device unavailable.
One is local, the other networked. One is an authentication control that failed; the other is a service that was never meant to be reached by anyone hostile. Together they bracket the full path a change takes from an engineer’s desk to a running process — and they show how thin the built-in protections are at every step.
Why signatures can’t see this
The reason these two flaws matter more than their CVSS scores suggest is that neither leaves a signature-shaped trace.
Signature-based detection matches what has already been seen. It can catch a known exploit string or a known command pattern. But there is no signature for “a password that was accepted when it shouldn’t have been.” The bypass happens inside the engineering tool’s memory, on the workstation — no packet crosses the wire announcing that authentication failed and the tool let it through anyway. And the FTP command that crashes the controller is a single malformed message that, at a glance, looks like every other FTP message the device has ever handled.
This is the familiar limit, but it bites harder here because the failure is in the controls, not the traffic. Signatures can only describe what’s on the network. What failed — an authentication check, a service’s input handling — is invisible to them. Signatures catch what’s been seen before; the more damaging attack is the one that leans on a control that never works quite the way the plant believes it does.
What behavioral detection sees instead
Behavioral detection inverts the question. Instead of asking “does this traffic match a known attack?”, it asks “does this activity match what this network normally does?”
Consider what actually changes in each scenario.
When a tampered control program is downloaded, the download itself is observable. A new project write arrives at the PLC — from a workstation, on a schedule, or with content that differs from the last known-good version. The device then begins to behave differently: the process values it drives drift from their learned normal. None of this requires knowing the password was bypassed. It only requires knowing what “normal” looks like for this specific controller.
When a controller is hit with a crafted FTP command, the service’s behavior changes — the connection pattern, the response, and the device’s subsequent state all deviate from the baseline built up over weeks of ordinary operation. A learned baseline includes normal FTP usage, so this is not a blank check; it is a reference against which the deviation stands out.
In both cases we freeze the baseline, not the detection — the attack is still fully caught. What changes is only the thing it’s measured against.
Why patching alone can’t close this
None of this means the advisories should be ignored. They should be actioned. The Modicon fix ships in firmware version 3.60 for the affected modules, and applying it requires a reboot — which, on a live process, is a scheduling problem all by itself. Access to engineering workstations and to controller network services should be restricted. FTP does not need to be reachable from the business network, or at all outside maintenance windows. The engineering network should be segmented from the process network.
But these fixes close today’s specific holes. Tomorrow’s advisory will open another. Hardening is necessary and never sufficient on its own. The durable control is the one that doesn’t need to know which vulnerability is current: continuous observation of what the network and the process are actually doing, so the first time a tampered program is downloaded — or a controller stops behaving like itself — someone sees it, rather than weeks later when the process misbehaves.
What did the two advisories actually say?
CISA’s advisory for Mitsubishi Electric GX Works3 and Motion Control Settings (CVE-2026-15688, CWE-303, Incorrect Implementation of Authentication Algorithm) describes a local attacker authenticating with an invalid block password by executing the product and modifying part of the executable module in memory. The consequence is the ability to view, tamper with, destroy, or delete control programs. The separate advisory for Schneider Electric Modicon M340 controllers and communication modules (CVE-2025-6625, CWE-20, Improper Input Validation) describes a denial of service triggered by a specifically crafted FTP command, affecting Ethernet, serial RTU, and Modbus/TCP modules.
How is “broken authentication” different from “missing authentication”?
Missing authentication is a door with no lock at all — the flaw is obvious the moment anyone looks. Broken authentication is worse in one specific way: the lock is there, the plant trusts it, and it silently fails to do its job. The Mitsubishi block password is the second kind. It gives false confidence, which is why it can persist for years without anyone re-examining it.
What does an attacker need to use the block-password bypass?
Local code execution on the engineering workstation. That is a higher bar than a remote exploit, but it is a realistic one — a compromised workstation is among the most common entry points into an OT environment, and the workstation is exactly where a block-password bypass has maximum effect, because it sits between the engineer and the controller. Once the control program is reachable, the bypass converts a workstation compromise into full read, tamper, and destruction of the logic the plant runs on.
What should an OT team do when an advisory like this lands?
Triage it against reality, not just severity: is the affected device reachable from anywhere hostile? Is the engineering software in use, and on which workstations? Then act on a schedule the process can tolerate — apply the fix in a maintenance window, restrict or remove the reachable service, segment the engineering network. And treat the advisory as evidence that the built-in controls are not a complete answer: the compensating control is observation that doesn’t depend on any of them working.
Doesn’t a behavioral baseline need the FTP traffic to be normal first?
Yes — and that is the point. A baseline is learned from the network as it actually operates, including its ordinary FTP usage during maintenance. What the detection flags is not “FTP happened” but “FTP happened in a way this device has never shown before” — a deviation in pattern, timing, or consequence. The baseline is not a rule that forbids a protocol; it is a model of this network’s normal, and the crafted command is a departure from it.
This is the problem Maigadi was built to address.
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.
When a security control fails silently, the signal isn’t in the failed control — it’s in the behavior around it. A passively learned baseline is built to surface exactly that: the download that shouldn’t have been possible, the controller that stopped behaving like itself, the deviation that no password check would ever catch.
Maigadi Networks provides passive, signature-less network detection and response for OT/ICS environments. We help operators see when a trusted device starts doing something it has never done before — before that behavior becomes an incident.