Zyxel Switches Say Patched. The Exploit Disagrees.

A Zyxel GS1900 switch running June's security fix could still hand an attacker control, if that attacker can reach its web management page. On 3 November 2026, Zyxel published an advisory crediting Binarly, the firm that found a real campaign's exploit still worked on that firmware. Check each client's GS1900 switches today, including those already marked as patched.

TL;DR

• Zyxel disclosed CVE-2026-107441 in GS1900 switches on 3 November 2026; Binarly calls it exploited as a zero-day, while Zyxel's advisory doesn't address exploitation.
• A client is exposed on any of ten GS1900 models with firmware ending .2C0 or earlier, June's fix included; read it in Maintenance > Firmware > Management.
• Export logs first, because a reboot erases the buffered log; then install the model's .3C0 build, change passwords and rerun the checks.
• GreyNoise counted 996 switches in 48 countries, 564 on default credentials, in a campaign it tied to the June flaw; configurations and hashed root credentials were taken.

What is CVE-2026-107441 and is it being exploited?

CVE-2026-107441 is an out-of-bounds write (writing past allotted memory) in the GS1900's web management program; Zyxel says an unauthenticated attacker could run operating system commands. Binarly says the exploit was used in the wild, but according to The Hacker News, neither GreyNoise nor Binarly says the hacked switches ran June's fix.

CISA, the US cyber agency, added the June flaw, CVE-2026-7273, on 21 September 2026 and set a due date of 24 September 2026 for federal agencies. CISA has not listed CVE-2026-107441 as of this writing; recheck the catalog.

The US database NVD lists 8.8 out of 10 and Zyxel says "LAN-based"; according to The Hacker News, Binarly rates it 9.8 and says network reachability is enough.

Which Zyxel GS1900 switches are affected?

Ten models are affected, and Zyxel says unlisted products aren't. Treat any route to the management page as exposure.

Fixed builds from Zyxel's advisory.

How do I check if my clients are exposed to the Zyxel GS1900 zero-day?

Check 2 settles exposure; the rest look for signs of a break-in. These switches are appliances, not Linux servers, so console paths run on the switch and commands run on your own analysis machine, in one shell. Hunt from 7 May 2026, the earliest activity GreyNoise attributes to this actor, using the client's SIEM or firewall archive, since on-device logs cover far less. GreyNoise's published hashes aren't tied to the switch script, so a hash check isn't possible there, and a clean result doesn't rule out an earlier break-in.

1. Preserve evidence. In Maintenance > Configuration > Backup, choose HTTP and save the running and startup configurations, flash log and buffer log, because a reboot erases the buffer log. Export firewall logs too. Pass: $D.sha256 lists all saved files.

   D="/srv/ir/gs1900-$(date +%F)"; sudo mkdir -p "$D"
   # exports: one subfolder per switch, plus the firewall log export
   sudo cp -a ~/gs1900-exports ~/fw-logs "$D"/
   sudo find "$D" -type f -exec sha256sum {} + | sudo tee "$D.sha256"
   

2. Read the firmware. Run Zyxel's ZON utility on the switch's broadcast domain to list model and firmware, or open Maintenance > Firmware > Management. Pass: the Active build ends .3C0, matching the table.

3. Test outside reachability. This covers ports 80 and 443 on the listed public addresses only, so use the client's asset inventory as the main list. Pass: both ports show filtered or closed, and each curl line ends 000.

   while read -r H; do
     nmap -Pn -p 80,443 "$H"
     for U in "https://$H/" "http://$H/"; do
       curl -sk -o /dev/null -w "$U %{http_code}\n" --max-time 10 "$U"
     done
   done < client-public-ips.txt
   

4. Check logins and changes. Try admin/1234, Zyxel's default, then review Configuration > Management > Users and Monitor > Management > Syslog for new admins or configuration changes. Pass: the default login is rejected and Users lists only expected names.

5. Search for published indicators. These come from GreyNoise, which doesn't tie the IPs to Zyxel specifically. A hit means contact with known attacker infrastructure: treat it as a likely compromise and escalate. Pass: no output.

   P='/tmp/info|/home/web/tmp/info\.txt|172\.245\.247\.21'
   P="$P|104\.225\.153\.141|74\.48\.66\.73|981666\.xyz"
   sudo find "$D" -type f -exec zgrep -EaH "$P" {} +
   

6. Look for the switch's outbound transfer. GreyNoise says the collector script arrived over TFTP, a simple file-transfer protocol, on port 6969. A hit needs review. Pass: no output.

   # put the client's switch addresses in SW
   SW='10\.0\.0\.2|10\.0\.0\.3'
   sudo find "$D" -type f -exec zgrep -EaH "($SW).*6969" {} +
   

