Zyxel’s June switch update missed the flaw attackers used

The warning changed because the attack used a different flaw

NHS England’s national cyber operations centre issued an alert on November 5 for ten Zyxel GS1900 switch models. Its assessment was that further exploitation was likely. The agency pointed operators to model-specific firmware updates and drew attention to a detail that changes the response for anyone who patched in June. Binarly, the researchers who examined a recovered attack tool, say that tool still worked against the firmware that fixed the earlier flaw.

The two vulnerabilities have separate identifiers. Zyxel’s June 16 advisory assigned CVE-2026-7273 to a buffer overflow and listed the 2.90 Patch 2 firmware as the fix. The November 3 advisory assigns CVE-2026-107441 to a different memory-writing error. On the ten listed models, the November table treats Patch 2 and earlier as affected by this second flaw. Patch 3 is the fixed line listed for those devices.

Binarly dates the new firmware fix to October 22. Zyxel’s public community release note is dated October 23 and was edited November 3, when the vendor and Binarly published their advisories. The November 5 alert adds an independent operational assessment. The attack evidence and firmware fix predate the alert.

Source notes: 1, 2, 3, 5.

What the recovered exploit could establish

GreyNoise had already documented an August campaign against these switches. Its September report says data was taken from 996 devices across 48 countries, including 20 listed in Romania. The researchers saw configurations, networking information and hashed root credentials. That count describes the records GreyNoise analysed. It gives no estimate of the current installed fleet, the number of unpatched devices today or the firmware installed on each victim.

GreyNoise originally associated the attack with the June vulnerability. Binarly later found an exploit on infrastructure associated with the attacker and compared the program’s behaviour with the firmware. It says the recovered exploit still worked against all ten builds that addressed the June issue. The difference matters for administrators who saw the original warning, installed the recommended June build and closed the ticket.

Binarly’s analysis points to two different checks in the switch’s web-management software. One concerns how many fields are accepted. The other concerns how much data can be copied from an individual field. Patch 3 adds tighter checks that Binarly says stop the recovered exploit. The researchers tested firmware and analysed the tool. Their finding leaves the precise software history of individual compromised switches unresolved.

The strongest reading is narrow. The device population, the attack tool and the patched code are three pieces of evidence. GreyNoise provided a view of the affected devices. Binarly provided a test of the exploit against specific firmware. The November vendor advisory supplies a model-by-model list that operators can apply to their own equipment. None of those records can tell an individual owner that its switch was reached.

Source notes: 1, 2, 3, 4.

Find who can reach the management interface

Zyxel describes an attacker with access from the local network who can reach the management software and send a crafted web request without signing in. Binarly describes the consequence as command execution with root privileges. Both accounts put access to the management service at the centre of the risk. A switch can be protected from the public internet and still be reachable from a compromised workstation or another segment if the network permits it.

A management interface configures the switch. The switch also carries ordinary traffic, which does not mean every device can reach the management address. Review which networks and remote-access paths have permission to connect to that address. If the service is reachable from places that do not need it, restrict that access through controls you already manage and verify the restriction. Schedule the firmware update as a separate action.

Inventory and reachability can help set the order of work. An affected switch with a management page reachable from ordinary users warrants particular attention. A switch with restricted access still needs the model-specific update. Record the temporary restriction as a mitigation and keep the update open until you can verify the running version. This avoids turning a network access decision into an unsupported statement about the firmware.

Source notes: 1, 2, 3.

Verify the installed build and review possible exposure

Start with the label or inventory and the full running firmware string. The GS1900-24 and GS1900-24E are examples of names that look alike. Zyxel lists 2.90(AAHL.3)C0 for the GS1900-24 and 2.90(AAHK.3)C0 for the GS1900-24E. Use the official download for the exact model and confirm the new running build after the reboot. A downloaded file or a successful management-console upload is only one step in that check.

Plan the maintenance window around what depends on the switch, particularly if it supplies power to an access point or phone. Record the old and new versions and verify that the expected management access and normal traffic work after the update. Where the model or support status is unclear, ask the vendor before installing a file intended for a similar device.

Treat past exposure as a separate investigation. GreyNoise’s evidence includes data taken from devices, so an operator who finds suspicious access or unexplained configuration changes has reason to preserve relevant records and follow the organisation’s incident-response process. Installing the fix addresses the vulnerable code. It cannot establish whether credentials or configurations were copied before the upgrade.

A useful record therefore has two entries. One links the exact switch model and running build to the current advisory. The other tracks whether the network review or available logs revealed evidence that needs investigation. An earlier ticket for the June update answers a different question and is worth retaining as part of that history.

Source notes: 1, 2, 4, 6.