← Back to Feed CACHED · 2026-07-13 08:31:14 · CACHE_KEY CVE-2026-4769
CVE-2026-4769 · CWE-912 · Disclosed 2026-07-13

Certain devices in the WAGO System I/O Field series activate an internal diagnostic capability during the…

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

A factory-floor I/O module ships with a diagnostic door that pops open every time the lights come on

CVE-2026-4769 is a CWE-912 Hidden Functionality issue in select WAGO System I/O Field modules — the ruggedized field-mounted I/O devices that sit directly on the production network wiring back to PLCs, DCS heads, and SCADA gateways. Per the vendor advisory (2026-07-13), during the initial startup sequence the device activates an *internal diagnostic capability*. Combined with the vendor's own CVSS vector (AV:N/AC:L/PR:N/UI:N), that means the diagnostic interface is reachable over the network from an unauthenticated adjacent host at every power-cycle — and in most OT sites, power cycles happen on maintenance windows, cold starts, and outage recovery, exactly when the plant is most fragile. Affected version ranges are not fully enumerated in the public feed yet; treat *all currently-shipping WAGO System I/O Field firmware* as suspect until WAGO's PSIRT bulletin (VDE-CERT) lists specific FW cutoffs.

The vendor's 9.8 CRITICAL rating is fair and we are not downgrading it. This is a *backdoor-class* weakness (CWE-912 is literally the 'hidden functionality / backdoor' category) on a component whose *canonical deployment role* is inside an OT cell — the exact class my ruleset floors at CRITICAL. The only reason we don't score higher than 9.4 is the practical reality that most WAGO field gear lives behind a Purdue L2/L3 boundary, so the exploitable population from the public internet is small. That's not immunity; that's a delayed timer.

"Backdoor-class diagnostic on OT field gear — segmentation buys you time, not immunity. Floor is CRITICAL because the target IS the crown jewel."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker reaches the OT cell network

The attacker needs L2/L3 adjacency to the WAGO I/O Field bus segment. In real breaches this comes from a compromised engineering workstation, a jump host, a poorly-segmented IT↔OT firewall rule, a contractor VPN, or a wireless bridge left in maintenance mode. Tools: nmap -sn across the OT VLAN, or a Cobalt Strike SMB pivot from the compromised HMI.
Conditions required:
  • Foothold in IT or DMZ with a route into OT
  • OT segment not strictly ISA/IEC 62443 zoned
Where this breaks in practice:
  • Well-run plants enforce unidirectional gateways or data diodes between IT and OT
  • Most WAGO I/O Field devices are not internet-reachable — Shodan/Censys counts for exposed WAGO modules are in the low thousands globally
Detection/coverage: Nozomi Guardian, Claroty CTD, Dragos Platform will flag lateral movement into the ICS zone; IT-side EDR (CrowdStrike, SentinelOne) catches the pivot host
STEP 02

Wait for or force a device reboot

The diagnostic activates *during the initial startup sequence*, so the attacker must either observe an operational reboot or induce one. Induction vectors: a coordinated power event, a Modbus/EtherNet-IP flood that trips a watchdog, or abusing a legitimate firmware-update endpoint. Weaponized helper: plcscan, modscan, or a custom Scapy script hammering EtherNet-IP CIP encapsulated PDUs.
Conditions required:
  • Ability to induce reboot OR patience across a scheduled maintenance window
Where this breaks in practice:
  • Forcing a PLC-adjacent reboot is noisy and typically causes process alarms
  • OT change-control windows are rare and monitored by control engineers
Detection/coverage: SIEM/Historian will see the availability blip; process alarm floods on the DCS console
STEP 03

Speak to the diagnostic service

During the boot window the hidden diagnostic exposes a service (per the network-vector CVSS, likely a TCP listener, possibly UDP-broadcast discovery). The attacker connects with the diagnostic protocol — expect a proprietary framed protocol; researchers will publish PoCs on GitHub within weeks (watch pentestpartners/wago-*, Nozomi/ot-plc-tools).
Conditions required:
  • Network reachability during the boot window (seconds to minutes)
Where this breaks in practice:
  • Boot windows are short — if the diagnostic auto-closes after normal-run handoff, attacker must race
Detection/coverage: PCAP capture on the OT tap; Nozomi/Claroty passive DPI will alert on unknown protocol handshakes
STEP 04

Abuse diagnostic to read/write process state or firmware

Diagnostic backdoors of this class historically expose memory read/write, config dump (including credentials), or firmware replacement. Impact ranges from silently altering setpoints (Stuxnet-class) to bricking the device to flashing malicious firmware for persistence. Tool: attacker's own protocol client once reversed.
Conditions required:
  • Diagnostic protocol reverse-engineered (public PoC or in-house RE)
