Zyxel GS1900 Unauthenticated Root RCE: Incomplete Patch Leaves Switches Exposed — Detection and Remediation Guide

If your organization runs Zyxel GS1900 series smart managed switches and you applied the vendor's earlier firmware fix (the 2.90 release train) believing you were protected against an actively exploited unauthenticated remote code execution flaw — you need to go back and patch again. Researchers at Binarly have confirmed that Zyxel's initial remediation was incomplete: the patched firmware still leaves the switches open to the same exploitation path attackers have been using in the wild.

The vulnerability allows anyone who can reach the switch's web management interface to execute arbitrary commands as root — without authentication. No credentials, no session token, no user interaction. Zyxel has now released corrected firmware for 10 GS1900 models that properly closes the hole.

This is a classic and dangerous pattern in vulnerability management: an incomplete vendor patch creates a false sense of security while the attack surface remains live. Organizations that patched early and checked the box are, in many cases, just as exposed as those that never patched at all. This post breaks down what happened, how to determine whether you're exposed, how to hunt for signs of prior exploitation, and the exact remediation steps to take now.

Technical Analysis

Affected Products

The flaw affects the Zyxel GS1900 series of smart managed Ethernet switches — a product line commonly deployed in SMB environments, branch offices, and as access-layer infrastructure in larger networks. Zyxel's corrected firmware release covers 10 GS1900 models. Organizations should consult Zyxel's official security advisory for the exact model and firmware version matrix applicable to their inventory.

Critically, the affected population includes devices that were already updated to the vendor's earlier fix — firmware version 2.90 and its associated builds. That patch did not fully neutralize the vulnerability, meaning "patched" devices remain exploitable until the newly released firmware is applied.

How the Vulnerability Works

From a defender's perspective, the attack chain is straightforward and severe:

1. Reachability is the only prerequisite. The attacker needs network access to the switch's HTTP(S) web management interface. In poorly segmented environments, this interface is reachable from user VLANs; in the worst cases, it has been exposed directly to the internet.
2. No authentication is required. The flaw permits command execution without any valid session or credentials, which means credential hygiene, MFA, and strong passwords provide zero protection against this specific vector.
3. Execution context is root. Commands run with the highest privilege on the device, giving an attacker complete control over the switch: configuration modification, credential harvesting from device memory, traffic interception or redirection, persistence via config manipulation, and pivoting into the management network.

A compromised access-layer switch is not a minor event. It is a foothold at Layer 2 with visibility into — and control over — the traffic of every endpoint connected to it. Attackers can mirror ports, alter VLAN assignments, disable port security, weaken or remove management ACLs, and use the device as a stealthy persistence point that almost no EDR stack will ever see.

The Incomplete Patch Problem

Binarly's finding highlights a failure mode every vulnerability management program must plan for: vendor fixes that address the reported exploitation vector without eliminating the underlying weakness. The 2.90-series fix apparently blocked or narrowed the known attack path without fully remediating the root cause, leaving the devices exploitable through the same general mechanism.

Practical implication: your asset and patch records are now unreliable indicators of risk for this product line. Any GS1900 showing firmware 2.90 in your CMDB must be treated as vulnerable until the corrected build is confirmed.

Exploitation Status

The vulnerability has been described as actively exploited — this is not a theoretical or PoC-only issue. Attackers have used this flaw in the wild, and the incomplete patch means the exploitation window never actually closed for organizations running the earlier fix. Network edge and infrastructure devices from multiple vendors have been under sustained attack through 2025 and 2026, and unmanaged or semi-managed switches with exposed web interfaces are a recurring target class. Defenders should assume opportunistic scanning for reachable GS1900 management interfaces is ongoing.

Detection & Response

Embedded switches are notoriously difficult to instrument — you cannot deploy an EDR agent to a GS1900. Effective detection therefore relies on three pillars: syslog/CEF ingestion from the devices into your SIEM, network-layer monitoring of management-plane traffic, and post-compromise behavioral hunting on the endpoints and infrastructure behind the switch.

Hunting priorities:

