Vulnerabilities

Zyxel GS1900 zero-day CVE-2026-107441 survived the June patch

Binarly finds the exploit used on 996 Zyxel GS1900 switches abuses a new flaw, CVE-2026-107441, that June’s fix missed. Patch to October firmware.

Illustration of a network switch with a warning symbol representing the Zyxel GS1900 zero-day CVE-2026-107441

An exploit used to raid almost 1,000 Zyxel GS1900 switches this summer still works on firmware that Zyxel shipped as the fix, because it targets a different flaw. Zyxel has now confirmed the bug as CVE-2026-107441 and released new firmware.

What happened

On 3 November 2026 Zyxel published a security advisory for an out-of-bounds write in the CGI program of its GS1900 series smart managed switches. The flaw, tracked as CVE-2026-107441, lets an unauthenticated attacker run operating system commands on the switch with a crafted HTTP request. On the same day firmware analysis firm Binarly, which reported the issue, released its own advisory (BRLY-2026-057) and a detailed write-up. Patched firmware has been available since 22 October.

What makes this matter is how the bug surfaced. Binarly was studying JITTERLY, a Linux backdoor that Acronis TRU had linked to attacks on Gitea servers. On one of the actor’s command servers it found an open directory holding an archive called gs1900_bundle.tar.gz. Inside was a PyArmor-obfuscated Python tool labelled “Zyxel GS1900 Pre-Auth RCE”.

That tool is the same one GreyNoise described in September, when it reported that an attacker had pulled configurations, network details and hashed root credentials from 996 GS1900 switches in 48 countries around 17 August. GreyNoise linked the activity to CVE-2026-7273, a flaw Zyxel had patched in June, and on 21 September that CVE entered CISA’s Known Exploited Vulnerabilities (KEV) catalogue. According to Help Net Security’s report on the GreyNoise research, 564 of the victim switches were still using factory default credentials.

Binarly’s findings change that picture. When it ran the exploit against the June firmware, every one of the ten releases sold as the CVE-2026-7273 fix was still vulnerable. Binarly told Zyxel on 29 September, and Zyxel confirmed the issue and reserved the new CVE in early October.

The technical picture

The bug sits in dispatcher.cgi, the program that handles HTTP POST requests to the switch’s web management interface. When it parses a request body, the code copies each key and value pair into a fixed global buffer with room for 140 parameters of 1,024 bytes each. In the vulnerable code, neither the length of each parameter nor the running parameter count was checked before the copy.

The parameter counter happens to sit in memory directly after that buffer. A long final parameter therefore overwrites the counter, and the next copy lands wherever the attacker points it. Binarly’s analysis shows that the captured tool uses this to redirect a library function to the system’s command runner, or alternatively to hijack saved registers on the stack. In either case the attacker gets command execution before any login check. The request needs no credentials, and the tool fingerprints the firmware and carries memory offsets for releases back to 2015.

The June update added a check on the counter, but only after the copy that corrupts it. Binarly says this left the exploit working unchanged. Zyxel told Binarly that CVE-2026-7273 had covered the missing counter validation, and that it treats the missing size check as a separate vulnerability, now CVE-2026-107441. The October firmware checks the counter before copying and limits each field to 511 bytes, which Binarly says closes the hole.

There is also disagreement over severity. Zyxel’s CVE record scores CVE-2026-107441 at 8.8 (CVSS 3.1) with an adjacent-network attack vector, the same rating it gave CVE-2026-7273. Binarly argues that because the attack is plain HTTP, all it needs is network reachability to the management service, and it scores the flaw 9.8 with a network attack vector. Binarly also believes the exploit was probably LLM-generated, an assessment not independently confirmed.

Timeline from Zyxel's June GS1900 patch, through the August attacks and Binarly's discovery, to the October fix and 3 November advisories

Why it matters for UK organisations

The GS1900 range is made for small and mid-sized networks. Help Net Security notes it is typically found in small offices, schools, hotels and shops. That is a large part of the UK economy, and also the part least likely to have someone checking switch firmware each month. None of the sources I reviewed breaks down the 996 compromised switches by UK location, so I would not assume British devices were spared.

The bigger lesson is about process. Many UK organisations, and the managed service providers that look after them, use CISA KEV as a prioritisation feed. Anyone who saw the September KEV entry, installed the June firmware and marked the job closed was still exposed for about a month, until the October release. Version-based vulnerability scanners would probably have reported those switches as patched. Binarly makes the same point: the KEV entry had no effect on this actor, because the actor was using a different bug.

Expert view

In my experience, switches are the most neglected devices on internal networks. Firewalls get attention; access switches get installed, configured once and left alone for years, often with the management web interface open on every VLAN. When we test small business networks, a switch admin page reachable from staff or guest wireless is depressingly common.

Zyxel’s “adjacent” rating gives some comfort. If the management interface is only reachable from inside the network, an outsider cannot hit it directly. But once someone is inside the network, the barrier is low. A phished laptop, a compromised IoT device or an exposed jump host all provide the foothold this exploit needs, and GreyNoise’s numbers show hundreds of these switches were reachable.

The patch history worries me more than the bug. A misdescribed flaw followed by an ineffective fix damages trust in the whole patch cycle. The answer is not to stop patching, but for high-value kit, verifying a fix deserves the same rigour as applying it.

What to do now

  1. Patch to the October firmware. Install 2.90(xxxx.3)C0 for your model (for example 2.90(AAHL.3)C0 on the GS1900-24). Any build ending .2)C0 or earlier is vulnerable, including the June “fix”. This maps to the Cyber Essentials security update management control.
  2. Treat exposed switches as possibly compromised. If a GS1900 was reachable from untrusted networks before you patched, assume its configuration and credential hashes may have been taken. Rotate the admin passwords and any RADIUS or SNMP secrets it held, and check the configuration against a known-good copy.
  3. Lock down management access. Limit the web interface to a dedicated management VLAN or named admin hosts, and never expose it to the internet. This covers the firewalls and secure configuration controls.
  4. Remove default credentials. GreyNoise’s figures show default passwords were widespread among the victims. Replace them with unique, strong credentials held in a password manager.
  5. Check your inventory. Ask your MSP or reseller which GS1900 models you have and what firmware they run. Scanner results that rely only on version numbers should be checked again in this case.
  6. Hunt for known indicators. Check firewall and DNS logs against the indicators GreyNoise and Binarly have published.

Bottom line

This is an exploited, pre-authentication code execution bug in a common small business switch. It escaped its first patch and was being used in the wild before it had its own CVE. If you run GS1900 switches, install the October firmware now, take the management interface off user networks and change the passwords. And when a KEV entry and a release note say you are safe, verify it where it counts.

Sources

Related Posts