Pricing Contact Case Studies Research Talk to a Pentester ↗
POCFORGE RESEARCH 4 MIN READ Threat intel

Zyxel GS1900 switches: zero-day CVE-2026-107441 was behind the 996-switch compromise, and the June patch did not stop it

Attackers compromised 996 Zyxel GS1900 switches in 48 countries from around mid-August 2026. The activity was first blamed on CVE-2026-7273, fixed in June, but Binarly found the exploit worked against the June firmware by abusing a separate flaw, now CVE-2026-107441. Zyxel shipped fixed firmware in late October and published its advisory on 3 November. If you patched in June and stopped there, your switches may have stayed exposed until late October.

What changed

  • 16 June 2026: Zyxel fixed CVE-2026-7273, a pre-authentication buffer overflow in GS1900 switches.
  • From around 17 August: GreyNoise saw a suspected Chinese-speaking actor it tracks as Kapibala exploiting GS1900 switches, compromising 996 devices across 48 countries and collecting configuration files, hashed root credentials and network information. GreyNoise linked Kapibala to the Red Heron campaign.
  • 21 September: GreyNoise disclosed the campaign and attributed it to CVE-2026-7273; CISA added CVE-2026-7273 to its Known Exploited Vulnerabilities (KEV) catalogue the same day.
  • 28 September: according to BleepingComputer’s reporting of Binarly’s findings, Binarly, investigating Red Heron infrastructure, recovered the exploit and confirmed it still worked against all ten firmware releases patched for CVE-2026-7273.
  • 11 October: Zyxel confirmed a separate vulnerability and assigned CVE-2026-107441.
  • Late October: fixed firmware released. 3 November: Zyxel advisory published.

What the vulnerability is

Zyxel describes CVE-2026-107441 as an out-of-bounds write in the CGI program of the GS1900 web management interface that could let an unauthenticated attacker on the LAN execute OS commands with a crafted HTTP request. The GitHub Advisory Database entry for the CVE (GHSA-c73h-2jmc-4mfp) rates it CVSS 3.1 8.8 (High), with an adjacent-network attack vector. In practice, any network segment that can reach the switch’s web management page is the exposure, and in the observed campaign that included devices reachable from the internet.

We are not publishing technical exploitation details. The defensive point is simple: the June fix was incomplete for this attack, so June firmware is not a safe state.

Who is affected

Ten GS1900 models. Upgrade to the “.3” build for your model:

Model Vulnerable (and earlier) Fixed
GS1900-8 2.90(AAHH.2)C0 2.90(AAHH.3)C0
GS1900-8HP 2.90(AAHI.2)C0 2.90(AAHI.3)C0
GS1900-10HP 2.90(AAZI.2)C0 2.90(AAZI.3)C0
GS1900-16 2.90(AAHJ.2)C0 2.90(AAHJ.3)C0
GS1900-24 2.90(AAHL.2)C0 2.90(AAHL.3)C0
GS1900-24E 2.90(AAHK.2)C0 2.90(AAHK.3)C0
GS1900-24EP 2.90(ABTO.2)C0 2.90(ABTO.3)C0
GS1900-24HPv2 2.90(ABTP.2)C0 2.90(ABTP.3)C0
GS1900-48 2.90(AAHN.2)C0 2.90(AAHN.3)C0
GS1900-48HPv2 2.90(ABTQ.2)C0 2.90(ABTQ.3)C0

Source: Zyxel advisory, 3 November 2026. Models not listed are stated by Zyxel to be unaffected.

What to do now

  1. Inventory every GS1900 switch, including ones in branch offices and small sites that are often forgotten, and compare firmware against the table above.
  2. Install the “.3” firmware for each model. Do not treat the June (CVE-2026-7273) firmware as fixed.
  3. Take the web management interface off the internet and off user, guest and IoT networks. Put switch management on a dedicated management VLAN reachable only from admin hosts.
  4. Assume credential exposure on any switch whose management page was reachable from untrusted networks between August and your upgrade: the campaign collected configuration files and hashed root credentials. Change the admin password, and rotate anything stored in the configuration, such as SNMP community strings, RADIUS/TACACS+ shared secrets and any reused passwords.
  5. For switches that were internet-reachable, consider a factory reset and clean reconfiguration from a known-good baseline rather than trusting the running state.
  6. Review logs and NetFlow for unexpected outbound connections from switch management IPs, and for configuration downloads you cannot explain.

How to verify

  • Firmware version in the web UI or CLI matches the “.3” build for the model.
  • External scan confirms the management interface is not reachable from the internet.
  • Internal check confirms it is only reachable from the management VLAN.
  • Credentials and shared secrets have been rotated, and the change is recorded.

The wider lesson

A KEV listing and a vendor patch told defenders the problem was solved, and for this exploit it was not. When an edge or network device is under active attack, recheck the vendor advisory after the first fix, and restrict management planes regardless of patch status. A small switch is still a foothold with a view of your network.

Sources