← Back to Feed CACHED · 2026-10-02 20:29:55 · CACHE_KEY CVE-2026-86326
CVE-2026-86326 · CWE-347 · Disclosed 2026-10-02

An improper verification of cryptographic signature vulnerability exists in protocol gateways because the…

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

The factory's protocol translator will flash whatever firmware you hand it, signed or malicious, and the manufacturer says there is no fix coming

CVE-2026-86326 is a missing firmware signature verification flaw in Moxa's entire MGate protocol gateway family — the MB3000, EIP3000, 5000, and legacy W5000 series, spanning 17+ product lines across all firmware versions ever released. The device's firmware update mechanism does not validate cryptographic signatures before writing images to flash. An attacker who has already obtained admin-level access to the gateway's web management console can upload a trojanized firmware image that replaces the legitimate OS. The malicious image persists through reboots and — critically — survives subsequent legitimate firmware updates, giving the attacker a durable implant on a device that sits between your SCADA system and field PLCs/RTUs.

Moxa, acting as CNA, assigned a CVSS 4.0 score of 8.6 (HIGH) with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. That mechanical score is defensible: it correctly reflects the PR:H requirement (admin credentials needed) and the absence of downstream scope change. However, it does not account for two deployment realities that matter enormously. First, 100% of MGate installs sit in OT/ICS networks where the blast radius of a persistent gateway implant includes Modbus traffic manipulation and potential safety impact. Second, there is no patch and no timeline for one — the device was never designed with firmware signing, making this a design-level gap rather than a fixable bug. Our noisgate assessment lands at HIGH 8.4: the OT context and no-patch status push upward, while the PR:H prerequisite and typical OT segmentation provide real friction that prevents CRITICAL.

"OT gateways accept any firmware — admin-level attackers get persistent implants with no vendor fix in sight"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Gain access to OT network segment

The attacker must first reach the Layer 2/3 network where the MGate management interface resides. In mature OT environments, this segment is behind a firewall, DMZ, or jump host — often requiring VPN credentials or a prior compromise of an IT-to-OT pivot point. In less mature environments, flat networks may expose the management interface to broader corporate LAN segments.
Conditions required:
  • Network connectivity to the OT VLAN or management subnet where the MGate is deployed
Where this breaks in practice:
  • IEC 62443 / Purdue Model segmentation should isolate OT management interfaces behind firewalls and jump hosts
  • VPN + MFA policies on IT/OT boundary reduce reachability
Detection/coverage: Network IDS at IT/OT boundary (e.g., Claroty, Nozomi, Dragos) should flag lateral movement into OT segments
STEP 02

Obtain admin credentials for MGate web console

The MGate web console (HTTP on most models, HTTPS on MB3x80/MB3x80) requires authentication. The attacker needs admin-level credentials. OT device credential hygiene is notoriously poor: default passwords (admin/moxa or admin/admin) persist in a significant fraction of deployments, and shared credential usage is common. Credential theft from OT asset management databases or configuration backups is another vector.
Conditions required:
  • Valid admin-level credentials for the MGate web console
  • Knowledge of the device IP address and management port
Where this breaks in practice:
  • Organizations following Moxa's own hardening guide should have changed defaults
  • RBAC-aware deployments may restrict firmware upload to a dedicated admin role
Detection/coverage: Failed authentication attempts logged on the device (if logging is enabled and forwarded to SIEM); credential-stuffing patterns detectable by OT monitoring platforms
STEP 03

Navigate to firmware update interface

With admin authentication, the attacker accesses the web-based firmware update page. This is a standard, documented management function — no exploit code or special tooling is required. The interface accepts a binary firmware image file via HTTP/HTTPS upload.
Conditions required:
  • Authenticated admin session on the MGate web console
Where this breaks in practice:
  • Session timeout and IP-based ACLs can limit the attack window
  • HTTPS-only configurations (available on some models) prevent credential interception
Detection/coverage: Web management access logging; anomalous admin session timing or source IP detectable by OT behavioral monitoring
STEP 04

Upload trojanized firmware image

The attacker prepares a modified firmware binary — either by patching a legitimate Moxa firmware image with a backdoor or by building a fully custom image for the device's embedded platform (typically ARM or MIPS-based Linux). Because the device performs zero cryptographic signature verification, the malicious image is accepted and written to flash identically to a legitimate update. This requires reverse-engineering the firmware format, but Moxa firmware images have been publicly analyzed in prior ICS security research.
Conditions required:
  • A crafted firmware image compatible with the target MGate hardware platform
  • No firmware signature verification on the device (the vulnerability itself)
Where this breaks in practice:
  • Requires embedded systems expertise to build a working malicious firmware image
  • Hardware-specific: different MGate series use different SoCs and boot processes
  • No public PoC or weaponized tooling exists as of 2026-10-03
Detection/coverage: No device-side detection — the vulnerability IS the absence of validation. Network-side: firmware upload traffic (large HTTP POST to management interface) is detectable by deep packet inspection on the OT monitoring plane.
STEP 05

Persistent code execution on the gateway

The malicious firmware executes with full control of the gateway hardware. The attacker now has a persistent implant that survives reboots and — per Moxa's advisory — persists across subsequent legitimate firmware updates. From this position, the attacker can silently manipulate Modbus RTU/ASCII ↔ TCP translation (alter register values, drop commands, inject false responses), establish reverse shells for persistent OT network access, or brick the device to cause denial of service to downstream field devices.
Conditions required:
  • Successful firmware flash from step 4
Where this breaks in practice:
  • None — once flashed, the device runs the attacker's code unconditionally
Detection/coverage: Firmware integrity monitoring via out-of-band hash comparison; behavioral anomaly detection on Modbus traffic patterns (e.g., unexpected register value changes, new TCP connections from the gateway)
03 · Compensating Control

1
HIGH 8.4→MEDIUM 5.8
SEVERITY REDUCED
Restrict firmware update interface to dedicated management VLAN with IP-based ACLs — Configure upstream switches/firewalls to allow management web console access (TCP 80/443) only from a hardened jump host on a dedicated management VLAN. This breaks attack path step 1 for any attacker not already on the management segment. Deploy within the noisgate mitigation SLA of 30 days for HIGH severity. Document the ACL rules and test connectivity from authorized stations.
2
HIGH 8.4→MEDIUM 6.2
SEVERITY REDUCED
Rotate all MGate admin credentials to unique, strong passwords per device — Replace default and shared credentials with unique 16+ character passwords per gateway, stored in a PAM vault or OT credential manager. This directly raises the bar on attack path step 2. Most OT environments still run defaults — this single control eliminates the most common PR:H fulfillment path. Deploy within 30 days per noisgate mitigation SLA.
3
HIGH 8.4→HIGH 7.2
Deploy OT network monitoring with firmware-upload detection rules — Configure OT-aware IDS (Claroty, Nozomi Networks, Dragos Platform, or similar) to alert on large HTTP POST requests to MGate management interfaces — the signature of a firmware upload. Also baseline normal Modbus traffic patterns and alert on anomalies (new register addresses, changed polling intervals, unexpected TCP connections from the gateway). This adds detection at attack path steps 3–5. Deploy within 30 days.
4
HIGH 8.4→HIGH 7.5
Implement out-of-band firmware integrity verification process — After any firmware update (or on a quarterly schedule), dump the running firmware image via the device's diagnostic interface or serial console and compare its SHA-256 hash against the known-good hash published on Moxa's official download page. This is a detective control for attack path step 5 — it won't prevent the flash but will detect tampering. Document the procedure and assign it to OT security operations.
5
HIGH 8.4→LOW 4.0
SEVERITY REDUCED
Segment OT network per IEC 62443 / Purdue Model with IT/OT DMZ — If not already in place, establish a proper IT/OT boundary with a DMZ, firewalls, and data diodes where applicable. This limits lateral movement from IT into the OT zone where MGate devices reside. This is a foundational control that reduces exposure for this and all future OT vulnerabilities. Plan and execute within the noisgate remediation SLA of 180 days.
What doesn't work
  • Firmware rollback/reinstall: Per Moxa advisory MPSA-269540, malicious firmware modifications persist across subsequent firmware updates. Reflashing with a legitimate image may not reliably overwrite a sophisticated implant that hooks the update mechanism itself. A full factory reset via serial console with hardware-verified boot media is the only reliable recovery path.
  • Web application firewall (WAF): The firmware upload is a legitimate authenticated admin function over HTTP/HTTPS. A WAF cannot distinguish a malicious firmware upload from a legitimate one — the payload is an opaque binary blob.
  • Endpoint detection / antivirus: MGate devices are embedded Linux/RTOS systems with no support for third-party security agents. There is no EDR, AV, or host-based detection capability available for these platforms.
  • TLS/HTTPS enforcement alone: While HTTPS prevents credential interception in transit, it does not address the core vulnerability — the device accepts unsigned firmware regardless of transport security.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNo known exploitation. Not listed in CISA KEV. No CISA ICS-CERT advisory issued yet for this specific CVE as of 2026-10-03. No campaigns attributed.
Proof-of-conceptNo public PoC detected. Checked pocindex.io (no results), GitHub (no repos named CVE-2026-86326), ExploitDB (no entries), and nuclei templates (none). The SecureWithUmer/CVE-2026-PoCs aggregate repo does not list this CVE. Exploitation requires embedded firmware engineering skill, raising the bar for PoC development.
EPSS scoreNot yet scored. FIRST EPSS API returns empty results — the CVE was published <24 hours ago (2026-10-02). Expect initial EPSS scoring within 7–14 days. Given PR:H and OT niche, anticipate a low EPSS probability (<5th percentile).
KEV statusNot listed. No CISA Known Exploited Vulnerabilities entry. No federal BOD deadline applies.
CVSS vectorCVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N — 8.6 HIGH (Moxa CNA-assigned, CVSS v4.0). Network-reachable but requires admin privileges. No scope change (compromised gateway only, per CVSS math — though real-world blast radius extends to downstream Modbus devices).
Affected versionsAll firmware versions, all time across: MGate MB3170, MB3270, MB3180, MB3280, MB3480, MB3660, MB3000 series, EIP3170, EIP3270 (EIP3000 series), MGate 5217, 5105, 5109, 5101, 5114, 5118 (5000 series), and discontinued W5108/W5208. Version 1.0 through current.
Fixed versionsNone. No firmware patch exists. Moxa advisory MPSA-269540 explicitly states no fix is available — the device was never designed with firmware signature verification. Moxa directs users to Security Hardening Guides. No timeline for a fix has been communicated.
Scanning / exposureShodan indexes ~4,400 Moxa devices globally (all product lines). MGate-specific exposure is a subset. OT protocol gateways should never be internet-exposed — most MGate management interfaces sit on internal OT VLANs. Internet exposure represents severe misconfiguration, not typical deployment.
Disclosure timelineReserved: 2026-09-07 · Published: 2026-10-02 · Advisory: MPSA-269540 (covers both CVE-2026-86325 and CVE-2026-86326) · NVD status: Awaiting Analysis
Reporter / creditSelf-reported by Moxa as CNA. No external researcher credited. Disclosed alongside CVE-2026-86325 (stack buffer overflow, CVSS 4.0 9.4 Critical) in the same advisory.

Sources.

  1. Moxa Security Advisory MPSA-269540
  2. SecurityOnline — Moxa MGate Vulnerabilities Analysis
  3. Strix AI — CVE-2026-86326 Detail
  4. Threat Radar — CVE-2026-86326 Live Intelligence
  5. TheHackerWire — CVE-2026-86326 Vulnerability Details
  6. ThreatInt CVE Database — CVE-2026-86326
  7. Moxa MGate MB3170/MB3270 Series Product Page
  8. CISA ICS Advisory — Moxa MGate Protocol Gateways (historical)
05 · The Call

Final Verdict
= UNCHANGED to HIGH (8.4/10)

Why this verdict

  • PR:H is real friction but weaker than it looks in OT: Admin credentials on Moxa MGate devices are frequently default (admin/moxa, admin/admin) or shared among operations staff. OT credential hygiene surveys consistently show 40–60% of embedded devices retain factory defaults. PR:H is a speed bump, not a wall.
  • No patch, no timeline — this is a design gap: The device never implemented firmware signing. Moxa's advisory offers no fix and no ETA. Defenders cannot remediate by patching; they can only mitigate by restricting access to the firmware update function. This durability of exposure pushes severity upward.
  • Persistence survives remediation of the initial vector: Even if the initial compromise (stolen admin creds) is detected and credentials are rotated, the malicious firmware remains on the device. The implant outlives the incident response. This is qualitatively different from a configuration-based attack that can be reversed.
  • Role multiplier: Moxa MGate gateways are purpose-built OT/ICS protocol translators — 100% of the installed base occupies the high-value OT role by definition. In canonical deployment (bridging SCADA HMI to field PLCs via Modbus RTU/TCP), a persistent firmware implant enables silent manipulation of process data: falsified sensor readings sent to operators, altered setpoints sent to PLCs, or total communication denial. This qualifies as OT-safety impact. The blast radius is per-gateway (host-level + downstream field devices), not fleet-scale — limiting the ceiling.
  • No exploitation ecosystem yet: Zero PoC, zero KEV, zero observed campaigns. Exploitation requires embedded firmware reverse-engineering skill and hardware-specific knowledge. This caps the near-term probability, though it does not reduce the impact ceiling.

Why not higher?

