June Zyxel GS1900 Patch Can Still Be Hacked (CVE-2026-107441): Check Your Firmware

CVE-2026-107441 is an out-of-bounds write vulnerability in the Zyxel GS1900 switch admin web interface that allows an unlogged attacker to execute OS commands as root. The problem: the June firmware patch for CVE-2026-7273, which had already been exploited in nearly 1,000 switches, was apparently still bypassable with the same exploit.

If your office, school, internet cafe, or server room uses Zyxel GS1900 series switches, this article is for you. Below is a list of affected models, safe firmware versions, how to check, mitigations, and signs that a switch has been compromised.

What really happened?

The story has two acts. On June 16, 2026 Zyxel patched CVE-2026-7273, a buffer overflow in the GS1900 firmware CGI program. Zyxel's advisory states that this vulnerability can be used by attackers on a LAN without authentication to execute OS commands via specially designed HTTP requests.

Around August 17, GreyNoise started seeing attacks. One actor, allegedly speaking Mandarin, hacked 996 switches in 48 countries. Of that number, 564 devices still use factory default credentials. CISA added CVE-2026-7273 to its Known Exploited Vulnerabilities (KEV) catalog on September 21.

Second round: while exploring the “Red Heron” campaign infrastructure, Binarly researchers discovered an archive containing a Python exploit obfuscated with PyArmor. On September 28 they tested it and found that all ten firmware results from the June patch were still transparent. Zyxel confirmed the findings on October 11, assigned CVE-2026-107441, released new firmware on October 22, then issued an advisory on November 3.

Why can the June patch be skipped?

According to Binarly analysis quoted by BleepingComputer and Cryptika, the vulnerable code is in dispatcher.cgi, and the same pattern also appears in httprestorecfg.cgi and httpupload.cgi. The flow is something like this:

1. HTTP request parameters are stored in a fixed memory block containing 140 slots, each 1,024 bytes.
2. Data is copied to the slot before the slot count is checked.
3. A very long value in slot 139 overflowed and overwrote the parameter counter.
4. The counter going negative causes the next write to fall before the memory block, overwriting the function pointer, so the command runs as root.

The June patch did add an overflow check, but copying still happens before that check. The attacker simply breaks the counter first. The October 22 fix limits the parameter size and validates the number of parameters before data is copied.

There are two notes you need to know. First, Zyxel considers this a separate vulnerability, not just a bypass, because the exploit also abuses unvalidated parameter lengths. Second, it is not clear whether the exploit was intentionally created to skip patches or was targeting similar loopholes that were missed. BleepingComputer mentioned this openly.

How serious is it? This is a difference between sources

The CVSS scores are not uniform. Zyxel gave 8.8 assuming the attacker was on an adjacent network. Binarly considers the score too low because the gap can be reached via regular HTTP from any network that can access the switch. Some aggregators and media write 9.8, but WindowsForum notes that this number cannot be verified from official sources.

One more thing: the number 996 switches was reported for the CVE-2026-7273 campaign. There is no evidence yet that all the devices were compromised via CVE-2026-107441. However, because the same exploit penetrated the June firmware patch, even "updated" switches cannot be considered safe.

Which models are affected and which versions are safe?

There are ten GS1900 models. The June release firmware (ending .2) is still vulnerable. The safe version is .3. Models not listed are declared unaffected, and patches are only provided for models that are still in the security support window.

How do I check the switches on my network?

Starting from inventory. Many "smart managed" switches are installed once and then forgotten on the shelf. Practical steps:

• Note the exact model and firmware version running on each switch. The version is visible on the status page/dashboard of the web interface.
• Match with the table above. A suffix of .1 or .2 means still vulnerable.
• Check that the admin interface can be accessed from outside the management VLAN, let alone from the internet.

To find switches you forgot to log, scan the internal subnet of the admin machine (only on your own network):

# Cari perangkat dengan antarmuka web dan tampilkan judul halamannya
sudo nmap -p 80,443 --open -sV --script http-title 192.168.1.0/24 -oN scan-switch.txt

# Saring hasil yang menyebut Zyxel atau GS1900
grep -i -B6 -E "zyxel|gs1900" scan-switch.txt

Then make sure the admin interface is not open to the internet. From outside the network (for example VPS), check your office's public IP:

# Ganti 203.0.113.10 dengan IP publik kantor. Hasil "open" = perlu ditutup segera
nmap -Pn -p 80,443,8080,8443 203.0.113.10

What to do now?

1. Update to firmware .3 from the official Zyxel download channel for the respective models. Don't stop at the June release.
2. Restrict admin web access to only trusted management VLANs or IPs. This is general hardening, not an official Zyxel workaround; advisory does not list workarounds.
3. Change all default passwords. More than half of the victims of the previous campaign still used factory logins.
4. Assume exposed = probably hacked. The attacker steals the configuration and root credential hashes. Rotate admin passwords, check configuration (VLAN, port mirroring, new account), and when in doubt do a factory reset before installing new firmware.

If the router or firewall in front of the switch is Linux-based, this simple rule limits access to the switch management IP from only one admin subnet:

# 10.10.99.0/24 = subnet admin, 10.10.1.2 = IP manajemen switch GS1900
sudo iptables -I FORWARD -d 10.10.1.2 -p tcp -m multiport --dports 80,443 ! -s 10.10.99.0/24 -j DROP
sudo iptables -L FORWARD -n --line-numbers | head

How to detect signs of attack?

According to GreyNoise and Binarly, after getting the command executed, the attacker downloads the collection script via TFTP, then copies the stolen data to a folder that can be read via the web. The same actor also used the JITTERLY Linux backdoor (more than 30 commands) and the SIXZUT rootkit that can hide files, processes, and connections. This campaign has also been linked to WordPress and Gitea breaches.

What can be monitored:

• TFTP traffic (UDP 69) goes out from the switch management IP. Normal switches rarely do that.
• dispatcher.cgi HTTP request with very many or very long parameters from an unknown IP.
• Admin logins at odd hours or configuration changes that are not recorded.

Example of checking Linux firewall/syslog logs and matching suspicious file hashes on a Linux server with published IOCs:

# TFTP keluar dari IP switch (sesuaikan path log dan IP)
grep -E "SRC=10\.10\.1\.2 .*DPT=69" /var/log/kern.log

# Cocokkan hash SHA-256 file di direktori yang sering dipakai malware
cat > ioc.txt <<'IOC'
0f6e757e82c4d91df5bd249f775b9970b59dee42cc0dfe40f879d77fc16821c6
663a8088faca8e126a11648f5671fcf4eaf96435e10daf63a1d1b17d8385154c
82d072ab03d90c0131b06a576eadf2c986a51f0de986d50db4e49be01bf125cb
295133156b6a7d95b9c92f832f49e35235f1fbd3906e75c9202ef4cd65d1018c
64677002011bc2e4bc642a4154a20fdb95620ebd0144b98fc60f917901ec8b92
728810b07e911b235f6450e784391e39f68819a0a5d209662162916ffea25146
IOC
sudo find /tmp /var/tmp /dev/shm /usr/local/bin -type f -size -20M -exec sha256sum {} + 2>/dev/null | grep -F -f ioc.txt

The first three hashes belong to JITTERLY and the last three belong to SIXZUT, according to the list Cryptika quoted from Binarly. Because SIXZUT is a rootkit, an empty result from an infected server does not necessarily mean it is clean. To be sure, check from a separate boot media.

Teams managing multiple servers also need to ensure the web applications behind the network remain patched. Also see our guides on the WordPress 7.1.4 RCE flaw, Ivanti Connect Secure zero-day chain, and Node-RED being hacked without login.

FAQs

I updated the firmware in June. Is it safe?

Not yet. Firmware ending .2 from June is still vulnerable to CVE-2026-107441. You need to install release .3 which is released October 22, 2026.

My switch can only be accessed from the LAN. Is it still risky?

Yes. One malware-infected office computer or guest on unisolated Wi-Fi is enough to send a request to the switch. Restrict web admin to management VLAN only.

Is CVE-2026-107441 already in the CISA KEV catalog?

As of November 5, 2026, the sources we read only mention CVE-2026-7273 in the KEV catalog (as of September 21); For CVE-2026-107441 there is no information yet. However, exploits used in the field have been proven to penetrate the June firmware patch, so treat both as vulnerabilities under attack.

Are other Zyxel models such as the GS1200 also affected?

The Advisory only lists ten GS1900 models. Models not on the list are not affected by this loophole. Other series may have separate advisories, so keep an eye on the Zyxel security page.

What if my model is no longer supported?

Zyxel only patches models within the security support period. If your model does not get firmware .3, isolate the admin interface as tightly as possible and plan a device replacement.

Source

• BleepingComputer: Zyxel fixes zero-day exploit to hack nearly 1,000 network switches (Nov 4, 2026)
• WindowsForum: Zyxel GS1900 CVE-2026-107441, June Firmware Patch Still Vulnerable (4 Nov 2026)
• Cryptika: Hackers Exploit Zyxel GS1900 Zero-Day in the Wild (4 Nov 2026)
• Help Net Security: Attacker compromised nearly 1000 Zyxel switches since August (22 Sep 2026)
• Zyxel: Security advisory CVE-2026-7273 for GS1900 (Jun 16, 2026)
• Canadian Center for Cyber ​​Security: Zyxel security advisory AV26-603