Zyxel's GS1900 Firmware Fix Leaves Switches Open to Unauthenticated Root Command Execution
Network administrators running Zyxel GS1900 series switches should not assume they are protected after installing the vendor's earlier firmware fix: security researchers at Binarly found that the update does not block the exploit chain used against the underlying flaw, which was already being actively exploited, as reported by The Hacker News.
According to Binarly's findings, anyone with network reachability to a switch's web management interface can execute commands on the device without authenticating. Zyxel has since released new firmware covering ten GS1900 models that closes the hole.
The fix that only changed the version number
The earlier fix, firmware release 2.90, raised version numbers and refreshed the information shown in device dashboards, but the actual attack path remained intact — the unauthenticated command execution still worked. The available material does not explain why the earlier fix failed to block the observed exploit.
That gap is the editorial lesson for anyone managing switch fleets: a completed patch job in a spreadsheet is not the same as a verified mitigation. Version-number tracking alone would have marked these switches as remediated while they remained exploitable, which is why independent verification of a fix — rather than trusting the release notes — is increasingly treated as a distinct discipline in its own right.
Why this matters for small and medium network operators
GS1900 switches are common in small and medium-sized networks, where access switches are often treated as set-and-forget infrastructure. They frequently sit outside formal asset inventories, lack a defined patch cadence, and expose their management interfaces on the same segments users occupy — precisely the conditions this vulnerability rewards. It is a pattern familiar to many local IT teams running mixed-vendor access switches.
Verification checklist for network administrators
- Inventory first. Identify every GS1900 deployment and its current firmware version, including switches nobody remembers procuring.
- Confirm firmware beyond 2.90. Release 2.90 is not sufficient — it is the fix that demonstrably failed to block the exploit. Treat it as a do-not-stop-here marker and move to the newer release Zyxel has published for the affected models. Check Zyxel's official advisory and firmware download page for the exact CVE identifier and the per-model affected list, and confirm your hardware is covered.
- Test reachability yourself. Probe whether the web management interface is reachable from untrusted networks and from ordinary user VLANs, rather than assuming exposure based on network diagrams.
- If patching must wait, compensate at the network layer. Place management interfaces on a dedicated management VLAN, apply source-IP allowlists to HTTP/HTTPS administration, and block management protocols at the perimeter.
- Re-verify after upgrading. Given that a prior fix failed to disrupt the attack chain, validate that the new firmware actually closes the path on a sample device before rolling out fleet-wide.
When the patch is applied but the exploit path isn't
Because the exploit requires no login, application-level authentication offers no protection; only restricting who can reach the interface does. That makes the network-layer controls above the practical barrier for unpatched devices — and it is also why the re-verification step matters more than the upgrade itself.
The original GS1900 flaw was already being exploited in the wild before the first fix shipped, which raises the stakes for any switch left on 2.90. Devices that attacker tooling can reach silently, with no login and full command execution, are attractive targets on networks where nobody is watching the management plane. A patch record says the work is done; only a check that the exploit path is actually severed says the device is safe.
Operators should confirm details against Zyxel's advisory and the report published by The Hacker News.
Zyxel GS1900 韌體修補未能阻擋漏洞 交換機仍面臨未經身份驗證的 root 指令執行風險
正在使用 Zyxel GS1900 系列交換機的網絡管理員，不應以為安裝了廠商較早前的韌體修補程式便已受到保護：安全研究機構 Binarly 的研究人員發現，該更新並未阻斷針對底層漏洞——該漏洞此前已遭活躍利用——的 exploit chain，據 The Hacker News 報道。
根據 Binarly 的調查結果，任何能夠連線至交換機網頁管理介面的人，無須經過身份驗證即可在裝置上執行指令。Zyxel 其後已發布涵蓋十款 GS1900 型號的新韌體，堵塞了相關漏洞。
只改了版本號的修補
較早前的修補（韌體版本 2.90）只提升了版本號，並更新了裝置儀表板上顯示的資訊，但實際的攻擊路徑依然存在——未經身份驗證的指令執行仍然有效。現有資料並未解釋為何較早前的修補無法阻擋已觀測到的 exploit。
這個落差，對所有管理交換機機群的人來說是一個編輯層面的警示：在試算表上標記為完成的修補，並不等於已驗證的緩解措施。單靠版本號追蹤，只會將這些交換機標記為已修復，而它們實際上仍可被利用。正因如此，對修補進行獨立驗證——而非僅依賴 release notes——正日益被視為一門獨立的專業範疇。
為何中小型網絡營運商須留意
GS1900 交換機常見於中小型網絡，此類網絡往往將接入層交換機視為裝妥後便毋須理會的基礎設施。它們通常不在正式的資產清冊之內，缺乏明確的修補週期，並將管理介面暴露於用戶所在的同一網絡分段——這正好是該漏洞最能奏效的條件。這種模式，對不少運行多個品牌接入交換機的本地 IT 團隊而言，應不陌生。
網絡管理員驗證清單
- 先盤點資產。 識別所有 GS1900 部署及其當前韌體版本，包括那些已無人記得何時採購的交換機。
- 確認韌體版本高於 2.90。 版本 2.90 並不足夠——它正是已證實無法阻擋 exploit 的修補。應將其視為「不可止步於此」的警示，轉而升級至 Zyxel 為受影響型號發布的較新版本。請查閱 Zyxel 官方安全公告及韌體下載頁面，核對確切的 CVE 編號及各型號受影響清單，並確認你的硬件在涵蓋範圍之內。
- 自行測試連線可達性。 實際探測網頁管理介面是否可從不受信任的網絡及一般用戶 VLAN 連線到達，而非僅憑網絡拓撲圖假設其暴露情況。
- 若必須延後修補，則在網絡層作出補償。 將管理介面置於專用的管理 VLAN，對 HTTP/HTTPS 管理介面套用來源 IP 白名單，並在網絡邊界阻斷管理協議。
- 升級後再次驗證。 鑑於先前的修補未能中斷 attack chain，應先在一部樣本裝置上驗證新韌體確實封閉了相關路徑，然後才在整個機群推行。
修補已套用，但 exploit 路徑仍存
由於該 exploit 無須登入，應用層面的身份驗證並不能提供保護；只有限制誰能連線至該介面才有效。這使得上述網絡層控制成為未修補裝置的實際防線——也正因如此，重新驗證這一步比升級本身更為重要。
GS1900 的原始漏洞在第一個修補發布之前已遭野外利用（in-the-wild exploitation），這令任何仍停留在 2.90 的交換機風險大增。攻擊者工具可以悄然連線、無須登入便擁有完整指令執行能力的裝置，在無人監察管理平面（management plane）的網絡上，是極具吸引力的目標。修補紀錄只說明工作已完成；只有確認 exploit 路徑確實被切斷的檢查，才能說明裝置是安全的。
營運商應根據 Zyxel 的安全公告及 The Hacker News 發布的報告核實詳情。