CRITICAL would require that this vulnerability unlocks a new impact category beyond what the PR:H prerequisite already provides. An attacker with admin access to an MGate can already reconfigure Modbus slave/master routing, alter polling parameters, and manipulate data translation — achieving immediate (though non-persistent) safety impact through configuration alone. CVE-2026-86326's incremental contribution is persistence (surviving reboots and firmware updates), which is operationally significant but does not elevate the blast radius to fleet-scale, domain-scale, or supply-chain-scale. Additionally, the per-gateway blast radius (one gateway + its downstream serial devices) limits the scope versus a vulnerability in a centralized OT management platform. No PoC or weaponized tooling exists, and exploitation requires niche embedded systems expertise.

Why not lower?

MEDIUM would dangerously undercount the deployment context and the no-fix reality. These are exclusively OT/ICS devices where the affected function (firmware update) controls the entire device execution environment. The absence of any firmware signing is a permanent design gap — not a bug that will be patched in a release cycle. A persistent implant on a Modbus gateway that outlives credential rotation and standard IR playbooks represents a qualitative escalation in attacker dwell time. Combined with the consistently poor credential hygiene documented across OT embedded devices, the PR:H barrier is less protective than it would be in an IT context.

06 · Verification

Crowdsourced verification payload.

Run from any workstation with network access to the MGate management interface. Requires Python 3.6+. No special privileges needed — the script makes unauthenticated HTTP requests to identify the device model. Example: python3 check_cve_2026_86326.py 192.168.127.254 or with custom port: python3 check_cve_2026_86326.py 10.0.100.10 8080. Exit code 1 = VULNERABLE, 0 = PATCHED (not an affected model), 2 = UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
"""CVE-2026-86326 Checker - Moxa MGate Missing Firmware Signature Verification
All firmware versions of affected MGate series are vulnerable. No patch exists.
"""
import sys
import re
import urllib.request
import ssl

AFFECTED_KEYWORDS = [
    "mb3170", "mb3270", "mb3180", "mb3280", "mb3480", "mb3660",
    "mb3000", "eip3170", "eip3270", "eip3000",
    "5217", "5105", "5109", "5101", "5114", "5118",
    "w5108", "w5208", "mgate 5"
]

def check(host, port=80):
    ctx = ssl.create_default_context()
    ctx.check_hostname = False
    ctx.verify_mode = ssl.CERT_NONE
    proto = "https" if port == 443 else "http"
    url = f"{proto}://{host}:{port}/"
    print(f"[*] Probing {url} ...")
    try:
        req = urllib.request.Request(url, headers={"User-Agent": "noisgate-CVE-2026-86326/1.0"})
        with urllib.request.urlopen(req, timeout=15, context=ctx) as resp:
            body = resp.read().decode("utf-8", errors="ignore")
            headers = dict(resp.getheaders())
    except Exception as e:
        print(f"[!] Connection failed: {e}")
        print("UNKNOWN")
        return 2

    # Check Server header for Moxa fingerprint
    server = headers.get("Server", "")
    combined = (body + " " + server).lower()

    is_moxa = "moxa" in combined
    is_mgate = "mgate" in combined

    if not is_moxa:
        print(f"[*] Device at {host}:{port} does not appear to be a Moxa product.")
        print("UNKNOWN")
        return 2

    if not is_mgate:
        print(f"[*] Moxa device detected but does not appear to be an MGate gateway.")
        print("UNKNOWN")
        return 2

    # Extract model string
    model_match = re.search(r"(MGate[\s-]*(?:MB|EIP|W)?[\s-]*[\dA-Za-z]+)", body, re.IGNORECASE)
    model = model_match.group(1).strip() if model_match else "MGate (model unknown)"
    print(f"[*] Detected: {model}")

    # Extract firmware version if visible
    fw = re.search(r"(?:firmware|version|fw)[:\s]+[Vv]?([\d.]+)", body, re.IGNORECASE)
    if fw:
        print(f"[*] Firmware: v{fw.group(1)}")

    # Check against affected series
    for kw in AFFECTED_KEYWORDS:
        if kw in combined:
            print(f"[!] AFFECTED: {model} matches vulnerable series keyword '{kw}'")
            print(f"[!] CVE-2026-86326: No firmware signature verification.")
            print(f"[!] ALL firmware versions affected. No patch available.")
            print(f"[!] Ref: Moxa MPSA-269540")
            print("VULNERABLE")
            return 1

    print(f"[*] {model} did not match known affected series keywords.")
    print(f"[*] Verify manually against Moxa MPSA-269540 affected product list.")
    print("PATCHED")
    return 0

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print(f"Usage: {sys.argv[0]} <host> [port]")
        print(f"Example: python3 {sys.argv[0]} 192.168.127.254 80")
        sys.exit(2)
    host = sys.argv[1]
    port = int(sys.argv[2]) if len(sys.argv) > 2 else 80
    sys.exit(check(host, port))
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously