Mitsubishi Electric GX Works3 Vulnerability Turns a Local Password Bypass Into a Control Program Risk

Mitsubishi Electric disclosed a GX Works3 vulnerability affecting every version of the software, despite protections intended to restrict access to individual program blocks. Tracked as CVE-2026-15688, the flaw lets a local attacker bypass a block password by modifying the running software in memory.

The attacker needs local access and low-level privileges, so this is not a direct internet attack against a programmable logic controller. However, successful exploitation can expose the control programs that define how connected machinery operates. An attacker could view, alter, destroy, or delete those programs.

That distinction creates the central tension. Block passwords promise protection for sensitive control logic, but the vulnerable authentication process can be manipulated on the engineering workstation that enforces them. The immediate contest is therefore between project-level password protection and the security of the workstation running GX Works3.

CISA published its industrial control systems advisory on September 17, 2026. Mitsubishi Electric released its corresponding security bulletin the same day. Both GX Works3 and the bundled Motion Control Setting software require action from operators.

The Mitsubishi Electric GX Works3 Vulnerability Affects Every Version

CVE-2026-15688 affects all versions of GX Works3 and all versions of Motion Control Setting packaged with it.

GX Works3 is engineering software used to create, configure, maintain, and diagnose automation projects involving Mitsubishi Electric programmable controllers. Motion Control Setting supports the configuration of motion-related control functions within that engineering environment.

The vulnerability concerns block password authentication. A block password is meant to restrict access to selected parts of a control project, including program logic that an owner wants to protect.

According to the industrial advisory, an attacker can run the affected product and modify part of its executable module in memory. The altered process can then accept an invalid block password as though it were valid.

This is an incorrect implementation of an authentication algorithm, classified as CWE-303. That category covers systems that perform authentication incorrectly, allowing an identity or credential check to produce an invalid result.

The CWE-303 definition is important here because the flaw does not mean an attacker discovered the correct password. Instead, the attacker interferes with the mechanism responsible for deciding whether a submitted password is correct.

Once the check has been bypassed, the attacker can gain access to protected control programs. Mitsubishi Electric says the resulting actions can include viewing, tampering with, destroying, or deleting those programs.

The affected products are:

• Mitsubishi Electric GX Works3, all versions

• Mitsubishi Electric Motion Control Setting, all versions

CISA calls the bundled component “Motion Control Settings,” while Mitsubishi Electric uses the singular product name “Motion Control Setting.” Both descriptions refer to the software packaged with GX Works3.

“All versions” does not mean every installation has the same practical exposure. Access controls, project security settings, workstation hardening, and network architecture still shape the attack path.

However, administrators cannot close the issue by checking whether they already run a nominally recent release. Mitsubishi Electric’s response also requires projects to use its newer security format.

The company assigns CVE-2026-15688 a CVSS 4.0 base score of 9.2, classified as critical. CISA lists a CVSS 3.1 score of 8.8, classified as high.

Those scores use different versions of the Common Vulnerability Scoring System. They are not contradictory ratings produced from an identical formula.

The official CVE record describes a local attack with low complexity, low privileges, and no user interaction. Its CVSS 4.0 assessment assigns high impact to confidentiality and integrity.

CISA’s CVSS 3.1 vector also treats the attack as local. It assigns high potential impact across confidentiality, integrity, and availability, with a changed scope beyond the vulnerable application.

CISA identifies the affected infrastructure sector as critical manufacturing. It also says the products are deployed worldwide and identifies Mitsubishi Electric’s headquarters location as Japan.

This combination explains the urgency without turning the flaw into a remote compromise story. The vulnerable application sits close to operational logic, even though exploitation begins on a local engineering system.

A Local Attack Can Still Reach Operational Logic

The local attack requirement narrows initial exposure, but it does not make the potential consequences local to one Windows process.

An attacker must first gain access to a computer running the affected engineering software. That access could follow stolen credentials, malware execution, abused remote support, physical access, or another workstation compromise.

The published advisory does not establish which entry path is most likely. It also does not claim that CVE-2026-15688 independently provides remote access or code execution.

Once present, the attacker needs low privileges and can manipulate the affected product while it runs. No additional user interaction is required under the published CVSS assessments.

That sequence separates initial access from exploitation. CVE-2026-15688 becomes useful after an attacker has crossed the workstation boundary, but before protected project blocks become accessible.

This is why engineering workstations deserve separate attention within an industrial security program. They often hold project files, credentials, software packages, and trusted connections needed to change automation systems.

A workstation compromise can therefore provide more than ordinary endpoint access. It can become a route toward the logic governing production equipment.

Consider a maintenance laptop used to update several production lines. If an attacker compromises that laptop, block passwords should still limit access to protected logic.

CVE-2026-15688 weakens that expected secondary barrier. The attacker can manipulate the password decision inside the engineering application instead of discovering or guessing the correct password.

The attacker could then inspect proprietary sequences, interlocks, timing logic, or equipment coordination rules stored in protected blocks. The exact content depends on each project.

Alteration creates a more serious operational concern. A small logic change can be difficult to notice through casual review, particularly within a complex project containing many blocks.

Deletion or destruction can also disrupt recovery. Even when controllers continue running existing logic, engineers may lose confidence in the integrity of workstation copies and project archives.

The published material does not document a confirmed incident caused by this vulnerability. CISA’s vulnerability enrichment recorded no known exploitation when the CVE became public.

That absence should temper claims about an immediate active campaign. It should not replace remediation, because public disclosure now gives defenders and attackers the same basic information.

The local attack vector also changes prioritization. Internet scanning alone cannot identify whether an organization has safely addressed the vulnerable authentication mechanism.

Asset owners need an inventory of engineering software installations, project security settings, remote access paths, and people authorized to modify control logic. A controller inventory by itself is incomplete.

Organizations should also distinguish computers that merely store project files from systems that actively connect to controllers. The latter can create a shorter path between compromised software and operational changes.

The main pressure falls on plant operators, system integrators, and contractors managing shared engineering environments. They must establish both software status and project-level security status.

A vendor may deliver an updated application, yet existing projects can retain older security behavior. That leaves remediation incomplete until project settings are reviewed and saved appropriately.

This two-part requirement is the practical lesson of the advisory. Endpoint updates matter, but the security state of the engineering artifact matters too.

Why the Block Password Failed as a Security Boundary

The flaw exposes a basic limit of application-level passwords: the same local process that checks the credential can become the attacker’s target.

A block password protects access through the normal GX Works3 interface. Under expected conditions, the application compares a submitted credential with the project’s protection data.

CVE-2026-15688 changes that decision path. By modifying part of the executable module in memory, an attacker can cause the application to authenticate an invalid password.

Memory modification means changing code or data after a program has loaded into a computer’s working memory. It does not necessarily change the application file stored on disk.

This distinction can complicate detection. A standard file-integrity check might confirm that the installed executable remains unchanged while the running process behaves differently.

The advisory does not publish exploit code or detailed offsets for the memory modification. It also does not describe a specific malware family using the technique.

Defenders should therefore avoid treating one hypothetical implementation as definitive. Detection should focus on the broader conditions that make process manipulation and project access possible.

Those conditions include untrusted software execution, excessive local privileges, weak endpoint monitoring, unrestricted remote sessions, and shared engineering accounts. Removable media can add another entry path in some facilities.

Block passwords still have value after remediation. They can prevent casual access, enforce engineering workflows, and reduce accidental exposure of protected logic.

However, they should not stand alone as the final barrier against a hostile user who already controls the engineering workstation. The vulnerability makes that architectural limitation visible.

The control protecting a sensitive asset should ideally operate independently from the system an attacker is expected to manipulate. In this case, the password verifier and the protected workflow share one application environment.

That does not mean every project password is useless. It means organizations must understand what the password can defend against and where its trust assumptions end.

Version 2 project security is Mitsubishi Electric’s response to the vulnerable design. The company instructs users to update the application and configure affected projects to use that security version.

For GX Works3, Mitsubishi Electric directs customers to install version 1.096A or later. Users must then set each project’s security version to “2.”

For Motion Control Setting, the company directs customers to install version 1.070Y or later. Projects must again use security version “2.”

The vendor bulletin points GX Works3 users to section 15.9 of the operating manual. That section covers protection against unauthorized data access and falsification.

These version thresholds can appear inconsistent with the statement that all versions are affected. The distinction is between vulnerable product scope and an available mitigation workflow.

Installing a qualifying release gives users the functions needed to apply the recommended project security setting. Installation alone does not automatically establish that every project uses security version 2.

Organizations should verify the saved project configuration rather than recording only the installed software version. They should also check copies held in archives, repositories, and contractor systems.

Projects restored from old backups deserve special attention. A workstation can run updated software while an imported project retains an older security configuration.

The same issue can arise when an integrator exchanges project files with a customer. Both parties need a common process for confirming the security version before using the project operationally.

This is the primary contest exposed by the incident: project password promises versus workstation trust. The promised protection holds only when the application enforcing it remains trustworthy.