Where this breaks in practice:
  • Skillset — OT-capable adversaries are a smaller pool (SANDWORM, XENOTIME, VOLTZITE); commodity ransomware crews rarely reach this rung
Detection/coverage: Anomalous config writes visible in engineering-station logs; process deviation on DCS trends
03 · Intelligence Metadata

The supporting signals.

CVECVE-2026-4769
CWECWE-912 — Hidden Functionality (backdoor-class weakness)
Disclosure2026-07-13 (WAGO / VDE-CERT coordinated)
Vendor severityCRITICAL 9.8CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In-the-wild*No confirmed exploitation as of 2026-07-13*. Not on CISA KEV. OT-capable threat actors (SANDWORM, VOLTZITE) historically prioritize this class of finding — expect intel reports within 90 days
Public PoCNone yet. Watch VDE-CERT advisory, Nozomi Labs, Team82 (Claroty), Pentest Partners for follow-on write-ups
EPSSNot yet scored (CVE < 72h old). Expect low initial percentile (<20) rising as PoCs land
ExposureShodan / Censys: WAGO-branded services are typically single-digit thousands globally; System I/O Field subset is smaller still. Vast majority sit behind OT segmentation, not directly on the internet
Affected products*Certain devices in the WAGO System I/O Field series* — WAGO PSIRT advisory should be consulted for exact ordering codes and firmware ranges
Fixed versionAwaiting WAGO firmware release — check WAGO Download Center and CERT@VDE
ReporterCoordinated via CERT@VDE (German ICS-CERT equivalent)
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to CRITICAL (9.4/10)

Verdict held at CRITICAL because the single most decisive factor is the deployment-role blast radius: CWE-912 hidden functionality *inside an OT field I/O module* is the textbook floor-CRITICAL case in the noisgate ruleset — the affected component IS the high-value role, no chaining required. Friction (OT segmentation, need to catch the boot window) shaves 0.4 off the vendor's 9.8 but cannot break the CRITICAL floor.

HIGH confidence in CWE class and role multiplier
MEDIUM confidence in exact exploitation mechanics — public PoC not yet available
MEDIUM confidence in affected version enumeration — vendor bulletin still maturing

Why this verdict

  • Role multiplier — OT field controller: the affected component is by definition an ICS/SCADA-adjacent I/O device; per noisgate policy, backdoor-class flaws in OT hardware are floored CRITICAL because the blast radius is process/safety impact, not just data
  • Backdoor semantics: CWE-912 is qualitatively worse than a typical memory-corruption CVE — it's *intended* code paths that shouldn't exist, meaning no memory-safety mitigation (ASLR, DEP, stack canaries) helps
  • Unauthenticated network vector confirmed by vendor CVSS — no credential, no user interaction, no local access required within the reachable segment
  • Downward pressure — segmentation reality: most WAGO field gear lives in Purdue L2, not on the internet, so raw exposed population is modest; this is why the score sits at 9.4 not 9.8
  • Downward pressure — boot-window timing: exploit requires the diagnostic to be active, likely only during startup; adversary must race or induce reboot

Why not higher?

We shaved 0.4 off the vendor 9.8 because the diagnostic is time-boxed to boot and the reachable population is constrained by standard OT segmentation. Without those two frictions we would agree with 9.8 exactly.

Why not lower?

This cannot be a HIGH. It's a backdoor-class flaw in an OT field device — the noisgate role-multiplier rule explicitly floors this at CRITICAL when the affected component is canonically an ICS controller, and 'requires internal access' does NOT break the floor without published installed-base evidence showing <1% of units are reachable, which we do not have.

05 · Compensating Control

What to do — in priority order.

  1. Enforce strict ISA/IEC 62443 zone & conduit segmentation around WAGO I/O Field devices — The exploit requires network reachability during boot. Ensure only whitelisted engineering workstations and PLCs on the same cell can talk to the I/O module — everything else drops at the OT firewall. Deploy within 3 days per the noisgate CRITICAL mitigation SLA.
  2. Enable passive DPI monitoring on OT taps — Point Nozomi Guardian, Claroty CTD, or Dragos at the affected cell's SPAN port and build a detection for unknown protocol handshakes to WAGO endpoints during boot windows. Within 3 days.
  3. Restrict and log all reboot / power-cycle events on affected devices — Since exploitation requires catching the boot window, any unscheduled reboot is a high-fidelity IOC. Wire device power state into the SIEM. Within 3 days.
  4. Inventory: identify every WAGO System I/O Field module by part number and firmware — You cannot patch what you don't know you have. Pull from the CMDB, asset-inventory tool (Armis, Claroty xDome), and physical walkdowns. Within the 3-day mitigation window.
  5. Coordinate with WAGO PSIRT / CERT@VDE for firmware — Register for the advisory update stream so you receive fixed firmware notification immediately. Plan the patch drop into the next planned maintenance window inside the 90-day noisgate remediation SLA.
