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.
4 steps from start to impact.
Attacker reaches the OT cell network
nmap -sn across the OT VLAN, or a Cobalt Strike SMB pivot from the compromised HMI.- Foothold in IT or DMZ with a route into OT
- OT segment not strictly ISA/IEC 62443 zoned
- 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
Wait for or force a device reboot
plcscan, modscan, or a custom Scapy script hammering EtherNet-IP CIP encapsulated PDUs.- Ability to induce reboot OR patience across a scheduled maintenance window
- Forcing a PLC-adjacent reboot is noisy and typically causes process alarms
- OT change-control windows are rare and monitored by control engineers
Speak to the diagnostic service
pentestpartners/wago-*, Nozomi/ot-plc-tools).- Network reachability during the boot window (seconds to minutes)
- Boot windows are short — if the diagnostic auto-closes after normal-run handoff, attacker must race
Abuse diagnostic to read/write process state or firmware
- Diagnostic protocol reverse-engineered (public PoC or in-house RE)
- Skillset — OT-capable adversaries are a smaller pool (SANDWORM, XENOTIME, VOLTZITE); commodity ransomware crews rarely reach this rung
The supporting signals.
| CVE | CVE-2026-4769 |
|---|---|
| CWE | CWE-912 — Hidden Functionality (backdoor-class weakness) |
| Disclosure | 2026-07-13 (WAGO / VDE-CERT coordinated) |
| Vendor severity | CRITICAL 9.8 — CVSS: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 PoC | None yet. Watch VDE-CERT advisory, Nozomi Labs, Team82 (Claroty), Pentest Partners for follow-on write-ups |
| EPSS | Not yet scored (CVE < 72h old). Expect low initial percentile (<20) rising as PoCs land |
| Exposure | Shodan / 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 version | Awaiting WAGO firmware release — check WAGO Download Center and CERT@VDE |
| Reporter | Coordinated via CERT@VDE (German ICS-CERT equivalent) |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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'
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.
#!/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())
If you remember one thing.
Sources
- WAGO I/O System Field product page
- CERT@VDE advisory portal
- CWE-912: Hidden Functionality
- CISA ICS Advisory — WAGO Managed Switches
- Nozomi Networks — Vulnerabilities in WAGO PLCs
- OffSeq Threat Radar — CVE-2026-3587 (related WAGO CWE-912)
- CISA Known Exploited Vulnerabilities Catalog
- WAGO Download Center (firmware release notes)
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.