Two of the three were named today at CVSS 9.9, weeks after the firmware that closes them shipped; the third has had a working public exploit since February and only got a fix version attached to its record this morning.
What happened
At 7:16 a.m. UTC on Monday, September 7, VulDB published two CVE records against Advantech’s WISE-6610 industrial LoRaWAN gateway. CVE-2026-79697 and CVE-2026-79698 are both command injections reached through the device’s LuCI web administration interface, and both carry a CVSS 3.1 base score of 9.9 on the vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
CVE-2026-79697 sits in the function basicstation_apply, in what the record calls the “Basic Station Certificate-Deletion Handler.” CVE-2026-79698 sits in nodered_lib_apply, in the Node-RED library component. In both cases the injected value is the act argument. The records name thirteen model variants as affected at firmware 1.2.1_20251110: WISE-6610-NB, -EB, -TB, -JB, -CB, the five matching EL models, and WISE-6610P-DEA, -DNA, and -DTA. Both name 1.2.4_20260821 as the unaffected version.
Both records carry a second score. VulDB’s CVSS 4.0 assessment puts each at 8.6, on a vector ending E:P — the exploit-maturity metric set to proof-of-concept. VulDB’s own entry for CVE-2026-79697 states that “a proof-of-concept exploit exists and is publicly accessible.”
The third flaw is older. CVE-2026-2670 was published on February 18, 2026 against the same thirteen models at the same firmware level. It is a command injection in /cgi-bin/luci/admin/openvpn_apply reached through the delete_file argument, and it scores lower — 7.2 on CVSS 3.1, on a vector requiring high privileges and staying inside its own scope. Its NVD description reads: “The exploit is publicly available and might be used. Upgrading to version 1.2.4_20260821 is able to address this issue.”
That sentence is new. The record’s lastModified timestamp is 2026-09-07T06:17:18.777 — an hour before the two new CVEs went out, and roughly two hundred days after the record itself was published. The referenced proof of concept is older still: a GitHub issue opened February 6, 2026 that traces the injection to an unsanitized os.execute() call in /usr/lib/lua/luci/controller/admin/uci.lua and gives the request outright, act=delete&delete_file=123123|id>2.txt&openvpn_id=1, confirming execution as root.
Advantech’s own firmware download page lists a single build for the series, WISE-6610_v1.2.4_20260821, described as “WISE-6610 V2 Firmware (WISE-6610-EL-XB FW for EdgeLink 2.8.4.1),” with a listed release date of September 2, 2026. The version string itself is stamped August 21. VulDB’s timeline says the CVE-2026-79697 submission arrived on September 2 with the countermeasure already disclosed, and credits the vendor: Advantech “was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.”
Advantech’s security advisory page tells none of this. Checked in both its English and Chinese editions, it lists four advisories — ACIRT-260501 covering CVE-2026-6888 (May 13, 2026), ACIRT-260101 on IoTSuite 3D Visualization (January 12, 2026), ACIRT-251201 on WISE-DeviceOn 5.3.12 Server (December 4, 2025), and AQIRT-241201 on the EKI-6333AC access points (December 3, 2024). The WISE-6610 appears in none of them, and neither does any of the three CVE IDs.
Why it matters
The interesting thing here is the order in which the three flaws became visible, and what that order did to anyone triaging them.
The one disclosed first scores lowest. CVE-2026-2670 needs an account with high privileges and does not cross a scope boundary; that is what pulls it down to 7.2. The two disclosed today need only low privileges and do change scope, and that is most of the distance up to 9.9. So an operator who saw the February record, read a 7.2 that required admin access anyway, and put the gateway on the deferred pile made a defensible call in February and is looking at a different device today. Nothing about the box changed. The published account of it did.
Worse, that operator had no fix to apply even if they had wanted one. Between February 18 and this morning, the NVD record for CVE-2026-2670 carried a public exploit and no remediation. The upgrade sentence and the 1.2.4_20260821 fixed-version data were attached today, in the same VulDB batch that produced the two new records. The fix has existed since at least September 2, when it appeared on Advantech’s download page, and its build stamp says August 21. For somewhere between five days and two and a half weeks, depending on which date you take as the fix’s birthday, the remedy was downloadable and the record did not say so.
This failure mode is worth naming because it is not the usual one. The common patch-gap story is a vendor sitting on a fix. This is the opposite: the vendor moved, and by VulDB’s account moved well. The record lagged the vendor. A scanner run against these gateways any time in August would have reported a 7.2 with a public exploit and no available fix, at a moment when the fix was either already built or days from being posted. Scanners read the record, and the record was wrong by omission.
Then there is the advisory that does not exist. Advantech maintains an ACIRT advisory series and has used it four times since December 2025, including twice this year. It did not use it here. The result is that the only public account of three root-level command injections in an industrial gateway lives in a third-party CNA’s database, a GitHub issue, and an undated firmware download whose description mentions EdgeLink and says nothing about security. An operator who does what security teams are told to do — subscribe to the vendor’s advisory feed and act on it — would have learned nothing about any of this, in February or today.
The components matter too. Basic Station is the LoRa packet-forwarder protocol implementation; Node-RED is the flow-based automation runtime a lot of industrial gateways ship as the thing operators actually build in. Those are not obscure corners of the firmware. They are the two features most likely to be enabled, and both handlers take an act argument straight into a shell.
One last wrinkle, on scoring. The CVSS 4.0 numbers on the two new records are lower than the 3.1 numbers — 8.6 against 9.9 — because 4.0 handles the old scope-change bonus differently and folds the subsequent-system impacts in on their own terms. Anything sorting by “highest score in the record” will see 9.9; anything that has migrated to 4.0 will see 8.6 and rank these below flaws that looked less serious yesterday. Same flaw, same record, two answers.
What to do
Upgrade to 1.2.4_20260821, available from Advantech’s WISE-6610 firmware page (support entry 1-2K7AXRI). Check the full build string on the device rather than the marketing version — the date stamp is part of the identifier the CVE records use, and “1.2.4” on its own does not tell you which build you have.
If any of these gateways came off firmware 1.0.15 or older, Advantech’s own page carries a prerequisite: run the separate DTB Upgrade process after the firmware update and reset to factory defaults afterward. Plan the outage for that, because a half-finished upgrade on a field gateway is worse than a scheduled one.
Until the upgrade lands, treat the LuCI administration interface as the whole attack surface. All three flaws are reached through /cgi-bin/luci/admin/ endpoints, and two of the three need only a low-privilege authenticated session. Restrict management access to a jump host or a management VLAN, and audit which accounts exist on these devices — the jump from 7.2 to 9.9 is almost entirely the jump from “needs admin” to “needs any account.”
For detection, the February proof-of-concept publishes a Snort rule matching shell metacharacters in the delete_file parameter on POSTs to openvpn_apply. It covers CVE-2026-2670 only; the same shape of rule applied to basicstation_apply and nodered_lib_apply on the act parameter would cover today’s two, and is worth writing locally rather than waiting for a vendor signature.
Do not wait for an Advantech advisory to confirm any of this. There is no indication one is coming.
Sourcing note
Checked directly: the NVD records for CVE-2026-79697 (published 2026-09-07T07:16:45.903), CVE-2026-79698 (published 2026-09-07T07:16:47.420), and CVE-2026-2670 (published 2026-02-18T22:16:27.360, last modified 2026-09-07T06:17:18.777); VulDB entry 399512 for CVE-2026-79697, for the submission timeline, exploit-availability statement, and vendor-response language quoted above; Advantech’s WISE-6610 firmware download page for the build name and listed release date; Advantech’s security advisory page in both its English and Chinese editions for the advisory list.
The claim that Advantech has published no advisory covering these CVEs rests on two separate retrievals of the advisory index, at two different URLs, both asked to answer explicitly whether WISE-6610 or any of the three CVE IDs appear. Both returned the same four advisories and no match. If Advantech publishes one after this posts, that is a development, not a contradiction.
Could not reach: the researcher writeup hosted on a Feishu wiki, referenced by both new CVE records — the host disallows automated fetching, so the technical detail in those two records is taken from the CVE descriptions and the VulDB entry rather than from the original writeup. Neither new record carries CISA KEV fields, and there is no federal deadline attached to any of the three.
Unresolved: whether 1.2.4_20260821 is the only build that fixes all three, or whether an intermediate release closed some of them — Advantech’s download page currently lists one firmware entry for the series, so there is nothing to compare against. Also unresolved is the gap between the August 21 build stamp and the September 2 listed release date; both are Advantech’s own values, which is why this story does not give a single date for when the fix became available.