• Management-plane exposure: Identify every source IP that has touched a GS1900 web interface (typically TCP 80/443 on the switch's management IP). Any source outside a defined set of admin workstations/jump hosts is suspect.
• Post-exploitation command artifacts: Exploitation of a root RCE on a switch frequently manifests as configuration changes, new administrative accounts, unexpected reboots, or firmware/config uploads — events that should appear in device syslog if logging is enabled and forwarded.
• Egress from the switch itself: A compromised switch generating outbound connections (to non-NTP/DNS/Zyxel update destinations) is a high-fidelity indicator. Switches should initiate almost no outbound traffic.
• Downstream host compromise: If a switch was used as a pivot, look for ARP anomalies, unexpected gateway behavior, and lateral movement from the switch's management IP toward internal hosts.

SIGMA Rules

---
title: Zyxel GS1900 Web Management Interface Access From Non-Administrative Source
id: 8f2c1d4e-6a7b-4c9d-b1e2-9a3f5c7d8e01
status: experimental
description: Detects HTTP/HTTPS connections to Zyxel GS1900 switch web management interfaces originating from hosts outside the designated administrative management subnet. Unauthenticated RCE exploitation of GS1900 switches requires only reachability to the web UI, making any non-administrative source accessing the management plane a high-priority hunting lead.
references:
  - https://thehackernews.com/2026/11/zyxel-gs1900-patch-fails-to-block-zero.html
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/11/15
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: firewall
  product: network
detection:
  selection_dst_port:
    DestinationPort:
      - 80
      - 443
  selection_switch:
    DestinationIp|cidr:
      - '10.0.99.0/24' # REPLACE: your switch management subnet / management VLAN
  filter_admin:
    SourceIp|cidr:
      - '10.0.10.0/28' # REPLACE: admin jump hosts / NOC subnet
  condition: selection_dst_port and selection_switch and not filter_admin
falsepositives:
  - Network scanners and inventory tools run by IT
  - Monitoring platforms performing HTTP health checks against switch UIs
level: high
---
title: Network Device Syslog Indicates Configuration Change or New Administrator Account
id: 3b9e7a12-5d4f-4e8a-9c2b-1f6d8a0e4b77
status: experimental
description: Detects syslog messages from network infrastructure devices indicating configuration modification, new user account creation, or privilege changes. Post-exploitation activity on compromised switches (including via unauthenticated root RCE such as the Zyxel GS1900 flaw) commonly involves persistence through configuration changes or rogue administrative accounts.
references:
  - https://thehackernews.com/2026/11/zyxel-gs1900-patch-fails-to-block-zero.html
  - https://attack.mitre.org/techniques/T1136/
  - https://attack.mitre.org/techniques/T1098/
author: Security Arsenal
date: 2026/11/15
tags:
  - attack.persistence
  - attack.t1136
  - attack.t1098
logsource:
  category: syslog
  product: linux
detection:
  selection_device:
    Host|contains:
      - 'gs1900'
      - 'switch'
      - 'zyxel'
  selection_events:
    Message|contains:
      - 'configuration changed'
      - 'config modified'
      - 'user added'
      - 'account created'
      - 'new user'
      - 'admin privilege'
      - 'password changed'
      - 'startup-config'
  condition: selection_device and selection_events
falsepositives:
  - Scheduled legitimate administration by network engineers (tune by time window and source admin account)
  - Automated configuration management platforms (Ansible, RANCID, Oxidized) backing up or pushing configs
level: high
---
title: Unexpected Outbound Connection From Network Switch Management IP
id: 6d1f8c33-2a9e-4b5d-8f7c-4e3a0b6d9c55
status: experimental
description: Detects outbound network connections initiated by network switch management IP addresses to destinations other than expected infrastructure (NTP, DNS, vendor update servers). Managed switches should initiate almost no outbound sessions; egress from a switch IP is a strong post-compromise indicator consistent with root-level code execution on the device.
references:
  - https://thehackernews.com/2026/11/zyxel-gs1900-patch-fails-to-block-zero.html
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/11/15
tags:
  - attack.command_and_control
  - attack.t1071
logsource:
  category: firewall
  product: network
detection:
  selection_source:
    SourceIp|cidr:
      - '10.0.99.0/24' # REPLACE: your switch management subnet
  filter_expected:
    DestinationPort:
      - 53
      - 123
  condition: selection_source and not filter_expected
falsepositives:
  - Vendor firmware update checks (whitelist Zyxel update destinations explicitly)
  - Syslog forwarding and SNMP polling responses misclassified as outbound sessions
level: critical

KQL — Microsoft Sentinel / Defender

The following queries assume you are ingesting switch syslog via a collector (CEF/Syslog into the Syslog or CommonSecurityLog tables) and firewall flow data. Adjust the management subnet placeholder to your environment.

// Hunt 1: Any host reaching GS1900 web management interfaces from outside the admin subnet
let SwitchMgmtSubnet = "10.0.99.0/24";   // REPLACE with your switch management range
let AdminSubnet = "10.0.10.0/28";        // REPLACE with admin jump-host range
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where ipv4_is_in_range(DestinationIP, SwitchMgmtSubnet)
| where DestinationPort in (80, 443)
| where not(ipv4_is_in_range(SourceIP, AdminSubnet))
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), ConnectionCount = count()
    by SourceIP, DestinationIP, DestinationPort, DeviceAction
