CSIPE

Published

- 17 min read

A Patched Zyxel Switch Still Needs a Trust Reset

Network Security Patch Management Incident Response Vulnerability Management

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

A switch can pass traffic all day while quietly losing the information that defines who may manage it. The ports stay green. Users keep working. Nothing on the front panel says that a stranger copied the configuration and the root password hash.

That is the useful lesson in this week’s Zyxel news. On 21 September 2026, GreyNoise reported that an attacker had exploited CVE-2026-7273 and extracted sensitive data from 996 Zyxel GS1900 smart managed switches in 48 countries. The stolen material included device configurations, network information, and hashed root-level credentials. GreyNoise also found factory-default credentials on 564 of the affected devices (GreyNoise: Open Season on Kapibala).

The vulnerability already had a repair. Zyxel published fixed firmware for ten supported GS1900 models on 16 June 2026, three months before the exploitation report (Zyxel: GS1900 stack-based buffer overflow advisory). The US Cybersecurity and Infrastructure Security Agency added the flaw to its Known Exploited Vulnerabilities catalogue on 21 September and set 24 September as the deadline for covered federal agencies (CISA: Known Exploited Vulnerabilities catalogue).

Installing that firmware is urgent. It is also only the first half of the response. A patch stops the known route into the switch. It does not make a copied configuration private again, change a password whose hash left the device, remove an account an intruder added, or prove that the management interface is now reachable only from the places you intended. After reported data theft, the job is patch, reset trust, and collect a receipt.

What happened, with the dates kept straight

CVE-2026-7273 is a stack-based buffer overflow in the web-management program used by affected GS1900 switch firmware. In plain English, a specially formed web request can make that program overwrite memory it should not touch. Zyxel says an attacker on the local network can exploit the flaw without logging in and potentially run operating-system commands on the switch.

Zyxel disclosed the vulnerability and its patches on 16 June 2026. The advisory lists ten affected models, from the GS1900-8 through the GS1900-48HPv2, with a separate fixed firmware build for each model. For example, the GS1900-24 is affected through 2.90(AAHL.1)C0 and fixed in 2.90(AAHL.2)C0. The exact suffix matters. A generic statement such as “we run version 2.90” cannot distinguish the affected build from the repaired one.

GreyNoise says the campaign reached the switches on or about 17 August 2026. Its researchers recovered an obfuscated Python program from the attacker’s infrastructure and found that the program explicitly targeted GS1900-24 firmware versions 2.10 through 2.90. The tool also exposed options for adapting memory addresses to other firmware. That technical detail does not prove every supported model was used in the observed campaign, so inventory should follow the vendor’s affected-model table rather than a broad guess about the whole product family.

The reported outcome was data theft, not merely scanning. GreyNoise says the attacker staged and retrieved configurations, networking information, and hashed root credentials from 996 switches. The devices were spread across 48 countries, with the largest reported counts in Italy, the United States, Taiwan, France, and South Korea. Help Net Security independently reviewed the report and the vendor advisory on 22 September, including the 996-device count, the stolen material, and CISA’s response deadline (Help Net Security: Attacker compromised nearly 1,000 Zyxel switches).

CISA’s entry supplies a second important date. It added CVE-2026-7273 to the Known Exploited Vulnerabilities catalogue on 21 September 2026, marked forensic triage as required for covered agencies, and set a 24 September due date. A catalogue entry means CISA has evidence of exploitation somewhere. It does not mean every affected switch was breached, nor does the public entry identify all victims.

Those limits matter. GreyNoise’s figures describe what it observed through its sensor network and access to adversary infrastructure. They are not a complete census of every vulnerable switch. The withheld attacker address also means a public indicator search cannot give every operator a clean yes-or-no answer. Treat the report as evidence that the flaw moved from possible to used, then examine your own devices and records.

Why a “local network” flaw still crossed 48 countries

The vendor describes this as a LAN-based vulnerability. That phrase is easy to misread as “safe unless the attacker is in the building.” A local-area network is a reachability condition, not a statement about physical distance. Remote access software, an exposed management address, a compromised workstation, a vendor tunnel, a flat guest network, or another infected device can place an attacker on a route that behaves like the local management network.

