What happened

Zyxel has released firmware for its GS1900 series switches that fixes CVE-2026-107441, an out-of-bounds write in the CGI program behind the web management interface. According to Zyxel's advisory, published on November 3, 2026, an unauthenticated attacker can send a crafted HTTP request and potentially execute operating system commands. The advisory describes a LAN-based attacker; BleepingComputer describes it as an attacker with network access, so the real exposure depends on where the management interface is reachable from in your environment.

The timeline matters. Zyxel patched an earlier pre-authentication buffer overflow, CVE-2026-7273, on June 16, 2026. From around August 17, GreyNoise observed a suspected Chinese-speaking actor it tracks as Kapibala exploiting GS1900 switches, and reported 996 compromised devices in 48 countries. The attackers ran commands, then downloaded a script that collected device configuration, hashed root credentials and network information. When GreyNoise disclosed the campaign on September 21, it attributed the activity to CVE-2026-7273, and CISA added that CVE to its Known Exploited Vulnerabilities catalog the same day.

Binarly later analysed an exploit recovered from attacker infrastructure and concluded it targeted a different, previously unknown flaw. According to reporting, the exploit specifically checked for firmware versions that had been patched for CVE-2026-7273, and Binarly confirmed on September 28 that it still worked against all ten of those firmware releases. Zyxel shipped new firmware on October 22 that limits parameter sizes and validates the parameter count before copying data into memory.

Why it matters

Two things stand out. First, a vulnerability record can be correct about the product and wrong about the bug: teams that marked CVE-2026-7273 as remediated in June had, in practice, not closed the exploited path. Second, switches are a blind spot. They usually have no endpoint agent, limited logging, and management interfaces on flat networks. A compromised switch gives an attacker a position to observe traffic and to hold credentials that may be reused elsewhere.

The stolen data is also reusable. Hashed root credentials and configuration files can reveal VLAN layouts, SNMP communities, management addresses and sometimes credentials for neighbouring systems.

What defenders should check

  • Inventory every GS1900 model in the estate, including closets and branch sites. Zyxel's advisory lists ten affected models, from the GS1900-8 to the GS1900-48HPv2.
  • Compare running firmware against the November 3 advisory. The fixed builds are the .3 releases, for example 2.90(AAHH.3)C0 for the GS1900-8. A build from the June fix, the .2 releases, is still vulnerable.
  • Confirm who can reach the switch web interface. It should be limited to a dedicated management network or jump host, never the internet.
  • Check for devices with default or shared admin passwords and change them.
  • Search internet exposure of your own ranges using Shodan or Censys filters scoped to your organisation, and review results for switch web banners.

Detection ideas

The following are starting points to adapt and test in your own environment. They are not production-ready rules.

Proxy or firewall logs that record URLs, looking for requests to the CGI endpoints named in public analysis (dispatcher.cgi, httprestorecfg.cgi and httpupload.cgi) from unexpected sources:

index=network (url="*dispatcher.cgi*" OR url="*httprestorecfg.cgi*" OR url="*httpupload.cgi*")
| stats count min(_time) max(_time) by src_ip, dest_ip, url

Flow data for switches that talk outward. A switch should rarely initiate connections to the internet:

CommonSecurityLog
| where SourceIP in (switch_mgmt_ips)
| where DeviceAction != "deny"
| where not(ipv4_is_private(DestinationIP))
| summarize count(), make_set(DestinationPort) by SourceIP, DestinationIP

On any host that can see management traffic, a quick grep over web or proxy logs works too:

grep -E 'dispatcher\.cgi|httprestorecfg\.cgi|httpupload\.cgi' /var/log/proxy/access.log

Also alert on configuration backups or restores on the switches that nobody scheduled.

Investigation

If a switch was reachable and ran an affected build, treat it as potentially compromised. Collect, in this order:

  • The running and startup configuration, then diff against your last known-good backup for new users, changed SNMP settings, port mirroring and altered management ACLs.
  • Syslog and any available web or authentication logs, plus upstream firewall and NetFlow records for the switch IP covering at least the period since August 17.
  • Outbound connections from the switch to unfamiliar hosts, which may point to the download of the collection script described in public reporting.
  • A forensic image or firmware dump if the vendor or your response team can provide one, before factory resetting, so that evidence is preserved.

Because the attackers collected hashed root credentials, rotate the passwords for the switch and for any other system that shared them.

Mitigation

  • Install the October 22 firmware or later on every GS1900 switch, following the model table in Zyxel's November 3 advisory.
  • Restrict the web management interface to a trusted admin network and disable it where it is not needed.
  • Change all default and shared credentials, and rotate any that touched an exposed switch.
  • Forward switch syslog to a central collector so that the next incident is visible.
  • Add network gear to the vulnerability management process with its own patch verification step, not just a CVE checkbox.

If you need help assessing whether network devices in your environment were compromised, our team offers compromise assessment and incident response services.

Sources: Zyxel security advisory for CVE-2026-107441 (November 3, 2026) and reporting by BleepingComputer on the exploitation timeline, which cites GreyNoise and Binarly research.