| sort by ConnectionCount desc;

// Hunt 2: Switch syslog events indicating command execution, config change, or account creation
Syslog
| where TimeGenerated > ago(30d)
| where Computer has_any ("gs1900", "zyxel", "switch") or HostIP has "10.0.99"  // tune to inventory
| where SyslogMessage has_any ("configuration changed", "user added", "account created",
     "password changed", "login successful", "shell", "command", "firmware", "reboot")
| project TimeGenerated, Computer, HostIP, Facility, SeverityLevel, SyslogMessage
| sort by TimeGenerated desc;

// Hunt 3: Outbound sessions originating from switch management IPs (post-compromise egress)
let SwitchMgmtSubnet = "10.0.99.0/24";   // REPLACE with your switch management range
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where ipv4_is_in_range(SourceIP, SwitchMgmtSubnet)
| where DestinationPort !in (53, 123) and not(ipv4_is_private(DestinationIP))
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Sessions = count()
    by SourceIP, DestinationIP, DestinationPort, ApplicationProtocol
| sort by Sessions desc;

// Hunt 4: Endpoint-side follow-on — lateral movement sourced from a switch management IP
let SwitchMgmtSubnet = "10.0.99.0/24";   // REPLACE with your switch management range
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where ipv4_is_in_range(RemoteIP, SwitchMgmtSubnet) == false
| where LocalIP has "10.0.99"            // connections where the switch IP is the initiator, if visible via mirrored traffic/NVA sensor
| summarize by LocalIP, RemoteIP, RemotePort, InitiatingProcessFileName, TimeGenerated;

Velociraptor VQL

Velociraptor cannot run on the switch itself, but it is valuable for hunting the administrative workstations and jump hosts that manage these switches — both to find attacker tooling used against the switches (scanners, exploit scripts, curl/POST artifacts in shell histories) and to detect compromise of the admin plane that could be used to reach the management interfaces.

-- Hunt administrative endpoints for evidence of interaction with switch management
-- interfaces and exploitation tooling targeting network devices

// Artifact 1: Processes on admin hosts targeting switch management IPs/ports
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(gs1900|zyxel|10\\.0\\.99\\.)'   -- REPLACE regex with your mgmt subnet
   OR CommandLine =~ '(?i)(curl|wget|invoke-webrequest|iwr).*:(80|443|8080)'
   OR Name =~ '(?i)(nmap|masscan|nuclei|hydra|medusa)'

// Artifact 2: Shell histories on admin Linux/macOS jump hosts referencing switch targets
SELECT FullPath, Size, Mtime,
       read_file(filename=FullPath) AS HistoryContent
FROM glob(globs=['/home/*/.bash_history', '/root/.bash_history', '/Users/*/.zsh_history'])
WHERE HistoryContent =~ '(?i)(gs1900|zyxel|10\\.0\\.99\\.|/cgi-bin/|/cmd|system\()'

// Artifact 3: Live network connections from admin hosts to switch management IPs
SELECT Pid, Name, Address, Port, RemoteAddress, RemotePort, State
FROM netstat()
WHERE RemoteAddress =~ '10\\.0\\.99\\.'    -- REPLACE with your mgmt subnet pattern
  AND RemotePort IN (80, 443, 8080)

Verification & Hardening Script

Because GS1900 switches are embedded devices, "remediation scripting" here means inventory, firmware verification, and exposure reduction across your fleet. The following Bash script audits which switches are reachable on their management interfaces and validates exposure; combine its output with your firmware inventory to drive the upgrade to Zyxel's corrected release.

#!/bin/bash
# Zyxel GS1900 exposure audit and management-plane hardening verification
# Run from a management jump host with network reachability to the switch fleet

MGMT_SUBNET="10.0.99.0/24"          # REPLACE: switch management subnet
ADMIN_SUBNET="10.0.10.0/28"         # REPLACE: authorized admin source range
REPORT="gs1900_exposure_audit_$(date +%Y%m%d).csv"

echo "switch_ip,http_open,https_open,reachable_from_nonadmin,notes" > "$REPORT"