How do I fix Zyxel GS1900 CVE-2026-107441 on client switches?

Install the firmware first, because new passwords don't help while the hole stays open.

1. Install the firmware. Download the GS1900 firmware update for that model from Zyxel's Patch 3 page, then upload the .bix to Active and Backup in Maintenance > Firmware > Upload and reboot. The wrong model's file may damage the switch. Pass: Management shows .3C0 on both images.

2. Remove footholds. According to The Hacker News, Zyxel's advisory doesn't say whether updating removes existing access. After any hit, use Maintenance > Configuration > Factory Default, rebuild settings by hand and open a Zyxel support case quoting both CVEs. Pass: Users lists only your names.

3. Rotate credentials. Configurations and hashed root credentials were taken, so change passwords in Configuration > Management > Users, selecting Encrypted, plus secrets under Configuration > AAA and SNMP community strings, the switch's monitoring passwords. Pass: logging in with the old password fails.

4. Hardening (agree with the client first). Under Configuration > Management > Remote Access Control, add a Permit profile for the admin subnet, then enable it; a wrong range locks you out. Pass: from outside that range, check 3's curl lines end 000.

5. Rerun the checks. Export fresh logs after the fix and rerun checks 2 to 6. Pass: all five checks meet their Pass lines.

Was this a CVE-2026-7273 patch bypass?

Zyxel treats CVE-2026-107441 as a separate flaw rather than a CVE-2026-7273 patch bypass, according to BleepingComputer, because the exploit also abused missing length checks. According to The Hacker News, Binarly found that June's counter check runs too late, and it offers two explanations: a faulty June fix, or attacks through a different flaw from the one CISA listed.

For partners, the distinction changes little. Admins who met CISA's September deadline installed firmware that, according to BleepingComputer, Binarly found the exploit still worked against.

• 16 June 2026: Zyxel fixes CVE-2026-7273.
• About 17 August 2026: GreyNoise dates the switch attacks.
• 21 September 2026: GreyNoise reports them; CISA lists the June flaw.
• 29 September 2026: Binarly reports to Zyxel, per BleepingComputer.
• 11 October 2026: Zyxel confirms the flaw, per BleepingComputer.
• 22 or 23 October 2026: Zyxel Patch 3 firmware ships; BleepingComputer says 22 October, Zyxel's release post says 23 October.
• 3 November 2026: Zyxel publishes its advisory.

According to The Hacker News, Binarly plans to publish a smaller proof of concept soon, so public exploit code may follow.

Where KinoSec fits

KinoSec's autonomous external network pentest checks whether each client's GS1900 web management page answers from the internet, and tests what an attacker could reach from the outside. That matters here because a version check would have marked these switches as patched. Each run ends in findings and remediation you can hand your client, based on what the test reached rather than what a changelog promised, and you can run it on demand after a patch window. It can also chain findings across web apps, networks and Active Directory, the kind of path a stolen network map helps an intruder plan. It tests from the outside, so the firmware read and log searches stay on your list.

Frequently Asked Questions

Does CVE-2026-107441 affect Zyxel switches outside the GS1900 series?

Zyxel's advisory lists ten GS1900 models and says products not listed are unaffected. Other Zyxel switches in a client's estate still need their own patch checks, but this CVE doesn't apply to them.

How do I check if my clients' Zyxel switches were hit?

First save the configurations and logs from Maintenance > Configuration > Backup, because a reboot erases the buffer log. Then test the switch's outside exposure with nmap -Pn -p 80,443 <client-public-ip>. Finally search exported logs with zgrep -Ea '981666\.xyz|/tmp/info' <exported-log>, using indicators from GreyNoise. A hit means contact with known attacker infrastructure: treat it as a likely compromise and escalate.

What if a client's switch can't be updated today?

Zyxel's advisory lists no workaround, so the firmware remains the only vendor fix. As a temporary measure, block ports 80 and 443 to the switch from all networks except the admin subnet, using the upstream firewall. Zyxel doesn't describe this as a mitigation, so schedule the update and confirm the Active build ends .3C0.

Does meeting a CISA deadline prove a client's device is safe?

No: a CISA due date tracks one named flaw, and here CISA's 24 September 2026 date covered CVE-2026-7273. According to The Hacker News, Binarly says the exploit worked unchanged on the firmware that fixed it. Record the build against the vendor's latest advisory, and retest reachability after patching rather than closing the ticket on the deadline.