CISA published the advisory on September 17, while Mitsubishi Electric’s accompanying PSIRT bulletin identifies the weakness as CWE-303, an incorrect implementation of an authentication algorithm. Mitsubishi assigns a CVSS v4 base score of 9.2, but its own vector also makes the boundary clear: this is a local attack requiring low privileges, not a disclosed network-authentication bypass against a PLC or motion controller.
For Windows administrators supporting factory automation engineering stations, the important operational conclusion is straightforward: a Block Password should no longer be treated as a sufficient control on projects left at the older security setting. The vendor’s prescribed mitigation has two required components—software version and project setting—and either one missing leaves the deployment outside Mitsubishi’s documented workaround.
The bypass occurs on the engineering workstation
GX Works3 is Mitsubishi’s Windows engineering environment for MELSEC programmable controllers, while Motion Control Setting is the GX Works3-packaged component used to configure and monitor Motion modules. The advisory concerns the Block Password function in those tools, rather than a vulnerability Mitsubishi has described as residing in controller firmware.
That distinction limits and sharpens the threat model. The published attack requires someone to execute the affected application locally and modify an executable module in memory; Mitsubishi’s CVSS vector specifies local access and low privileges. An internet-exposed PLC is therefore not, on the disclosed facts, directly exploitable through this CVE alone.
But a local engineering workstation is often a high-value trust boundary in an operational technology environment. A person with access to it could be a malicious insider, a contractor using a shared workstation, or an attacker who has already obtained a standard Windows account through phishing, remote-access abuse, or another endpoint compromise. Once the Block Password check can be bypassed, the consequence is not simply access to a configuration screen: Mitsubishi says the attacker may be able to read, alter, destroy, or delete the control programs that define machine behavior.
The advisory does not claim that CVE-2026-15688 independently writes malicious logic to a connected controller, causes immediate physical process changes, or permits remote code execution. Those are important limits. Yet the ability to alter an engineering project can still create a pathway to unsafe or disruptive changes if a compromised project is later downloaded, merged, restored, or used as the baseline for maintenance work.
Version 1.096A is only half of Mitsubishi’s workaround
Mitsubishi directs GX Works3 customers to install version 1.096A or later and set every project’s security version to “2.” For Motion Control Setting, the stated minimum is version 1.070Y or later, plus the GX Works3 workaround. Motion Control Setting users should not read the separate version number as a standalone fix; Mitsubishi explicitly makes the GX Works3 update and project-security change part of that path.
The language Mitsubishi uses is also significant. It labels these steps “workarounds,” not a fixed-version remediation that declares the affected software no longer vulnerable. Its product table continues to list all GX Works3 and Motion Control Setting versions as affected. Organizations should therefore document the compensating configuration change rather than close the issue merely because the two installers have been updated.
The release thresholds themselves are not newly created for this September 2026 disclosure. Mitsubishi’s earlier 2022-015 advisory already directed GX Works3 users to version 1.096A or later and security version “2” for a different set of security issues, including CVE-2022-29830; Motion Control Setting version 1.070Y was likewise the threshold for that component. The new advisory shows that the protection model Mitsubishi introduced then remains material for the Block Password bypass disclosed this week.
That history does not mean CVE-2026-15688 is old news. It means sites that updated their software but never converted active projects to security version “2” may have assumed the version number alone represented the security boundary. Mitsubishi’s new bulletin makes clear that it does not.
Security version “2” can disrupt older workflows
Changing project security version is not a cosmetic switch. Mitsubishi’s GX Works3 documentation says a project set to security version “2” in GX Works3 1.096A or later is automatically stored using the compressed project format; administrators cannot select the older “Standard” file-size setting for that project.
That creates compatibility consequences that should be planned before mass conversion. Mitsubishi states that a compressed project cannot be opened in GX Works3 1.047Z or earlier. It also states that a project secured at version “2” cannot be verified against a project created in GX Works3 1.095Z or earlier.
For a plant with a central engineering laptop, a vendor-maintenance notebook, and archived recovery images, that can become a real availability issue. A security upgrade may prevent an older service system from opening, comparing, or validating the project it is expected to support. The security setting is still the documented workaround, but it needs a coordinated rollout rather than a technician-by-technician change.
Motion Control Setting adds another dependency. Mitsubishi’s current download page says version 1.070Y requires GX Works3 1.085P or later, and identifies 1.070Y as the release that added support for security version “2.” That makes the component relationship explicit: an administrator cannot enable the recommended Motion Control Setting protection on an older installation and expect equivalent behavior.
Before changing production projects, administrators should identify every workstation, virtual machine, backup image, and third-party maintenance process that needs to open or verify those files. The goal is to eliminate an insecure engineering path without discovering during an outage that the only available recovery laptop is too old to use the hardened project.
The practical response is workstation hardening and project conversion
Mitsubishi’s mitigation advice reflects the local-access nature of the issue: keep computers running the affected tools inside a LAN, block untrusted remote logins, use firewalls or VPNs for necessary remote access, avoid untrusted links and attachments, use endpoint protection, and restrict physical access. These are reasonable measures, but they are layers around the core weakness; they do not substitute for moving projects to security version “2.”
A response plan should prioritize the engineering stations that can modify active production projects, then cover dormant but operationally important backup environments. At minimum, teams should do the following:
- Inventory GX Works3 and Motion Control Setting installations, including offline laptops and virtual-machine images used for commissioning or recovery.
- Update GX Works3 to version 1.096A or later, and update Motion Control Setting to version 1.070Y or later where it is installed.
- Identify active projects still using a security version below “2,” then schedule their conversion with owners who can validate the resulting project workflow.
- Test opening, comparing, monitoring, and restoring the converted project from every approved maintenance workstation before retiring older copies.
- Remove or isolate systems that must retain old GX Works3 releases for legacy recovery, and ensure they cannot become a routine path for editing current production projects.
- Review local Windows account permissions, remote-access tools, USB controls, and physical access around engineering workstations, because the published exploit begins with local software execution.
Mitsubishi credits Mayeul Fargier, Erwan Cordier, and Noé Flatreaud for reporting the flaw. The vendor has provided a usable workaround, but it imposes a clear administrative obligation: factories need to upgrade the Windows software and migrate the projects that the software opens. Leaving either task incomplete means the Block Password remains a weaker barrier than operators may assume.