Back to blog
CVE-2026-77946CVE-2026-75976CVE-2026-76589CVE-2026-78167CVE-2026-78050CVE-2026-78169TRENDnetipTIMEComfastUTTrouterCVE

SOHO Routers: 6 Critical CVEs with Public Exploits (TRENDnet, ipTIME, Comfast, UTT)

TRENDnet TEW-821DAP / 823DRU / 755AP, EFM ipTIME T16000M, Comfast CF-N1-S and UTT HiPER 1250GW: six CVSS 9.9-10.0 CVEs, every exploit is public. Audit and mitigation.

August 24, 20268 min read

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

CVEDeviceVersionCVSSNature
CVE-2026-77946TRENDnet TEW-821DAP2.2.01b0510.0Stack overflow (NTP/timezone)
CVE-2026-78167EFM ipTIME T16000M14.20.210.0Authentication bypass
CVE-2026-75976TRENDnet TEW-823DRU1.1.02b019.9Stack overflow (strcpy, WAN)
CVE-2026-76589TRENDnet TEW-755AP≤ 202607029.9Stack overflow (SSID)
CVE-2026-78050Comfast CF-N1-S2.6.0.19.9Stack overflow (NTP/timezone)
CVE-2026-78169UTT HiPER 1250GW≤ 3.2.7-210907-1805359.9Stack 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_get in /cgi-bin/apply_time.cgi, on the system.ntp.server, system.ntp.enable_server, cameo.time.time_zone and cameo.cameo.syslog_server arguments
  • CVE-2026-78050 — Comfast CF-N1-S, function sub_41AD7C in /cgi-bin/mbox-config?method=SET&section=ntp_timezone, on the timestr and ntp_client_enabled arguments

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_url of 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

VendorModelAffected versionFix
TRENDnetTEW-821DAP2.2.01b05Check vendor support
TRENDnetTEW-823DRU1.1.02b01Check vendor support
TRENDnetTEW-755APup to 20260702Check vendor support
EFMipTIME T16000M14.20.2None — vendor silent
ComfastCF-N1-S2.6.0.1Check vendor support
UTTHiPER 1250GWup to 3.2.7-210907-180535Check 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:

  1. Factory reset, then reconfigure by hand — don't restore a backup, it may carry the tampered configuration
  2. Change every password: administration, Wi-Fi PSKs, and credentials for any service whose traffic passed through the device
  3. 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.

Monitor CVEs with AI

AI-powered search, CVSS scoring, asset monitoring and automatic alerts.