echo "[*] Enumerating live hosts with web management exposed in $MGMT_SUBNET ..."
nmap -Pn -p 80,443 --open -oG - "$MGMT_SUBNET" | \
  awk '/Ports:/{split($2,a," "); ip=a[1]; http=($0 ~ /80\/open/) ? "open" : "closed"; https=($0 ~ /443\/open/) ? "open" : "closed"; print ip","http","https}' | \
while IFS=, read -r ip http https; do
  echo "[+] $ip  http=$http  https=$https"

  # Check whether the management UI is reachable from OUTSIDE the admin subnet
  # (run this section from a test host on a user VLAN to validate segmentation)
  nonadmin="unknown"
  if curl -sk --max-time 5 "http://$ip/" -o /dev/null -w "%{http_code}" | grep -qE "200|302|401"; then
    nonadmin="REACHABLE - investigate segmentation"
  fi

  echo "$ip,$http,$https,$nonadmin,verify firmware against Zyxel corrected release" >> "$REPORT"
done

echo ""
echo "[*] Audit complete: $REPORT"
echo ""
echo "=== NEXT STEPS ==="
echo "1. Cross-reference every discovered switch IP against your firmware inventory."
echo "2. ANY GS1900 on firmware 2.90.x or earlier fix builds = VULNERABLE. Upgrade to Zyxel's corrected firmware immediately."
echo "3. Restrict TCP 80/443 on switch management IPs to $ADMIN_SUBNET via ACL/firewall."
echo "4. Disable the HTTP interface where possible; enforce HTTPS-only management."
echo "5. Enable syslog forwarding on each switch and confirm events arrive in your SIEM."

# Optional: pull running firmware version via SNMP if enabled (requires snmpwalk + correct community)
# snmpwalk -v2c -c <community> <switch_ip> SNMPv2-MIB::sysDescr.0

Remediation

1. Identify every GS1900 in your environment. Do not rely solely on your CMDB — actively scan for reachable management interfaces. Switches are frequently deployed outside formal asset management (closets, branch offices, lab networks).

2. Treat firmware 2.90 as vulnerable. The earlier fix is confirmed incomplete. Any GS1900 running the earlier patched build must be upgraded to the newly released corrected firmware. Download firmware only from Zyxel's official support portal and verify against the model-specific advisory covering the 10 affected GS1900 models. Consult Zyxel's security advisories page (https://www.zyxel.com/global/en/support/security-advisories) for the exact corrected version per model.

3. Remove management interface exposure — this is the compensating control that matters most. The vulnerability requires only reachability to the web UI. Until (and after) patching:

   • Place switch management interfaces on a dedicated, ACL-restricted management VLAN.
   • Permit management traffic only from named admin jump hosts/NOC subnets.
   • Never expose switch management interfaces to the internet. Scan your external attack surface now to confirm none are reachable.
   • Disable the web UI entirely if you manage via CLI/SNMP, and disable HTTP in favor of HTTPS-only where the UI is required.

4. Hunt before you patch, and preserve evidence. Because the flaw was actively exploited and the earlier patch never closed it, assume a possible dwell time measured in months. Before upgrading firmware (which may destroy volatile evidence), capture current configurations, running processes where accessible, syslog archives, and account lists. Compare current configs against known-good backups: look for unexplained admin accounts, altered ACLs, new port-mirroring (SPAN) sessions, changed SNMP communities, and modified VLAN assignments.

5. Rotate credentials if compromise is suspected. Any credentials stored on or transiting a potentially compromised switch — SNMP communities, RADIUS/TACACS+ keys, admin passwords — should be rotated.

6. Enable and verify logging. Forward syslog from every managed switch to your SIEM and confirm arrival. A switch with no logs is a blind spot an attacker will find before you do.

7. Fix the process gap. Add a step to your vulnerability management workflow: for critical infrastructure flaws, track vendor advisories through to confirmation of complete remediation, not just initial patch release. Incomplete patches — as this case demonstrates — are common enough that "patch released" must never automatically mean "ticket closed."

Conclusion

The Zyxel GS1900 situation is a textbook example of why vulnerability management cannot end at "vendor patch applied." An incomplete fix for an actively exploited, unauthenticated root RCE means organizations that did everything right on the first advisory are still exposed today. The corrected firmware is available for 10 affected models — deploy it urgently, restrict management-plane reachability as a durable compensating control, and hunt for signs of exploitation that may predate the patch. On network infrastructure, there is no agent to save you; visibility, segmentation, and disciplined patching are the defense.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub