Zyxel GS1900 needs a second fix after root flaw remained exposed

At a glance

What this is: NHI Mgmt Group's analysis, drawing on SOCRadar's report: Zyxel's GS1900 switches needed a second firmware fix because the earlier patch left a zero-day path to unauthenticated root command execution.

Why it matters: This matters because network devices with web management interfaces often sit outside normal patch discipline, yet they can expose root access, configuration data and adjacent network control when remediation is incomplete.

By the numbers:

• Zyxel listed 10 GS1900 switch models that needed the Patch 3 firmware.

Context

A zero-day in a network switch is especially dangerous when the management interface is reachable from ordinary user networks or the internet. The problem is not only code execution, but the control plane exposure that lets an attacker turn a device into a foothold for configuration theft, credential harvesting and lateral visibility.

Patch sequencing failures are common when fixes address one validation step but leave the underlying parser or copy operation intact. In infrastructure gear, that kind of partial remediation can make a device look compliant while it remains exploitable, which is why switch hardening must include exposure review, not just version checks.

Key questions

Q: What should teams do first when a zero-day is disclosed before scanning can finish?

A: Start with the most current inventory data you already trust, then query that inventory for the affected CVE, package, or version. The priority is to answer exposure status before the window for exploitation widens. If the feed is stale or the inventory is incomplete, treat the result as advisory rather than authoritative.

Q: Why does incomplete firmware remediation leave network switches exposed?

A: Incomplete firmware remediation leaves network switches exposed when the vulnerable code path remains reachable after a partial update, rollback, or failed patch. If the unsafe parser path is still present, an attacker can send crafted management traffic to trigger code execution or denial of service, especially where the device accepts unauthenticated or weakly authenticated input.

Q: How does an out-of-bounds write lead to root command execution on devices?

A: An out-of-bounds write can overwrite adjacent memory on a device, corrupt control data, and redirect execution into attacker-controlled code. On network equipment, that can turn input sent through management interfaces into root command execution if the flaw reaches privileged firmware or a system process running with elevated rights.

Q: What signs suggest a managed switch has been compromised?

A: Signs of a compromised managed switch include unexpected configuration changes, new or altered local accounts, unusual management sessions, modified ACLs or VLAN settings, and firmware integrity mismatches. You may also see traffic being mirrored, redirected, or dropped without an approved change, or logs showing access from unknown admin sources.

Technical breakdown

Why the GS1900 web management path was exploitable

The vulnerable surface sat in the switch's CGI handler, which processed HTTP parameters for the web management interface. The core problem was unsafe handling of parameter count and size inside a fixed storage area. When the handler copied an oversized parameter, it could corrupt adjacent memory and change control flow before any later check had a chance to stop it. That is a classic out-of-bounds write, but here it was exposed through an administrative interface rather than a public web app. See the CWE Top 25 Guide.

Practical implication: Treat switch management interfaces as attack surfaces that need exposure minimisation and version-specific validation, not just patch deployment.

How an attacker moved from parameter overflow to command execution

The exploit path depended on overwriting the parameter counter and using the next write to redirect execution. In practical terms, the attacker did not need authentication, only network reachability to the management service. Once execution shifted to attacker-chosen logic, the switch could run commands with root privileges, which turns a parser bug into full device control. That makes the weakness more than a crash condition, because it enables configuration theft and persistent device abuse.

Practical implication: Confirm that management endpoints are isolated from user and internet networks, and assume unauthenticated parser bugs can become root-level device compromise.

Why Patch 2 left a usable exploit path

Patch 2 introduced a counter check, but it ran after the oversized copy had already occurred. That ordering matters: a validation step that executes after memory corruption cannot prevent the overwrite that sets up exploitation. Patch 3 changed the sequence by checking first and limiting the copy itself, which closes the exploit path rather than just detecting part of it. This is the difference between partial remediation and true input-boundary enforcement.

Practical implication: Verify that firmware fixes change control flow before any unsafe copy or parse step, because post-copy validation does not eliminate exploitation.

Threat narrative

Attacker objective: The attacker objective was to gain root-level control of the switch and extract configuration and credential material for follow-on access.

1. Entry came through a reachable GS1900 web management interface where an unauthenticated attacker could submit crafted HTTP parameters.
2. Credential_harvested phase followed when the exploit dropped a script that collected switch configuration data, hashed root credentials and network information.
3. Impact occurred when the attacker retained the output on-device for later retrieval and used root-level command execution against the switch.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Partial patching creates remediation debt: A fix that closes one validation flaw but leaves the same parsing path reachable does not end exposure. In this case, the vendor's June firmware reduced risk but did not remove the exploit condition, so the device remained a live target after administrators believed it was patched. The broader lesson is that configuration devices need fix validation, not just update deployment.

Management-plane exposure is the decisive control gap: The exploit only becomes operational when the switch management interface is reachable from untrusted networks. That makes network segmentation, management VLAN design and interface reachability part of vulnerability management, not a separate hardening task. Without that boundary, a single parser bug can become a root compromise event.

Root credential handling is part of incident response, not only hygiene: The campaign collected hashed root credentials and configuration data, which means exposed credentials may already be in hostile hands even after firmware is replaced. Teams should treat any reachable GS1900 as a potential identity and access compromise on the device, not simply a software maintenance issue.

Configuration integrity is the real post-exploit question: Once a switch can be commanded as root, the main risk shifts from the vulnerability itself to altered access rules, VLANs and management paths. That means the repair task is not only patching, but proving that the device's control plane still matches the intended network design. In identity terms, the device behaves like a privileged machine identity with standing access that must be revalidated.

Read next: Zero-Day and Exploited Vulnerabilities Guide

What this signals

Management-plane compromise: This case shows how a web admin interface becomes the real attack surface when it sits on the same network as everyday users. The operational implication is that patch management and network segmentation have to be treated as one control problem, because a fixed version that remains reachable is still a security exposure.

For device fleets, the next governance step is to move from version compliance to exposure compliance. A switch can report the right firmware while still presenting an exploitable interface, so asset discovery, management VLAN design and post-patch verification need to be checked together before teams assume the issue is closed.

The identity angle is easy to miss: when a switch stores or reveals root credentials, it behaves like a privileged machine identity with its own lifecycle and blast radius. That means device rebuild criteria, credential rotation triggers and configuration attestation should all be part of the response playbook.

For practitioners

• Install the exact Patch 3 build for each affected model Update every GS1900 variant listed by the vendor, including devices already moved to Patch 2, because the earlier firmware did not close the exploitable path.
• Restrict web management to a dedicated admin network Remove the management interface from user and internet reachability, and confirm that only approved administration paths can reach the switch.
• Rotate any exposed root credentials immediately Replace factory-default and shared passwords, then rotate the root password on switches that were reachable before remediation because hashed credentials were among the collected data.
• Audit switch configuration drift against known-good baselines Compare current VLANs, port settings, management access rules and account lists with approved backups to detect silent changes that could persist after patching.
• Rebuild devices that were exposed to untrusted hosts If a switch was reachable from untrusted networks since the exploit window opened, reset and reconfigure it rather than assuming firmware repair alone removed compromise.

Key takeaways

• The GS1900 issue is not just a software flaw, but a management-plane exposure problem that allows unauthenticated command execution when controls are misplaced.
• The campaign against nearly 1,000 switches showed that incomplete remediation can leave devices exploitable even after administrators believe they have patched them.
• Operators need to pair firmware upgrades with network isolation, credential rotation and configuration verification, because patch status alone does not prove device integrity.

Related NHI Mgmt Group resources: Zero-Day and Exploited Vulnerabilities Guide · Emergency Out-of-Band Patching Playbook · Zero-Day Exploitation Playbook · Memory Corruption Vulnerabilities Guide

Key terms

• CVE-2026-107441: A newly tracked vulnerability identifier for the GS1900 issue that allowed unauthenticated command execution through unsafe parameter handling. It represents the zero-day condition that remained exploitable after the earlier firmware fix and required a separate Patch 3 remediation.
• Out-of-Bounds Write: An out-of-bounds write occurs when software writes data outside the bounds of an allocated memory region. In security terms, it is a memory-safety failure that can corrupt state, crash a process, or create conditions for deeper compromise depending on the code path.
• Zero-Day Vulnerability: A zero-day vulnerability is a security flaw unknown to the software vendor or defenders, leaving no official patch or mitigation at the time it is discovered or exploited. Attackers can use it immediately against systems, applications, or devices, often before detection, making rapid monitoring and containment critical.
• Management Interface: A management interface is the administrative access point used to configure, monitor, or control a system. These interfaces are sensitive because they often expose high-privilege functions. If they are reachable from the internet, a vulnerability can become much easier to exploit and much harder to contain.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect privileged device access to broader identity and access controls.