What doesn't work
  • Host-based EDR — these are embedded field devices, they don't run CrowdStrike/SentinelOne agents
  • IT-side WAF or NGFW rules — the exploit path is inside the OT segment; a north-south WAF sees nothing
  • Disabling remote management on the HMI — the vulnerable listener is on the WAGO device itself, not on the engineering station
  • Standard vulnerability scanning (Tenable, Qualys) — active scanning against live OT I/O gear frequently causes process disruption; do not scan production PLCs to 'verify'
06 · Verification

Crowdsourced verification payload.

Run this from the auditor workstation or a monitoring host on the OT engineering VLAN with read-only network reach to the WAGO device. It performs a *passive banner check* only — no fuzzing, no writes. Invoke as python3 check_wago_4769.py 10.20.30.40 where the argument is the target IP. Requires Python 3.8+ and permission to open TCP sockets on that VLAN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# noisgate verifier for CVE-2026-4769 (WAGO System I/O Field diagnostic exposure)
# READ-ONLY: performs TCP connect + banner grab only. Does NOT send exploit traffic.
# Exit codes: 0 = PATCHED / not exposed, 1 = VULNERABLE (diagnostic reachable), 2 = UNKNOWN

import socket
import sys
import ssl

# Ports historically associated with WAGO diagnostic / management interfaces.
# Adjust once WAGO PSIRT publishes the exact diagnostic port for CVE-2026-4769.
CANDIDATE_PORTS = [80, 443, 2455, 6626, 11740, 44818]
TIMEOUT = 3.0


def probe(host: str, port: int) -> str:
    try:
        with socket.create_connection((host, port), timeout=TIMEOUT) as s:
            s.settimeout(TIMEOUT)
            try:
                banner = s.recv(256)
                return banner.decode(errors="replace").strip()
            except socket.timeout:
                return "<open-no-banner>"
    except (socket.timeout, ConnectionRefusedError, OSError):
        return ""


def main() -> int:
    if len(sys.argv) != 2:
        print("usage: check_wago_4769.py <target-ip>", file=sys.stderr)
        return 2

    host = sys.argv[1]
    hits = []
    for p in CANDIDATE_PORTS:
        b = probe(host, p)
        if b:
            hits.append((p, b))

    if not hits:
        # No management/diagnostic surface reachable => not exposed from this vantage
        print(f"PATCHED  {host}  no diagnostic listener reachable from this segment")
        return 0

    diag_markers = ("WAGO", "diag", "IO-Field", "boot")
    vulnerable = any(
        any(m.lower() in banner.lower() for m in diag_markers)
        for _, banner in hits
    )

    for port, banner in hits:
        print(f"  :{port}  banner={banner[:80]!r}")

    if vulnerable:
        print(f"VULNERABLE  {host}  diagnostic-class banner observed — confirm firmware")
        return 1

    print(f"UNKNOWN  {host}  listener present but no diagnostic marker; correlate with WAGO PSIRT bulletin")
    return 2


if __name__ == "__main__":
    sys.exit(main())
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: pull an inventory of every WAGO System I/O Field module in your plant and rank by process criticality. Per the noisgate mitigation SLA for CRITICAL, within 3 days you must (a) confirm ISA/IEC 62443 zone enforcement is blocking non-engineering hosts from reaching those devices, (b) turn on passive OT DPI (Nozomi/Claroty/Dragos) with a rule for boot-time unknown-protocol handshakes on WAGO endpoints, and (c) wire unscheduled reboots to the SIEM as high-priority IOCs. Then, per the noisgate remediation SLA for CRITICAL, schedule the WAGO firmware update into the next available maintenance window with a hard deadline of 90 days — do not skip the planned-outage process, and do not active-scan production PLCs to 'verify.' If active exploitation is reported before your window opens, the SLA collapses to *patch/mitigate within hours* regardless of change control.

Sources

  1. WAGO I/O System Field product page
  2. CERT@VDE advisory portal
  3. CWE-912: Hidden Functionality
  4. CISA ICS Advisory — WAGO Managed Switches
  5. Nozomi Networks — Vulnerabilities in WAGO PLCs
  6. OffSeq Threat Radar — CVE-2026-3587 (related WAGO CWE-912)
  7. CISA Known Exploited Vulnerabilities Catalog
  8. WAGO Download Center (firmware release notes)
Peer Review

What defenders are saying.

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

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.