A managed switch sits at an awkward point in that model. It connects the devices that may later attack it. Staff laptops, wireless access points, cameras, tills, printers, building systems, servers, and contractor machines may all send traffic through the same hardware. If the management interface listens where ordinary clients can reach it, one compromised endpoint can become the required “LAN-based” attacker.

The public campaign also shows why you should verify the path rather than debate the label. GreyNoise reports successful extraction from devices in 48 countries. The report does not publish the complete route into every switch, and the exact attacker address remains withheld for operational reasons. We therefore cannot say from the public evidence that all 996 management pages were openly reachable from the internet. We can say that the attacker’s infrastructure reached them well enough to run the exploit and retrieve data.

That distinction should shape the response. Do not assume direct internet exposure without evidence. Do not dismiss the event because a diagram puts management on an internal subnet. Test what can actually connect to the interface from user networks, wireless networks, remote-access paths, monitoring systems, and vendor support routes.

A switch often outlives the network design around it. An administrator enables web management during installation. Years later, a firewall rule expands, two networks are bridged, a temporary support virtual private network becomes permanent, or an acquired office inherits a broad management range. The intent remains “admins only” while the effective route becomes “any device in three buildings.”

The practical control is a small management zone with a short allowlist. Ordinary users and guests should not be able to open the switch’s web interface. Monitoring should read only what it needs. Administration should come from named systems or a controlled jump host. If a vendor tunnel exists, its route, identity, and expiry belong in the same review.

That setup does not remove the need to patch. Segmentation can fail, and an approved administrator machine can be compromised. It does change the number of machines that get a chance to exercise a management flaw. A security boundary earns its name only when a connection test proves it.

The configuration is a map of the network

A switch configuration can look boring until you ask what an intruder learns from it. Names reveal sites and business functions. Virtual local-area network definitions show which groups of devices are separated. Trunk ports show where traffic travels next. Management addresses identify other infrastructure. Authentication, logging, time, monitoring, and remote-management settings describe how the device is watched and who is expected to control it.

That information shortens future reconnaissance. An attacker no longer has to infer the network one packet at a time. The configuration may point toward servers, cameras, phones, payment devices, wireless controllers, or administrative systems. Even when it contains no reusable secret, it can explain which routes are valuable and which controls the operator believes are present.

Hashed credentials need equally careful language. A password hash is a derived value used to check whether a future password attempt is correct, rather than the plaintext password itself. A strong, unique password stored with a suitable modern scheme may resist guessing for a long time. A short, reused, or default password may fall much faster, especially if the format allows offline guesses.

GreyNoise reports that 564 of the 996 victims had factory-default credentials. That does not mean every stolen hash was cracked, and the public report does not say that every device used the same credential format. It does show that default credential handling was common in the observed set. A password that never changed after installation should be treated as exposed without waiting for proof that someone converted its hash back to readable text.

Reused administrator passwords widen the damage. If the same password controls another switch, wireless controller, firewall, or support portal, changing it on the patched device leaves the other doors open. The relevant unit is the credential’s reuse set, not the single appliance that disclosed it.

Configurations can carry other forms of authority too. Depending on how a device was set up, backups may contain community strings, remote authentication settings, monitoring destinations, certificates, keys, or references to external services. Do not assume those fields exist on every GS1900. Export the known-good configuration, inspect the settings your organisation actually uses, and rotate secrets that were present or credibly derivable.

The right response is therefore a trust reset, not a ritual password change. List the accounts and secrets that the device knew. Find where each one also works. Replace defaults and reused values. Review remote authentication and support access. Issue fresh keys or certificates where the copied configuration exposed them. Record the old value’s retirement rather than merely creating a new one.

Patching closes one route, not the earlier exposure window

A firmware update changes what the switch will run next. It does not answer what happened between 16 June, when the repair became available, and the moment your device completed the update. GreyNoise places the observed exploitation around 17 August. If a switch remained on an affected build through September, its exposure window includes that campaign date.

Start the record before making changes where operationally safe. Capture the model, serial or asset identifier, running firmware, uptime, management address, configuration checksum, account list, remote-access settings, and the networks that can reach management. Preserve central authentication, firewall, network-flow, configuration-management, and monitoring records covering the affected period. A screenshot of the version page is useful, but it cannot carry the whole incident.

