CVE-2026-7273: Buffer Overflow in Zyxel GS1900 Switches
Active exploitation confirmed in CISA KEV.
Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-09-21. Federal agencies must patch by 2026-09-24.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-7273 |
| CVSS score | 8.8 High |
| Attack vector | LAN-based |
| Auth required | No |
| Patch status | Yes, vendor fixes released for affected GS1900 models |
TL;DR - Zyxel GS1900 series switches contain a stack-based buffer overflow in a CGI program. - Unauthenticated LAN attackers can send crafted HTTP requests and may achieve OS command execution. - Patch immediately and restrict switch management interfaces to dedicated admin networks.
What happened and why it matters
CVE-2026-7273 is a high-severity stack-based buffer overflow affecting Zyxel GS1900 series switches. NVD specifically names the GS1900-48HPv2, where firmware versions through 2.90(ABTQ.1)C0 are vulnerable. Zyxel’s own advisory expands scope beyond that single model and provides a patch matrix covering multiple GS1900 series devices, which is the source defenders should use for remediation decisions.
The operational concern is not just denial of service. Both NVD and Zyxel describe potential OS command execution via a crafted HTTP request. Because the attack is LAN-based and unauthenticated, the real-world risk depends heavily on whether switch web management is reachable from user VLANs, guest networks, contractor segments, or other lightly trusted internal hosts. In many environments, that condition is more common than teams expect, especially in branch offices, campus wiring closets, and SMB deployments where management plane segmentation is inconsistent.
A buffer overflow in a device CGI path also deserves attention because network appliances often sit outside normal endpoint visibility. If an attacker can reach the web interface and trigger memory corruption before authentication, traditional identity-based controls do not help. Even if exploitation is not currently confirmed, an unauthenticated management-plane flaw in switching infrastructure warrants fast inventory, validation, and upgrade action.
Affected products and fixed versions
Zyxel states the issue affects the GS1900 series and provides a model-by-model firmware matrix. For defenders, this vendor advisory is the authoritative source for patching scope. NVD’s summary is narrower, but that should not be treated as the full affected set when the vendor has published a broader remediation list.
The following versions are affected and fixed as published by Zyxel:
| Model | Affected version | Fixed version |
|---|---|---|
| GS1900-8 | 2.90(AAHH.1)C0 and earlier |
2.90(AAHH.2)C0 |
| GS1900-8HP | 2.90(AAHI.1)C0 and earlier |
2.90(AAHI.2)C0 |
| GS1900-10HP | 2.90(AAZI.1)C0 and earlier |
2.90(AAZI.2)C0 |
| GS1900-16 | 2.90(AAHJ.1)C0 and earlier |
2.90(AAHJ.2)C0 |
| GS1900-24 | 2.90(AAHL.1)C0 and earlier |
2.90(AAHL.2)C0 |
| GS1900-24E | 2.90(AAHK.1)C0 and earlier |
2.90(AAHK.2)C0 |
| GS1900-24EP | 2.90(ABTO.1)C0 and earlier |
2.90(ABTO.2)C0 |
| GS1900-24HPv2 | 2.90(ABTP.1)C0 and earlier |
2.90(ABTP.2)C0 |
| GS1900-48 | 2.90(AAHN.1)C0 and earlier |
2.90(AAHN.2)C0 |
| GS1900-48HPv2 | 2.90(ABTQ.1)C0 and earlier |
2.90(ABTQ.2)C0 |
Zyxel also notes that on-market products not listed in its table remain unaffected. If you operate hardware adjacent to the GS1900 line, do not assume exposure by family resemblance alone. Verify exact model and firmware. Conversely, if your asset inventory only reflects “Zyxel switch” without the full SKU and firmware string, treat those records as incomplete until confirmed from the device UI, CLI, or configuration export.
Exploitation status and defender assumptions
As of 2026-06-16, exploitation in the wild is not confirmed in the sources provided. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog, and the vendor advisory does not state that active exploitation has been observed. Based on the available information, there is no CISA-confirmed in-the-wild exploitation signal for this flaw at this time.
A public proof of concept is also not known from the referenced source set. No exploit repository or public PoC was identified in the material used for this article. That does not mean exploit development will be difficult or unlikely. CGI parsing bugs in embedded web servers are often attractive targets because they may be reachable over HTTP and can sometimes be exercised with relatively simple crafted requests once reverse engineering begins.
In the absence of confirmed exploitation data, defenders should assume this will become more interesting to attackers if exposed management interfaces are common in the field. That means prioritizing exposure reduction and patching based on reachable attack surface, not just threat intel headlines. If your switch management interface is reachable from ordinary workstation networks, labs, or contractor segments, treat the urgency as higher than the current public exploitation status suggests.
Technical deep dive
The vulnerability is described as a stack-based buffer overflow in the switch CGI program. That generally means attacker-controlled input processed by the embedded web management stack can exceed expected bounds and corrupt memory on the call stack. In embedded network devices, such faults can lead to process crashes, device instability, or code execution depending on exploitability and available mitigations in the firmware build.
Two details materially affect defender prioritization. First, the attack is unauthenticated, meaning the vulnerable code path is exposed before login. Second, the attack is LAN-based, which narrows remote internet exposure but still leaves large internal attack surfaces in flat or poorly segmented networks. In practice, a compromised workstation, malicious insider, red-team foothold, or rogue device on an adjacent VLAN may be sufficient if the management interface is reachable.
Technical Notes
Because the exact CGI parameter or path has not been publicly detailed in the supplied sources, defenders should avoid relying on exploit-specific signatures alone. Instead, use generic detection for abusive access to embedded CGI handlers and oversized HTTP requests to switch management interfaces.
Example Suricata-style hunting idea for oversized internal requests to switch management ranges:
alert http $HOME_NET any -> $SWITCH_MGMT_NET any (
msg:"Possible exploit attempt against switch web management CGI";
flow:to_server,established;
http.uri;
content:"cgi"; nocase;
pcre:"/.{200,}/U";
classtype:web-application-attack;
sid:7273001;
rev:1;
)
This is not a vendor-provided signature and should be tuned carefully to avoid false positives. The goal is to identify suspiciously long requests to CGI paths from unexpected internal clients, not to claim precise exploit detection. Pair that network view with asset state monitoring so you can quickly spot switches that reboot, drop management sessions, or stop responding after receiving anomalous HTTP traffic.
How to identify exposure in your environment
Start with asset discovery. You need a list of all Zyxel GS1900 models and their current firmware versions. If your CMDB or network management system does not already track firmware, use SNMP, switch inventory exports, or administrative login checks to build a temporary remediation list. The key question is whether any device matches an affected model and is running the vulnerable release or anything earlier than the model-specific fixed version.
The second question is reachability. Because the flaw is LAN-based and targets the web CGI path over HTTP requests, exposure depends on who can talk to the management interface. A switch on a dedicated admin VLAN behind ACLs is materially less exposed than the same switch reachable from user access networks. Map management IPs, identify listening web interfaces, and verify the source networks allowed to connect. In many environments, this scoping exercise will reveal weak management segmentation that should be corrected regardless of patch timing.
Technical Notes
A practical first pass is to identify live web management interfaces on known switch IP ranges:
# Probe common management ports on suspected GS1900 addresses
nmap -Pn -p 80,443,8080,8443 10.20.30.0/24
# Enumerate HTTP titles/headers where possible
nmap -Pn -p 80,443 --script http-title,http-headers 10.20.30.0/24
If you have web proxy, firewall, or IDS logs for internal management subnets, look for unusual HTTP requests to switch interfaces, especially requests from non-admin VLANs. Because the exact vulnerable CGI endpoint was not disclosed in the provided sources, defenders should hunt broadly for anomalous requests rather than a single path:
Example HTTP log pattern to review:
src_ip NOT IN <admin_subnets> AND dest_ip IN <switch_mgmt_ips> AND http_method IN ("GET","POST")
Suspicious indicators:
- Long URI strings
- Oversized query parameters
- Repeated requests to CGI paths
- Bursts of 4xx/5xx responses followed by device instability
Example Splunk-style query:
index=network_http dest_ip IN (10.20.30.11,10.20.30.12,10.20.30.13)
| where NOT cidrmatch("10.99.0.0/16", src_ip)
| search uri="*cgi*" OR user_agent="curl*" OR user_agent="python-requests*"
| eval uri_len=len(uri)
| where uri_len > 200 OR status>=500
| table _time src_ip dest_ip method status uri uri_len user_agent
Because stack overflows can also crash or destabilize services, correlate web request anomalies with device reboots, web UI unavailability, configuration save failures, or syslog messages indicating management process restarts. If your switches forward syslog, review logs around the first appearance of unusual internal HTTP traffic to management addresses.
Mitigation and patching guidance
The primary mitigation is to upgrade each affected switch to the model-specific fixed firmware release published by Zyxel. There is no evidence in the provided sources of a universal fixed build across the whole family, so administrators should not assume one firmware image applies to every GS1900 model. Use the exact model-to-version mapping from the vendor advisory.
If you cannot patch immediately, reduce exploitability by restricting management access. Since the vulnerability is described as exploitable by a crafted HTTP request from the LAN with no authentication, every network path to the switch web interface matters. Limit web management to a dedicated admin VLAN, block access from user segments, disable HTTP if HTTPS-only administration is supported and operationally acceptable, and consider disabling web administration entirely if your team can manage the devices safely through alternate methods supported by your environment.
Technical Notes
Firmware installation steps vary by operational model, but the defensive requirement is the same: move every affected device from the vulnerable version to the listed fixed version. Before making changes, export the running configuration and schedule a maintenance window because network switches are production infrastructure.
Example workflow for teams maintaining a local firmware repository:
# Record current firmware from inventory notes
echo "GS1900-48HPv2 current: 2.90(ABTQ.1)C0" >> change-record.txt
# Download the vendor-published fixed image from Zyxel support portal
# Verify hash/signature if Zyxel provides one
sha256sum GS1900-48HPv2_2.90(ABTQ.2)C0.bin
# Store approved image in internal repository
mv GS1900-48HPv2_2.90(ABTQ.2)C0.bin /srv/firmware/zyxel/
If your switches support web-based firmware upload only, document the exact target version in the change plan and verify success after reboot. Example post-upgrade validation steps:
1. Log in to the switch management interface.
2. Confirm model matches the intended hardware.
3. Verify firmware version now shows the fixed release, for example:
GS1900-48HPv2 -> 2.90(ABTQ.2)C0
4. Test management access from the admin VLAN only.
5. Confirm user VLANs cannot reach the management IP over HTTP/HTTPS.
For temporary containment, apply network controls at the L3 boundary:
# Example ACL intent, syntax varies by platform
deny tcp <user_vlans> <switch_mgmt_subnet> eq 80
deny tcp <user_vlans> <switch_mgmt_subnet> eq 443
permit tcp <admin_vlans> <switch_mgmt_subnet> eq 443
If exact workaround support is unknown for your model, assume segmentation is your safest immediate control while patch testing proceeds.
References
The primary references for this CVE are the NVD entry, the CISA KEV catalog for exploitation status validation, and Zyxel’s official advisory with the affected and fixed firmware matrix. Where NVD and vendor scope differ, the vendor advisory should drive remediation because it includes the model-specific patch mapping defenders need.
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-7273
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Zyxel advisory: https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-stack-based-buffer-overflow-vulnerability-in-gs1900-series-switches-06-16-2026
- Additional Zyxel GS1900 advisory page: https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-gs1900-switch-vulnerabilities
For immediate action, inventory affected GS1900 models, confirm firmware against Zyxel’s matrix, upgrade to the fixed version for each model, and lock management-plane access to trusted admin networks only. Even without confirmed exploitation or a public PoC, this is the kind of unauthenticated infrastructure flaw that should move quickly through change management.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.