Between August 19 and 24, 2026, six vulnerabilities rated CVSS 9.9 to 10.0 were published against SOHO routers and access points from four different vendors. They share three traits: remote exploitation, no authentication, and a publicly available exploit for all six.
That last point changes the prioritisation entirely. A critical CVE with no exploit code stays theoretical for weeks. A critical CVE with a published exploit on remotely fingerprintable hardware is scanned by botnets within hours.
These six are grouped into a single article because the pattern is nearly identical from one vendor to the next — and that repetition is precisely the most useful piece of information here.
The Six CVEs
| CVE | Device | Version | CVSS | Nature |
|---|---|---|---|---|
| CVE-2026-77946 | TRENDnet TEW-821DAP | 2.2.01b05 | 10.0 | Stack overflow (NTP/timezone) |
| CVE-2026-78167 | EFM ipTIME T16000M | 14.20.2 | 10.0 | Authentication bypass |
| CVE-2026-75976 | TRENDnet TEW-823DRU | 1.1.02b01 | 9.9 | Stack overflow (strcpy, WAN) |
| CVE-2026-76589 | TRENDnet TEW-755AP | ≤ 20260702 | 9.9 | Stack overflow (SSID) |
| CVE-2026-78050 | Comfast CF-N1-S | 2.6.0.1 | 9.9 | Stack overflow (NTP/timezone) |
| CVE-2026-78169 | UTT HiPER 1250GW | ≤ 3.2.7-210907-180535 | 9.9 | Stack overflow (strcpy) |
The Recurring Pattern: the NTP Configuration Form
Two of these six CVEs, across two different vendors, sit in the timezone and NTP server configuration function:
- CVE-2026-77946 — TRENDnet TEW-821DAP, function
uci_safe_getin/cgi-bin/apply_time.cgi, on thesystem.ntp.server,system.ntp.enable_server,cameo.time.time_zoneandcameo.cameo.syslog_serverarguments - CVE-2026-78050 — Comfast CF-N1-S, function
sub_41AD7Cin/cgi-bin/mbox-config?method=SET§ion=ntp_timezone, on thetimestrandntp_client_enabledarguments
That's not coincidence, and it has an explanation. The NTP form is one of the few configuration screens where the user enters free text: a time server hostname, a timezone string. Those values get copied into fixed-size buffers, then frequently passed to system calls to reconfigure the clock. On firmware written in C without length bounds, it's a natural overflow candidate.
The TRENDnet function name is ironic: uci_safe_get. The safe prefix presumably denotes safe retrieval of a UCI configuration parameter — but nothing suggests the returned value's length is checked before it's copied.
Also worth noting in the TRENDnet case: the cameo.cameo.syslog_server argument. TRENDnet-branded firmware built on a Cameo base, an OEM supplier. A reminder that these vulnerabilities are often shared across several brands reselling the same firmware under a different name — so the real scope can extend beyond the models named in the CVE.
The Worst One Isn't an Overflow
CVE-2026-78167 (ipTIME T16000M, CVSS 10.0) stands apart by its nature:
The impacted element is the function
httpcon_check_session_urlof the component Session Validation Handler. This manipulation causes improper authentication. Remote exploitation of the attack is possible. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
Two things make it worse than the other five.
It's an authentication bypass, not memory corruption. A stack overflow needs an exploit tailored to the exact architecture and firmware; it can fail, crash the device, require tuning. Bypassing session validation is just sending the right request. Reliable, repeatable, quiet, with no crash to alert an administrator.
The vendor didn't respond to the disclosure. So there is no fix to wait for. This is the same situation as the 22 CVEs on the Totolink A8000RU router: when the vendor is silent, the only real mitigation is isolation or replacement.
Affected Products and Versions
| Vendor | Model | Affected version | Fix |
|---|---|---|---|
| TRENDnet | TEW-821DAP | 2.2.01b05 | Check vendor support |
| TRENDnet | TEW-823DRU | 1.1.02b01 | Check vendor support |
| TRENDnet | TEW-755AP | up to 20260702 | Check vendor support |
| EFM | ipTIME T16000M | 14.20.2 | ❌ None — vendor silent |
| Comfast | CF-N1-S | 2.6.0.1 | Check vendor support |
| UTT | HiPER 1250GW | up to 3.2.7-210907-180535 | Check vendor support |
NVD data exposes no fixed version for these six CVEs at the time of writing. I won't invent a number: check each model's support page. And for the ipTIME T16000M, the vendor's silence makes a fix unlikely.
Exploitation and Impact
Why these devices get scanned first
- Remotely fingerprintable: the HTTP banner, static asset paths and CGI URL structure are enough to identify the model and often the version. Targeting automates trivially.
- Exposed by default: remote administration is enabled on a significant share of installations — sometimes by the ISP, sometimes by a user who wanted to reach their camera.
- Never patched: nobody tracks firmware updates for an access point installed above a ceiling tile four years ago.
- Public exploits: no research skill required, only the ability to run a scan.
What happens next
On a compromised router or access point:
- Traffic interception: the router sees everything passing through. Changing the DNS servers is enough to redirect users to phishing pages without ever touching their machines.
- LAN pivot: IP cameras, NAS units, printers, industrial controllers — everything behind it becomes reachable from outside.
- Botnet enrolment: the most common outcome. Mirai derivatives target exactly this device class, and once enrolled the router participates in attacks whose visible origin is your organisation's IP address.
- Near-undetectable persistence: with no agent, no exported logs and no monitoring, a compromised router runs normally for years.
That last point deserves emphasis. Unlike a server, nothing signals the problem: the connection works, the Wi-Fi works, users don't complain. The device keeps doing exactly what you expect of it, in addition to what the attacker expects of it.
Audit to Run
1. Enumerate what's actually reachable from outside
This is the highest-value check, and it applies to your whole network estate, not just these six models:
# From an EXTERNAL connection, not the internal network
nmap -Pn -p 80,443,8080,8443,8081 <public-ip>
Any administration interface answering from the internet is a problem independent of any CVE.
2. Inventory models and firmware versions
The question you need to answer in minutes: which router and access point models are deployed, on which version, and where? If answering takes a day of investigation, that's the real problem to fix.
3. Hunt for signs of compromise
On each reachable device:
- DNS servers — a modified DNS is the most frequent and most revealing signal
- Undocumented port forwards
- Unknown administrator accounts
- Added firewall rules
- Outbound traffic initiated by the device itself to destinations unrelated to its function (visible from the upstream device)
Mitigation
1. Turn off remote administration
Applicable immediately, at no cost, and effective against all six CVEs plus the next ones:
Admin interface → Management / Administration
→ disable "Remote access" / "Remote management"
Five of the six become unexploitable from the internet the moment this is applied.
2. Restrict internal access to the admin interface
All six CVEs require network access to the web interface. On a segmented network, administration should only be reachable from a management VLAN — never from guest Wi-Fi or the user VLAN.
Verify in particular that your guest network is genuinely isolated from the admin interface of the device serving it. That's an extremely common misconfiguration.
3. Update firmware where a fix exists
Check each model's support page. For the five vendors still responsive, a fix is plausible.
4. For the ipTIME T16000M: replace or isolate
Silent vendor, CVSS 10.0, authentication bypass, public exploit. There is no third option:
- Replace the device with a model whose vendor maintains firmware
- Or isolate it strictly: no internet exposure, administration reachable from a single management IP, and treat the LAN behind it as potentially exposed
5. If you conclude there was a compromise
On a network device compromised at firmware level, cleaning in place isn't reliable:
- Factory reset, then reconfigure by hand — don't restore a backup, it may carry the tampered configuration
- Change every password: administration, Wi-Fi PSKs, and credentials for any service whose traffic passed through the device
- Audit the LAN behind it: a compromised router may have served as an observation post on all traffic
Why Continuous Monitoring of Network Gear Matters
These six CVEs illustrate a structural blind spot. Routers, access points and small network devices appear in no software inventory: no agent, no presence in OS scans, and often no declared owner on the IT side because they were installed by a contractor or an ISP. Add vendors who publish no advisory — or who don't respond at all — and "am I affected?" becomes a multi-day investigation, during which public exploits circulate.
With cveo.tech, inventory your routers, access points and network devices alongside your servers, and get automatic alerts whenever a critical CVE targets one of your exact versions. So a public exploit landing on a model in your estate is a notification, not a discovery.