Some evidence lives on the device and may change during an update or reset. Other evidence sits outside it and is harder for a compromised appliance to rewrite. That outside view matters because command execution on network infrastructure weakens confidence in local logs. Firewall records, authentication servers, network monitoring, administrator workstation histories, and configuration archives can corroborate or challenge what the switch reports.

Do not build the entire decision around one attacker address. GreyNoise withheld an exact address due to victim sensitivity and operational risk. It may publish more later, but a negative search today proves only that the available records contain none of the indicators you checked. It cannot prove that the switch kept its configuration private.

Compare the current configuration with a trusted earlier version. Look for new accounts, changed management ranges, altered remote logging, unfamiliar monitoring destinations, new services, unexpected name or time servers, modified virtual networks, and ports whose role changed without a ticket. Explain every security-relevant difference instead of staring at thousands of lines without a question.

A matching configuration is reassuring but incomplete. An attacker may have read data without changing settings. That is exactly why credentials and secrets still need a reset when evidence places the device in the affected set or when the exposure cannot be bounded. Confidentiality loss can leave no persistent configuration difference.

If there is evidence of command execution or unexplained administrative change, rebuilding from trusted firmware and a reviewed configuration gives stronger assurance than trying to clean an unknown state in place. Exporting the current configuration and immediately restoring it can preserve an attacker’s change. Use a known-good baseline, review each necessary difference, and follow Zyxel’s supported recovery process for the exact model.

Availability still matters. A switch may carry phones, cameras, payment terminals, wireless access points, or production equipment. An improvised reset can create an outage larger than the incident. Prepare the fixed firmware, backup path, console access, replacement hardware if required, approved configuration, rollback decision, and maintenance window before touching a critical device. Urgent does not mean careless.

Model and firmware proof beat a spreadsheet tick

The Zyxel advisory is refreshingly specific. It lists ten models, the last affected build for each, and the corresponding repaired build. That table should become the acceptance test.

The model name must match exactly. GS1900-24, GS1900-24E, GS1900-24EP, and GS1900-24HPv2 are different entries with different firmware identifiers. A family-level inventory entry such as “Zyxel 24-port switch” is not enough to select a file safely. Read the device label and management page, then reconcile both with the asset record.

The firmware string must also match the model. Zyxel’s fixed builds share the pattern 2.90(... .2)C0, but the letters inside the parentheses vary by product. Copying the repaired string from another model can produce a false report even if the device refuses the wrong image. Save the vendor table row used for the decision.

Unsupported or unlisted hardware needs a separate branch. Zyxel says on-market products not listed in the table are unaffected, but that sentence does not certify every retired device someone may still operate. If an old model falls outside vulnerability support and the vendor does not provide a clear repair statement, do not turn uncertainty into “not affected.” Ask the vendor or replace the device according to its support status and business role.

A successful upload is not the final receipt. Confirm that the switch restarted into the intended build. Reconnect through the approved management path. Verify that traffic forwarding, virtual networks, trunks, link aggregation, power delivery, spanning tree, time, logging, monitoring, and authentication behave as expected for that site. Then query the running firmware again.

The post-change record should connect four facts: this exact asset is an affected model; this exact fixed image came from the vendor; the device is now running that image; the management and trust review was completed. Without all four, a green patch dashboard can hide an old build, a wrong asset, a failed restart, or a stolen credential that still works elsewhere.

A practical response sequence

