GT Designer3 Security Risks: Patch Isolate Detect in ICS

Mitsubishi Electric’s GT Designer3 — the engineering suite used to build and transfer HMIs for GOT series panels — remains in the crosshairs of ICS security teams after coordinated disclosures and multiple CISA advisories identified serious weaknesses in GT Designer3, the associated GT SoftGOT products, and related MELSOFT components; defenders should treat these as high-priority to inventory, isolate, patch, and monitor because exploitation can expose plaintext credentials, bypass authentication, or enable remote code execution in certain configurations.

Background and overview​

GT Designer3 is Mitsubishi Electric’s authoring tool for GOT HMI families, widely deployed in manufacturing and critical infrastructure. Over the last two years Mitsubishi and national CERTs have coordinated multiple advisories covering distinct but related weaknesses: weak encoding of passwords in the GOT data-transfer function, missing authentication for critical functions in EZSocket/GT Designer RPC services, and unsafe reflection that can allow an attacker to load malicious libraries via RPC. These issues were cataloged across CVE entries and vendor advisories and appear in bundled CISA advisories addressing Mitsubishi FA engineering software more broadly. What that means in practice is straightforward: engineering workstations and HMI runtime devices that use older GT Designer3, GT SoftGOT, EZSocket and related MELSOFT products may leak or expose authentication material, accept unauthenticated control requests, or — in the worst case described by a critical CVE — allow an attacker to execute code on hosts that handle the vendor’s RPC communications. Mitsubishi has issued fixes for many of the identified faults but the product family’s broad footprint and diverse version matrix make immediate inventory and mitigation essential.

---

The immediate news: CISA advisory availability and the DHS message​

A recent user-supplied link points to a CISA advisory (ICSA-25-350-04) that addresses Mitsubishi FA software; when that page is unreachable the DHS/CISA platform displays a temporary outage message. Until the specific ICSA-25-350-04 page can be loaded directly, operators should rely on the vendor PSIRT notices, canonical CVE records, and prior CISA advisories that enumerate the affected product versions and mitigation steps. The CISA advisory ecosystem has previously grouped Mitsubishi advisories (for example, advisory bundles covering GT/GOT products and the broader FA Engineering Software family), and those canonical pages remain the best public guidance when available. Treat the direct CISA page unavailability as a temporary accessibility problem, not proof a vulnerability has been withdrawn. ([]

---

What the advisories and CVEs actually say — technical summary​

Weak encoding: password extraction via data-transfer paths​

One documented problem in GT Designer3/GOT2000 was weak encoding for password transfer in the data transfer security function. The practical effect is that encrypted passwords sent during project transfer or configuration could be decrypted by an attacker who can sniff the relevant traffic, exposing plaintext credentials. Mitsubishi and CISA recommended updated product builds to replace the weak encoding logic.

Missing authentication and unsafe reflection (CVE‑2023‑6942 and CVE‑2023‑6943)​

Two high‑impact CVEs underpin the most critical exposure:

• CVE‑2023‑6942 (Missing Authentication for Critical Function) — certain EZSocket and GT Designer3 RPC endpoints accepted specially crafted packets that bypassed authentication, enabling unauthorized connections and potentially allowing an attack to manipulate device state or configuration.
• CVE‑2023‑6943 (Unsafe Reflection / Externally-Controlled Code Selection) — an attacker able to connect to the affected RPC interface could cause the product to load an attacker-controlled library, which in turn can permit remote code execution under the context of the impacted process. Public trackers list high CVSS values for this issue and vendor pages provide version thresholds for remediation.

Both weaknesses were publicly coordinated and assigned CVEs; the combined effect is that unpatched engineering suites and runtime services may be vulnerable to network-originated attacks with little or no authentication required.

Scope and affected versions (practical inventory)​

The affected list spans multiple MELSOFT components — GT Designer3 Version1 (GOT1000 and GOT2000), GT SoftGOT, EZSocket, GX Works2/3, MELSOFT Navigator, and several supporting runtime or middleware components. Different CVEs target slightly different version ranges; vendors published explicit fixed-version thresholds (for example, GT Designer3 v1.300N or later addressed the weak-encoding issue for some GOT2000 variants). Because product versioning is granular and OEMs use suffixes and subbuild identifiers, defenders must capture the full model, SKU, and firmware/software string when triaging.

---

Why Windows admins should care (operational impact)​

Industrial engineering tools and HMIs are often hosted on Windows workstations and servers — that’s where the cross-domain risk becomes real.

• Engineering hosts typically hold powerful credentials and network access to PLCs, HMIs, and file repositories; if an engineering workstation is compromised via a GT Designer3 or GX Works weakness, an attacker can pivot into OT assets or steal project files. This is a recurring theme in CISA and vendor advisories: vulnerabilities in OT engineering tools translate into Windows-borne operational and security risk.
• GT/GOT project files can contain plaintext or recoverable credentials in some cases; attackers with access to those files can extract credentials and re‑use them to access protected projects or devices. That makes endpoint protection and file-handling policies on Windows machines essential.
• Even where a vulnerability only generates availability impacts (DoS), the effect is non-trivial. HMIs that lose connectivity can force manual operations, create safety hazards, and trigger high-cost production stoppages — events commonly investigated as cross-domain incidents because Windows-based supervisory systems and historian servers stop receiving telemetry.

---

Validating vendor and national guidance — cross-checks​

To avoid single-source dependence, defenders should validate the vendor’s PSIRT advisories against at least two independent sources:

• Vendor PSIRT pages list affected versions, fixed releases, and product-specific mitigation steps (for example, the FA vulnerability portal maintained by Mitsubishi). Those pages are the authoritative record for exact build numbers and upgrade artifacts.
• CISA advisories aggregate vendor disclosures, provide CVSS scoring, and add consensus mitigations tailored for ICS operators (segmentation, removal of Internet exposure, and VPN/jump host recommendations). When reachable, CISA’s advisory pages are succinct operational references.
• Independent CVE aggregators and national CERTs (NVD, CVE Details, INCIBE, JVN) re-publish CVE numbers, independent threat scores, and timeline metadata — these are helpful cross-checks for public scoring differences and exploitability context.

Where vendor and public sources differ on scoring or scope, default to the vendor’s fixed-version guidance for patching, but document any discrepancies and perform a local risk calculation.

---

Concrete risk scenarios (realistic exploit chains)​

• An attacker gains network access to an engineering VLAN (through a misconfigured VPN or via a compromised contractor laptop). They send crafted RPC packets to an EZSocket endpoint; authentication is bypassed (CVE‑2023‑6942) and the attacker uploads a malicious library path that the service later loads, achieving remote code execution (CVE‑2023‑6943). Result: engineering workstation process is owned and project files are exfiltrated or modified.
• A supply‑chain or contractor exchange contains a GT Designer3 project file. That project carries encrypted credentials that use the old weak-encoding scheme; the attacker intercepts the transfer and recovers plaintext passwords, which are then used to access protected devices or services. Result: credential theft and lateral movement into PLC configuration and HMI runtime services.
• A malformed packet or purposefully-crafted session forces repeated disconnects between HMIs and PLCs, producing intermittent DoS conditions. Alarms cascade and operators manually stop production, causing safety and financial impacts. Even where code execution isn’t apparent, availability losses are operationally critical.

---

Mitigation playbook for Windows and OT teams​

Treat mitigation as a program, not a single task. The following prioritized steps combine vendor guidance, CISA recommendations, and ICS best practice.

Immediate (hours)​

• Inventory: capture full product identifiers for every GOT, GT Designer3 installation, GX Works2/3, EZSocket, and SoftGOT instance. Record exact version and build strings. This inventory step is the gating factor for any subsequent action.
• Isolate externally exposed endpoints: block any direct Internet reachability to engineering hosts, GOT panels, and EZSocket/TCP ports using perimeter firewalls. If devices must be remotely accessed, require a hardened VPN or jump host.
• Apply temporary access filters: use ACLs to restrict which Windows management hosts can reach OT devices and remove broad, unconstrained access from enterprise subnets. Enable IP filtering where product features support it.

Short term (days)​

• Patch to vendor‑recommended versions where available. Mitsubishi’s advisories list fixed builds for many product lines (for example, GT Designer3 updates and GOT firmware releases). Follow vendor release notes for staging and rollback instructions. Never update production PLC firmware or HMI runtime without test validation.
• Rotate exposed credentials found in project files or exposed in the wild. Where plaintext or recoverable encodings were used, assume compromise and force password changes and credential re-issuance.
• Harden Windows engineering workstations:
• Enforce least-privilege for engineering users.
• Block USB autorun and disable removable-media write access for engineering hosts.
• Maintain up‑to‑date endpoint protection and application control (whitelisting where feasible).

Medium term (weeks)​

• Apply network-level detection: enable flow logging and deploy IDS/IPS rules tuned to vendor protocols (SLMP, EZSocket RPC patterns). Capture PCAPs during suspicious events and correlate with Windows event logs on HMIs, historians, and engineering hosts.
• Implement jump hosts with MFA and session recording for all remote maintenance sessions; enforce strict audit trails for file transfers and project publishing.

Longer term (months)​

• Redesign segmentation and supply‑chain controls: segregate OT networks from corporate IT, require encrypted and authenticated file-exchange channels with contractors, and maintain an asset lifecycle plan for FA engineering tools.
• Establish an ICS patch management program that aligns test, staging, and production cycles; keep a tested spare set of devices and rollback plans for firmware or HMI updates.

---

Detection and forensics: what to watch for​

• Sudden or repeated TCP session resets between HMIs and PLCs on vendor ports (unexpected disconnects).
• New or unexpected library paths referenced by MELSOFT or EZSocket processes (possible unsafe-reflection exploitation).
• Discovery of project files with embedded plaintext or re-creatable credentials on shared drives or contractor delivery channels.
• Unexpected process crashes or service restarts on engineering workstations immediately after file transfers or project imports.

When investigating, collect Windows event logs, MELSOFT application logs, network PCAPs for affected sessions, and a copy of the project file(s) for offline analysis. If remote code execution is suspected, treat the host as compromised and escalate to incident response with full containment, forensic imaging, and credential rotation.

---

Strengths and limits of vendor / CISA guidance — critical analysis​

• Strength: Vendor PSIRT disclosures tend to list exact affected builds and provide fixed-version thresholds, enabling precise remediation. Mitsubishi has published multiple security notes and follow-ups for FA engineering software.
• Strength: CISA advisories centralize vendor guidance, CVE mappings, and recommended mitigations tailored to ICS risk profiles — a valuable operations-level distillation for Windows-centric teams managing OT assets.
• Risk/Limit: Version fragmentation makes triage error-prone. Multiple advisories across different dates sometimes use differing version cutoffs; defenders must capture exact build IDs rather than rely on shorthand version numbers.
• Risk/Limit: Some advisories emphasize local‑file attack vectors (file access rather than remote network attack) and yet many defenses are network-focused. That mismatch can leave an engineering workstation vulnerable even in segmented networks if project files propagate via removable media or shared repositories.
• Caveat: In a few cases public scoring (CVSS v3 vs v4 or aggregator scores) varied between trackers; where scores differ, follow vendor and national guidance for prioritization—but document the scoring basis used in your organization.

---

Action checklist for WindowsForum readers (operational checklist)​

• Identify all hosts running GT Designer3, GT SoftGOT, EZSocket, GX Works2/3, and MELSOFT Navigator; capture full version strings.
• If any listed product is outside the vendor fixed-version recommendations, schedule immediate staging and patching.
• Block direct Internet access to GOT panels and FA tool RPC/TCP ports until patches or compensating controls are in place.
• Rotate credentials that may have been embedded in projects or transferred under older encodings.
• Require contractors to use encrypted, auditable transfer methods; sandbox all incoming project files before import.
• Enable PCAP and flow capture for engineering VLANs and correlate with Windows event logs.
• Enforce jump-host with MFA and session logging for all remote maintenance.
• Test patches in a lab and maintain rollback images and backups of PLC/HMI projects.

---

What remains unverifiable and what to watch for​

• The specific CISA page referenced (ICSA‑25‑350‑04) may be temporarily inaccessible or rate-limited by the DHS/CISA portal; the downtime message should be treated as transient. Until the live advisory page is reachable, rely on the vendor PSIRT documentation and canonical CVE records as the authoritative technical source; when the CISA page returns, reconcile its guidance against the vendor bulletin. Any claim that the advisory was rescinded or revised should be verified directly on the CISA or Mitsubishi PSIRT pages once the platforms are reachable. ([]
• If you encounter product-specific behavior that contradicts vendor release notes (for example, a patched build that still exhibits legacy RPC behavior), treat that as high-severity and report it to Mitsubishi’s PSIRT and to national CERTs for coordinated investigation.

---

Conclusion​

The Mitsubishi Electric GT Designer3 and associated MELSOFT components have been the subject of multiple high‑impact disclosures that affect both OT assets and the Windows infrastructure that manages them. The technical tripod of weak encoding of credentials, missing authentication on RPC endpoints, and unsafe reflection enabling potential code load means the risk vector set is broad: network attackers, supply-chain attackers, and insiders each have plausible exploitation paths.
Until every affected host is inventoried and either patched to the vendor’s fixed build or isolated behind compensating controls (VPN/jump host, segmentation, ACLs), organizations should operate under the assumption of exposure: rotate credentials, lock down engineering hosts, and increase logging and detection for anomalous RPC behavior. Use the vendor PSIRT advisories and CVE data as primary references, and consult CISA advisories when they are available for consolidated operational guidance. Every paragraph above advances a practical step: inventory, isolate, patch, monitor, and document. For Windows administrators and OT engineers alike, GT Designer3 vulnerabilities are not a theoretical exercise — they are an operational risk that must be addressed with the same urgency applied to ransomware- or supply‑chain threats in IT environments.

---

Source: CISA Mitsubishi Electric GT Designer3 | CISA