CVE Alert: CVE-2025-12211 – Tenda – O3

CVE-2025-12211

HIGHNo exploitation known

A security flaw has been discovered in Tenda O3 1.0.0.10(2478). Affected by this issue is the function SetValue/GetValue of the file /goform/setDmzInfo. The manipulation of the argument dmzIP results in stack-based buffer overflow. It is possible to launch the attack remotely. The exploit has been released to the public and may be exploited.

CVSS v3.1 (8.8)
Vendor
Tenda
Product
O3
Versions
1.0.0.10(2478)
CWE
CWE-121, Stack-based Buffer Overflow
Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:P/RL:X/RC:R
Published
2025-10-27T03:32:06.892Z
Updated
2025-10-27T03:32:06.892Z

AI Summary Analysis

Risk verdict

Critical remote code execution risk on Tenda O3 due to a stack-based overflow in setDmzInfo; exploit publicly disclosed, so urgent patching is advised.

Why this matters

The flaw allows an attacker with low privileges to compromise the device remotely, potentially taking control of the router, disabling protections, or pivoting into the internal network. Given the device’s role in NAT/DMZ exposure, successful exploitation can expose connected hosts and sensitive network assets, with high impact for both home and small-business environments.

Most likely attack path

Network-based exploitation (AV:N, UI:N, AC:L) requires no user interaction but does need remote access to the device and low privileges (PR:L). Successful exploitation yields full confidentiality, integrity, and availability impact (C/H, I/H, A/H) within the target scope. An internet- or WAN-reachable router with DMZ management enabled is the plausible precondition; post-exploitation, attacker could persist or move laterally within the local network.

Who is most exposed

Home users and small offices deploying Tenda O3 routers with DMZ/remote-management features exposed are at greatest risk. Devices directly facing the internet or on poorly segmented networks are particularly vulnerable.

Detection ideas

  • Logs show repeated /goform/setDmzInfo requests with crafted dmzIP values or crashes.
  • Unusual device reboots or memory-corruption crash signatures; stack traces in logs.
  • Incoming network probes or attempted connections to management interfaces from external IPs.
  • Known exploit patterns or signatures from CTI indicators (IOCs, IOAs) being observed.
  • Anomalous changes to DMZ settings or IP addresses without user input.

Mitigation and prioritisation

  • Apply the vendor’s patched firmware version as soon as available; if patch latency is long, disable or restrict remote management and DMZ exposure.
  • Implement strict access controls: limit management interfaces to trusted LANs, enforce firewall rules, and segment IoT devices from critical assets.
  • Enable enhanced logging, monitor for DMZ-related traffic aberrations, and collect crash/dump data for forensics.
  • Verify asset inventory and patch status; schedule a rapid, tested upgrade window with rollback plan.
  • If KEV/EPSS data become available indicating higher exploitation likelihood, elevate to priority 1.

Support Our Work

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.

AI APIs OSINT driven New features