The following sequence is deliberately defensive and vendor-led. It avoids exploit testing against production equipment. You do not need to reproduce the attack to prove that a device was exposed or to close the known weakness.

  1. Freeze the scope. Build a list of every GS1900 device from asset records, monitoring, network maps, purchasing records, and physical site checks. Record the exact model, serial number, site, owner, management address, running firmware, and support status. Reconcile duplicates and devices that no longer answer.

  2. Match each device to the vendor table. Use Zyxel’s 16 June 2026 advisory to identify the affected and fixed build for that exact model. Save the relevant row or advisory revision with the change ticket. Do not reduce the decision to a comparison against the number 2.90.

  3. Map real management reachability. From representative user, guest, server, wireless, remote-access, monitoring, and administrator networks, test whether the management service can be reached. Record the result. Remove broad routes and public exposure, then restrict administration to a small approved path.

  4. Preserve the earlier window. Before updating, collect the running state and the evidence your incident plan requires. Save central authentication, firewall, configuration, network, and monitoring records from at least the period in which the device ran the affected build, with particular attention to the reported activity around 17 August 2026.

  5. Install the model-specific fixed firmware. Obtain the image through Zyxel’s official support route and follow the vendor instructions for the exact device. Plan console access and rollback for critical sites. Do not download firmware from a link in an unsolicited message, even when the message cites the correct CVE.

  6. Prove the fixed build is active. After restart, query the running firmware and compare the complete string with the advisory. Check that the device remained in the intended configuration and that the network functions it carries recovered. A completed change job is not evidence that the switch booted the new code.

  7. Review and rebuild trust. Compare the configuration with a trusted baseline. Remove unknown accounts and unnecessary services. Replace default and reused administrator passwords everywhere they work. Rotate configuration-held secrets or certificates when exposure warrants it. If the device shows credible compromise, rebuild from trusted firmware and a reviewed configuration rather than blessing the current state.

  8. Close with an outside receipt. Attach the final model, firmware, configuration checksum, account review, credential rotations, reachability test, monitoring status, evidence location, exceptions, and named owner. Keep unsupported or unreachable devices open until they are replaced, isolated, or otherwise resolved.

This is more work than clicking “upgrade,” but most of it should already exist in a healthy network practice. Inventory, controlled management routes, configuration backups, central logs, unique credentials, and post-change verification are ordinary controls. The campaign simply reveals what happens when they are treated as optional paperwork.

Small organisations may not have a security operations team. They can still apply the model. The person or provider who manages the network should produce a short before-and-after record: device label, old and new firmware, backup date, management access rule, changed administrator credential, and confirmation that logging still works. If the provider cannot state which fixed build is running, the work is not finished.

Managed-service customers should ask precise questions. Which listed models do you operate for us? What firmware was active on 17 August and what is active now? Could client or guest networks reach management? Was our configuration among the reported thefts? Which credentials or configuration secrets were rotated? What evidence supports the answer? “We patched” covers only one of those questions.

Make the next appliance update cheaper

Network appliances often receive less engineering attention than servers because they look fixed-purpose. They have firmware, web applications, accounts, certificates, logs, dependencies, and support deadlines. They also sit on paths that many other systems trust. Treating them as silent boxes creates exactly the kind of blind spot this incident exposes.

Put firmware and support state into the asset inventory. Collect the running version automatically where the product permits it. Alert when configuration changes outside an approved window. Send logs and authentication events somewhere other than the device. Test the management allowlist from both permitted and forbidden networks. Store reviewed configuration backups where a switch compromise cannot rewrite them.

Unique administrative credentials are basic but decisive here. A copied hash should force one credential change, not a hunt across twenty appliances to learn where the same password was reused. A password manager, named administrator accounts where supported, and remote authentication with strong controls reduce the size of the reset. Remove factory defaults during commissioning and test that they no longer work.

Replacement belongs in patch management too. Hardware that no longer receives vulnerability fixes is not merely old; it creates an exception every time a new flaw appears. Keep the support end date beside the purchase date, assign a replacement owner, and budget before the final advisory. Emergency procurement is an expensive way to discover a lifecycle policy.

The larger lesson reaches beyond Zyxel. A firewall, wireless controller, storage appliance, management console, or hypervisor can lose sensitive state before an update arrives or before a team installs it. The repair prevents the next use of a known flaw. The incident response determines whether old authority still survives outside the repaired box.

That is the line to keep from this story. Patch the affected GS1900 switch now, using the exact build in Zyxel’s table. Then assume the data reported stolen remains stolen. Reset the trust that data carried, narrow the management path, and save proof from outside the device.

A switch that forwards packets is available. A switch whose firmware, configuration, credentials, and management boundary have all been checked is trustworthy enough to return to service. Those are different standards, and this week’s 996-device report is a good reason to stop confusing them.

If you want more calm, practical security explanations, the newsletter sends one email per month. The signup is on this site.

Sources