Zyxel GS1900: the patch CISA pointed to did not stop the exploit used on 996 switches, Binarly says

Ten of ten June fixes are on Zyxel's November list of affected firmware

Zyxel's advisory for CVE-2026-107441, published on 3 November 2026, lists ten GS1900 switch models as affected up to a stated firmware version "and earlier". For every one of the ten, that last affected version is the exact version Zyxel's advisory of 16 June 2026 gave as the fix for an earlier flaw, CVE-2026-7273. On the GS1900-24, for example, 2.90(AAHL.2)C0 was the June fix and is now inside the affected range; the new fix is 2.90(AAHL.3)C0. That is ten of ten (derived, compared model by model in this briefing's arithmetic). A switch updated in June, as Zyxel advised and as CISA's catalogue of known exploited flaws later directed, stayed open to CVE-2026-107441 until the .3 firmware arrived, which Binarly dates to 22 October 2026.

Why that matters: GreyNoise reported on 21 September that an actor it calls Kapibala took configurations, hashed root credentials and network information from 996 GS1900 switches in 48 countries, from on or about 17 August, and it named CVE-2026-7273 as the flaw used. CISA added CVE-2026-7273 to its Known Exploited Vulnerabilities (KEV) catalogue the same day, with a due date of 24 September. Binarly, the firmware security company, says the exploit in fact beat the June fix, and that the flaw it used is the one now numbered CVE-2026-107441. From GreyNoise's 17 August to the 22 October fix is 66 days (derived). The fix came 28 days after the KEV due date (derived). Binarly calls CVE-2026-107441 "a recently confirmed zero-day".

What the ten of ten comparison does not establish: it shows, on Zyxel's own record, that June firmware carries the newer flaw. It does not show how many of the 996 switches were running June firmware when they were taken. GreyNoise does not say, and the exploit's built in version list, as Binarly describes it, reaches back through years of older GS1900-24 releases, so many victims may have run firmware that either flaw would open. Zyxel's November advisory does not mention exploitation at all.

This briefing reads Zyxel's two advisories and its two community release notes, Binarly's blog post and advisory BRLY-2026-057, GreyNoise's post and its dated timeline, the CVE.org records for both numbers and CISA's KEV feed, all fetched between 21:18 and 21:22 UTC on Wednesday 4 November 2026. BleepingComputer's report of the same day, a secondary source, pointed to them. No exploit sample was downloaded, and the exploit code, request layouts and attacker commands that the primaries print are not reproduced here.

How the attribution moved, in dated order

Each date below is printed by the party named in the last column. Where two records disagree on a date, both are given.

The derived gaps: 62 days from the June fix to the first exploitation GreyNoise dates; 97 days from the June fix to the KEV listing; 66 days from first exploitation to the working fix; 31 days from the KEV listing to that fix; 23 days from Binarly's report to Zyxel's fix; 12 days from the fix to the advisory; and 44 days, at the time of reading, for which KEV has named only CVE-2026-7273. One small conflict: Binarly says Zyxel reserved CVE-2026-107441 on 11 October, while the CVE record says it was reserved on 8 October. The record's date is the one the CVE system stamps; both are shown.

Zoom

One parser, two numbers: how Binarly tells the flaws apart

Zyxel describes both flaws in almost the same words. The June advisory says a "stack-based buffer overflow vulnerability in the CGI program" could let "a LAN-based, unauthenticated attacker" potentially execute OS commands "via a crafted HTTP request". The November advisory says the same of an "out-of-bounds write vulnerability in the CGI program". Same component, same attacker, same outcome, different name.

Binarly's account, in words and at the level a defender needs. While examining servers tied to the JITTERLY backdoor and SIXZUT rootkit that Acronis had linked to the Red Heron campaign, it found an open directory holding an archive with an obfuscated Python exploit for GS1900 switches. The exploit fingerprints the firmware and carries settings for known versions, and the newest entry is 2.90(AAHL.2)C0, the June fix for the GS1900-24. That is the clue that made Binarly look again: an exploit for a patched flaw should not need settings for the patched firmware.

Binarly then compared the June firmware with the earlier one. It says the web interface's parameter parser stores each request parameter in a fixed slot of a global table, never limits how long a parameter can be, and keeps a parameter counter right after the table. The June patch added a check on that counter, but the check runs only after each parameter has been copied, so an over long parameter can overwrite the counter before the check sees it. The patch also swapped some unsafe string formatting calls for bounded ones, which Binarly says "has little to do with what the exploit targets". The October firmware checks the count before copying and limits each field, which Binarly says "effectively fixes the vulnerability". Binarly's advisory adds that the parser is present in seven CGI programs and reachable from the entry point in three of them.

Zyxel's own view, as Binarly reports it: Zyxel said CVE-2026-7273 "was related to a reqParameters overflow due to a lack of counter validation", despite its public description of a stack overflow, and treats Binarly's report as "a separate vulnerability because we also mentioned the lack of a parameter size check." Zyxel's own pages say none of this; it comes from Binarly's post.

So is it one flaw fixed twice, or two flaws? Binarly's advisory offers two readings. If the June parser changes were the CVE-2026-7273 patch, "then the patch is incorrect, as are the vulnerability description and CVSS". If they fixed something else, "CISA's association of that activity with CVE-2026-7273 would be incorrect". "In either case", it says, the flaw is present in all ten releases "that were advertised as fixes". BleepingComputer adds that it remains unclear whether the exploit was built to bypass the June updates or used a related flaw the June patches failed to address.

Zoom

The friendly names. "Patched" did the damage here. A KEV entry names a CVE; the CVE names fixed versions; a June update to those versions produced a record that said "fixed" while, on Zyxel's own November table, the device remained exposed. "Zero day" is Binarly's word, and it holds in a narrow sense the record supports: no fix that stopped this exploit existed before 22 October. It does not establish that any victim was on June firmware. GreyNoise's own phrase was "a novel exploit of CVE-2026-7273". "Kapibala" is GreyNoise's label and "Red Heron" is Acronis's, as cited by GreyNoise and Binarly; neither is an identification. "Chinese speaker" is GreyNoise's assessment from clues: it says the actor is "a suspected Chinese speaker possibly working in UTC+8", based on the operational timeline and Chinese language comments in its tools.

What the records said on 4 November

Each record was read between 21:18 and 21:22 UTC on 4 November 2026. Any of them can change within hours; the times are given so a reader can check.

• CISA KEV, catalogue release 2026.11.04 (20:00 UTC): lists CVE-2026-7273 as "Zyxel GS1900 Series Switches Stack-Based Buffer Overflow Vulnerability", added 21 September, due 24 September, with forensic triage marked "Yes" and the notes linking the June advisory. CVE-2026-107441 is not in the catalogue.
• CVE-2026-7273 record: Zyxel's text is as published on 16 June (stack based buffer overflow, CWE-121, 8.8, adjacent). CISA's enrichment adds exploitation "active", the KEV date and a link to GreyNoise's post. Last updated 22 September, 03:55 UTC.
• CVE-2026-107441 record: published 3 November, 01:41 UTC, by Zyxel: out of bounds write, CWE-787, 8.8, "an unauthenticated adjacent attacker". CISA's enrichment, stamped 04:56 UTC on 4 November, records exploitation as "none". One product line is printed as "GS1900-HPv2 firmware" for the version string Zyxel's advisory assigns to the GS1900-24HPv2.
• Zyxel's June advisory: its revision history shows only "2026-6-16: Initial release". No note points readers to the November advisory.
• Zyxel's November advisory: patches and a thank you to a Binarly researcher. No word of exploitation, GreyNoise, KEV or CVE-2026-7273.
• GreyNoise's post of 21 September and its timeline page: still describe "a novel CVE-2026-7273 exploit". No update note was on either page.

The SSVC line matters for anyone who triages by it. CISA's decision record for CVE-2026-107441 says exploitation "none" on the morning of 4 November, while Binarly's advisory, published the day before, has a section headed "Exploitation in the wild". A team that filters on that field would rank the flaw that was exploited below the one that was named.

Zyxel's community pages add one oddity. The release note for the June firmware, headed "May 2026", was posted to the community on 2 November 2026, after a user asked why the .2 release had never been announced there. The .3 release note was posted on 23 October, 01:03 UTC, and edited on 3 November.

Zoom

Adjacent or network: what the score hides

Zyxel scores both flaws 8.8 with an adjacent attack vector, and both advisories say "LAN-based". Binarly scores CVE-2026-107441 at 9.8, arguing that exploitation "uses HTTP and has no protocol-level adjacency requirement; an attacker only needs network reachability to the management service". The two scores differ only in that one choice.

GreyNoise's count bears on it. It says the actor took data from switches in 48 countries. GreyNoise does not say how the switches were reached; this briefing's inference is that an attacker working across 48 countries was not sitting on each victim's local network, so for those switches the "adjacent" label offered no protection. The score is Zyxel's to set, and both numbers are shown.

The campaign, as GreyNoise tells it

GreyNoise watches attacks through its own sensors and, here, the actor's infrastructure. It says it has tracked one IP address since early June and is "confident" that activity from 7 May 2026 onwards belongs to a single actor, which it judges "the same or related to" Red Heron, from the shared command and control domain, malware family, July exploitation of Gitea and other techniques. The switch campaign is one entry in a longer list: GreyNoise also describes attacks on Ubiquiti, FlowiseAI, WordPress, Gitea, Nuclio, SENAITE and Proxmox systems, and the theft of more than 18,000 records from a western government.

On the switches, GreyNoise says the actor exploited and exfiltrated "configurations, root level credentials (hashed), and networking information" from 996 GS1900 Smart Managed Switches in 48 countries, using a Python script obfuscated with PyArmor. It adds that "564 of the victims had factory default credentials": 56.6 per cent (derived). A hashed default password is no secret at all, so for those 564 the attacker held working root access, by this briefing's reading. Both GreyNoise and Binarly suspect the exploit was written with a large language model; neither presents proof.

GreyNoise's table was published against CVE-2026-7273 and has not been reissued. Read it as the actor's reach, not as a count of devices taken through either CVE number.

Stated, and not stated

Each party has a commercial interest, and it is stated once here. Zyxel sells the switches and wrote both advisories. GreyNoise sells internet sensor data, and its post closes on an offer to sign up. Binarly sells its firmware analysis platform and ends its post saying "the definitive way" to find such flaws is to read the binary code, "That's why we created BTP". None of that makes a finding wrong. The ten of ten comparison above rests on Zyxel's own tables, not on any vendor's argument.

What to do, in order

Technical details

The artifacts below are copied from the primaries as printed. No exploit code, request layout, memory address or attacker command is reproduced, though the primaries print some. First, Zyxel's table of affected and fixed firmware for CVE-2026-107441. Check the firmware version on each switch against the third column.

Affected model | Affected version | Patch availability
GS1900-8 | 2.90(AAHH.2)C0 and earlier | 2.90(AAHH.3)C0
GS1900-8HP | 2.90(AAHI.2)C0 and earlier | 2.90(AAHI.3)C0
GS1900-10HP | 2.90(AAZI.2)C0 and earlier | 2.90(AAZI.3)C0
GS1900-16 | 2.90(AAHJ.2)C0 and earlier | 2.90(AAHJ.3)C0
GS1900-24 | 2.90(AAHL.2)C0 and earlier | 2.90(AAHL.3)C0
GS1900-24E | 2.90(AAHK.2)C0 and earlier | 2.90(AAHK.3)C0
GS1900-24EP | 2.90(ABTO.2)C0 and earlier | 2.90(ABTO.3)C0
GS1900-24HPv2 | 2.90(ABTP.2)C0 and earlier | 2.90(ABTP.3)C0
GS1900-48 | 2.90(AAHN.2)C0 and earlier | 2.90(AAHN.3)C0
GS1900-48HPv2 | 2.90(ABTQ.2)C0 and earlier | 2.90(ABTQ.3)C0

The bug fix lines in Zyxel's two community release notes, as printed, including the stray space in the CVE number of the first.

V2.90 Patch 3 release note, headed "October 2026", Bug Fix:
1. Fixed Pre-authentication out-of-bounds write vulnerability. (CVE-2026- 107441).

V2.90 Patch 2 release note, headed "May 2026", Bug Fix:
2. Fixed Pre-authentication buffer overflow vulnerability (CVE-2026-7273).

The KEV entry as it stood, field by field, and the count for CVE-2026-107441 in the same release. The required action and notes fields are long and are summarised in the text above.

cveID: CVE-2026-7273
vendorProject: Zyxel
product: GS1900 Series Switches
vulnerabilityName: Zyxel GS1900 Series Switches Stack-Based Buffer Overflow Vulnerability
dateAdded: 2026-09-21
dueDate: 2026-09-24
knownRansomwareCampaignUse: Unknown
forensicTriage: Yes
cwes: CWE-121

CVE-2026-107441 entries in catalogue 2026.11.04 (2026-11-04T20:00:05.774Z): 0

CISA's SSVC decision points from the two CVE records. These feed many prioritisation tools.

CVE-2026-107441  CISA ADP Vulnrichment, SSVC 2.0.3, role CISA Coordinator, timestamp 2026-11-04T04:56:28.422975Z
  Exploitation: none
  Automatable: no
  Technical Impact: total
CVE-2026-7273  CISA ADP Vulnrichment, SSVC 2.0.3, role CISA Coordinator, timestamp 2026-06-17T00:00:00+00:00
  Exploitation: active
  Automatable: no
  Technical Impact: total

Binarly's hashes of the firmware payload and the web interface program shared by all ten June releases. A firmware image whose payload or dispatcher.cgi matches is affected.

Affected firmware: the ten 2.90(xxxx.2)C0 releases (Binarly: "All ten archives contain identical" payloads)
| `.bix` firmware payload                  | `8fc87aeadd18e7d711e5fec8e0003f0283c40c06a5800580458937579d65af79` |
| `/home/web/cgi-bin/dispatcher.cgi`       | `7dc47078f0ff2d75de4a7cd71895d01f0cce4728517f5efd94e2212975ceb811` |

GreyNoise's indicators. The addresses and the domain are live attacker infrastructure, so this site has defanged them; the hashes are as printed. One exploitation address is shown by GreyNoise as redacted. The two account names are as GreyNoise lists them.

Indicator | Note   (as printed by GreyNoise; addresses and domain defanged by this site)
0e81d80b40eaacbf6cb1e817fb1824c30a824af5cb4faca4aa9b03fd506d480f | Backdoor
0f6e757e82c4d91df5bd249f775b9970b59dee42cc0dfe40f879d77fc16821c6 | Backdoor
2ff2945b13a4cd0e9a65c85af29ea1539e162a516466c0de682dbf9f8a4000b1 | Backdoor
*.981666[.]xyz | C2
74.48.66[.]73 | Staging
<REDACTED> | Exploitation
104.225.153[.]141 | C2
172.245.247[.]21 | Exploitation
kapibala2 | Account
kapibala | Account

Binarly's host names, addresses and malware hashes. These indicate the actor's servers and its Linux backdoor and rootkit, not activity on the switches themselves. Binarly defanged them. Do not visit them.

Hostname | Resolved IPv4 address | Services   (as printed by Binarly, already defanged)
p2.981666[.]xyz | 104.223.65[.]148 | JITTERLY C&C at 8080/tcp; web servers with open directories at 80 and 18081/tcp
s0.981666[.]xyz | 203.88.123[.]148 | Admin panel with SoybeanAdmin web UI at 80/tcp;  OpenSSH server at 22/tcp
s2.981666[.]xyz | 104.225.153[.]141 | JITTERLY C&C at 5432, 6379, and 8082/tcp; web server with HTTP authorization on 8092/tcp; Nginx on 8833/tcp
s7.981666[.]xyz | 166.88.227[.]181 | JITTERLY C&C at 443/tcp

File found in the open directory on p2.981666[.]xyz, port 18081, as named by Binarly: gs1900_bundle.tar.gz
Contents as listed by Binarly: ./exp.py and a pytransform runtime directory

JITTERLY
0f6e757e82c4d91df5bd249f775b9970b59dee42cc0dfe40f879d77fc16821c6
663a8088faca8e126a11648f5671fcf4eaf96435e10daf63a1d1b17d8385154c
82d072ab03d90c0131b06a576eadf2c986a51f0de986d50db4e49be01bf125cb
SIXZUT
295133156b6a7d95b9c92f832f49e35235f1fbd3906e75c9202ef4cd65d1018c
64677002011bc2e4bc642a4154a20fdb95620ebd0144b98fc60f917901ec8b92
728810b07e911b235f6450e784391e39f68819a0a5d209662162916ffea25146

Binarly's YARA rule for the JITTERLY backdoor, for scanning Linux hosts. It is a detection rule, copied as printed.

import "elf"
rule JITTERLY {
  meta:
    description = "JITTERLY ELF implant"
    author      = "Binarly"
    reference   = "https://www.acronis.com/en/tru/posts/red-heron-exploits-gitea-n-day-flaw-in-multinational-campaign-exposing-new-linux-rootkit/"
    date        = "2026-09-16"
    namespace   = "malware"
    severity    = "high"
    hash        = "f264f04f597a2bdda372a27ae701c18d4036175b1eb8722db5f8531615b38788"
    hash        = "82d072ab03d90c0131b06a576eadf2c986a51f0de986d50db4e49be01bf125cb"
    hash        = "663a8088faca8e126a11648f5671fcf4eaf96435e10daf63a1d1b17d8385154c"
  strings:
    $ = "jitter" fullword
    $ = "nginx" fullword
    $ = "/etc/machine-id" fullword
    $ = "/proc/sys/kernel/random/boot_id" fullword
    $ = "USER" fullword
    $ = "LOGNAME" fullword
    $ = "00:00:00:00:00:00" fullword
    $ = "reverse" fullword
    $ = "VERSION_ID=" fullword
    $ = "NAME=" fullword
    $ = "encrypt_key" fullword
    $ = "rootkit_scheme" fullword
    $ = "/sys/class/net" fullword
    $ = "screenshot not supported" fullword
    $ = "job not found" fullword
  condition:
    filesize < 2MB and elf.number_of_segments > 1 and all of them
}

The question

If your records show these switches fixed for CVE-2026-7273 in June, what in your process would have told you, before 3 November, that the fix had not held, when the KEV entry, the June advisory and the CVE record all still said it had?

Key facts