Updating the Software Is Only Half the Mitigation

A complete response combines eligible software versions, security version 2 projects, controlled workstation access, and segmented operational networks.

The first task is discovery. Security teams should locate every installation of GX Works3 and Motion Control Setting across production sites, laboratories, maintenance shops, and contractor laptops.

That inventory should include the installed version, device owner, operating system, network zone, remote access method, and projects handled by each installation. Unknown engineering workstations should be investigated.

Next, administrators should update GX Works3 to version 1.096A or later. Motion Control Setting should be updated to version 1.070Y or later.

Mitsubishi Electric provides downloads through its Factory Automation software portal. Organizations should use established vendor channels and verify package integrity through their normal software-control process.

Administrators must then configure the security version of relevant projects to “2.” This step applies to both affected products and should be documented for each project.

A useful validation process should answer four separate questions:

• Does the organization know every affected workstation?

• Does each workstation run an eligible software release?

• Does each active project use security version 2?

• Are older copies controlled against accidental reuse?

A “yes” to the software question does not imply a “yes” to the project question. Tracking them as separate remediation fields reduces the chance of a false completion record.

Teams should test changed projects before production use. Industrial systems can have site-specific validation, change-control, and safety requirements that make an immediate blanket deployment inappropriate.

CISA advises organizations to perform an impact analysis and risk assessment before deploying defensive measures. That guidance matters when engineering software supports active production assets.

Testing should confirm that authorized engineers can open, edit, transfer, and recover the project as expected. It should also confirm that invalid credentials no longer provide access to protected blocks.

Organizations should preserve a known-good project copy before changing settings. The backup should be protected from routine workstation compromise and tested through a controlled restoration exercise.

Network controls address the attack paths surrounding the vulnerability. CISA recommends minimizing network exposure for control systems and preventing direct internet accessibility.

Control networks and remote devices should sit behind firewalls and remain isolated from business networks. Necessary communication should use narrowly defined routes and monitored services.

Remote access should use a maintained virtual private network or another approved secure access method. CISA notes that a VPN is only as secure as its connected devices.

That warning is directly relevant here. A protected tunnel does not compensate for a compromised maintenance laptop running vulnerable engineering software.

Remote sessions should require individual identities, multifactor authentication, time-limited approval, and logging where operationally feasible. Shared credentials make investigation and accountability harder.

Physical access also matters because the published attack vector is local. Engineering stations in open maintenance areas should not receive the same treatment as ordinary office computers.

Application control can reduce unauthorized executable activity on engineering systems. Endpoint monitoring can help identify suspicious process manipulation, debugging, injection, or credential-access behavior.

Those tools require careful testing in operational environments. A security agent that interrupts engineering software or controller communications can create its own production risk.

Organizations should review local administrator membership and remove unnecessary privileges. The advisory requires low privileges, so privilege reduction alone does not eliminate exposure.

Even so, minimizing administrative access can obstruct adjacent attack steps and limit an intruder’s ability to disable monitoring, install persistence, or alter system-wide controls.

Project access should also follow least privilege. Not every person who can launch GX Works3 needs authority to change every project or transfer logic to a controller.

Logging should cover project file changes, engineering access, remote sessions, controller downloads, and security-setting modifications. Available telemetry will vary by architecture.

A single unusual event does not prove exploitation. Correlation provides better evidence, such as an unexpected login followed by process manipulation and an unplanned controller transfer.

Teams should also inspect whether old project copies circulate through email, shared drives, removable media, or personal contractor storage. Those copies can reintroduce weaker settings after remediation.

A protected technical repository can help teams retain approved project versions, change records, validation notes, and recovery instructions. The repository must remain separate from untrusted workstation activity.

The objective is not merely to install a newer application. It is to restore confidence that both the engineering environment and the project artifact enforce the intended access boundary.

Severity Scores Do Not Describe Every Plant’s Real Risk

The 8.8 and 9.2 scores signal serious impact, but each organization must connect those ratings to its actual engineering workflow.

CVSS offers a standardized description of technical exploit conditions and consequences. It does not know whether a workstation controls one test bench or several production facilities.

Mitsubishi Electric’s CVSS 4.0 score is 9.2. That vector describes local access, low attack complexity, no additional attack requirements, low privileges, and no user interaction.

CISA’s CVSS 3.1 score is 8.8. Its vector also uses a local attack path and low privileges, while assigning high confidentiality, integrity, and availability impacts.

The difference reflects scoring-system semantics, including how downstream impacts are represented. Readers should not interpret it as disagreement over whether remediation matters.

A plant’s real risk rises when one engineering station manages many assets, remote access is broad, or project backups share the same trust boundary. Weak monitoring increases uncertainty.

Risk can be lower when engineering systems are isolated, access is tightly controlled, projects use security version 2, and transfers require independent authorization.

The vulnerability does not automatically let an anonymous internet user change a running controller. Claims describing it as a direct remote takeover would exceed the published evidence.

The advisory also does not say every successful password bypass immediately changes physical equipment. The attacker first gains access to protected control-program content within the affected engineering environment.

Further operational consequences depend on available connections, permissions, project workflows, controller state, and safety controls. Those details differ across facilities.

However, the ability to tamper with control programs creates a credible integrity risk. Industrial defenders cannot reduce the issue to intellectual-property exposure alone.

The uncertainty around exploitation is equally important. At disclosure, CISA’s SSVC record marked exploitation as “none,” automation as “no,” and technical impact as “total.”

SSVC, or Stakeholder-Specific Vulnerability Categorization, helps agencies describe exploitation and impact signals. It is separate from the numerical CVSS calculation.

“No exploitation” means CISA had not recorded known exploitation in that assessment. It does not prove nobody has tested, privately developed, or used the technique.

“Automatable: no” suggests the attack is not suited to reliable, scalable automation under the assessment. Local access and environment-specific process manipulation support that conclusion.

This reduces the resemblance to internet-wide vulnerability scanning. It increases the relevance of targeted access, insider risk, and compromises that already reached an engineering network.

The researchers credited for reporting the flaw are Mayeul Fargier, Erwan Cordier, and Noé Flatreaud. Public advisories do not describe their complete discovery process.

The Japanese coordination notice independently tracks the vulnerability and directs users to the vendor’s countermeasures. That coordination strengthens the public record.

Security teams should still treat the vendor bulletin as the authority for product-specific instructions. CISA adds sector context and broader defensive guidance.

The skeptical question is whether organizations can verify project-level remediation at scale. Software inventory platforms may report installed versions without understanding GX Works3 project security settings.

That gap can produce reassuring dashboards while archived or active projects remain configured under older protection behavior. Manual checks do not scale well across distributed engineering teams.

Asset owners should therefore demand evidence tied to each project. A completed change record, validated security setting, approved backup, and responsible owner provide stronger assurance.

Another uncertainty concerns detection. The public description identifies in-memory modification, but it does not provide a complete set of observable indicators.

Defenders should avoid building an alert around one assumed tool or technique. Behavioral monitoring and strict access control remain more durable approaches.

The most useful risk assessment combines three layers: exposure of the workstation, exploitability of the affected process, and authority to affect operational assets. Leaving out one layer distorts priority.

Three Signals Will Show Whether Operators Closed the Gap

The next test is not another severity score. It is whether operators can prove that updated software and security version 2 reached every relevant project.

The first signal is measurable project migration. Organizations should track how many active projects use security version 2, not merely how many computers received a software update.

A rising completion rate would strengthen confidence that the authentication weakness is being addressed where protected logic resides. An update-only metric would leave the central exposure unresolved.

The second signal is any change in exploitation status. CISA’s initial assessment recorded no known exploitation, while the public CVE described the potential for total technical impact.

A confirmed exploitation report, public proof of concept, or addition to CISA’s Known Exploited Vulnerabilities catalog would raise urgency. Continued absence of exploitation would not cancel remediation.

The third signal is follow-up guidance from Mitsubishi Electric. Administrators should watch for revised affected-version language, new fixed builds, clearer validation instructions, or additional detection information.

A later product change that removes reliance on project configuration would simplify remediation. Guidance that continues to require manual project conversion would keep the operational burden on asset owners.

Organizations should not wait for those signals before acting. The vendor has already supplied minimum software versions and a required project setting.

The appropriate response begins with an inventory of GX Works3 and Motion Control Setting installations. It continues through controlled updates, security version 2 conversion, testing, and protected backups.

Teams should then review local and remote access to each engineering workstation. Network segmentation, individual accounts, monitored sessions, and limited privileges reduce the opportunity surrounding the flaw.

Finally, managers should ask for evidence at the project level. A software deployment report cannot confirm that block protection now uses the required security version.

CVE-2026-15688 matters because it challenges a control that engineers may have treated as an independent safeguard. The password check depended on the integrity of the application performing it.

Has your organization verified both sides of the fix? Confirm the installed engineering software first, then open every active project and document its security version. Treat any missing owner, unmanaged laptop, or unverified archive as unfinished work.