CVE-2026-51762 in TOTOLINK
Summary
by MITRE • 09/01/2026
Incorrect access control in the meshInfoKick function of TOTOLINK T6 4.1.5cu.748_B20211015 allows unauthenticated attackers to kick or clean stale mesh information/state and trigger regeneration of mesh metadata via sending a crafted MQTT message to the cs_broker component.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in TOTOLINK T6 firmware version 4.1.5cu.748_B20211015 represents a critical failure in access control mechanisms within the meshInfoKick function, which is integral to the device's mesh networking capabilities. This flaw allows unauthenticated attackers to interact with internal system states by sending crafted MQTT messages directly to the cs_broker component. The core technical issue lies in the absence of proper authentication or authorization checks before executing operations that modify critical network metadata. By exploiting this gap, an attacker can force the router to kick existing mesh nodes or clear stale state information without valid credentials, effectively disrupting the established mesh topology and triggering a regeneration of mesh metadata.
From a technical perspective, the cs_broker component serves as the central message broker for MQTT communications within the device's firmware architecture. The vulnerability stems from insufficient validation of incoming messages targeting the meshInfoKick function. When an attacker sends a specifically crafted payload to this endpoint, the system processes the request and executes logic that clears or resets mesh-related data structures. This action does not require any form of user authentication, which is a severe deviation from standard security practices for administrative functions. The ability to manipulate these internal states remotely via MQTT highlights a significant misconfiguration in how network services expose their interfaces to potential external actors on the local network segment.
The operational impact of this vulnerability is substantial, primarily affecting the availability and integrity of mesh networking features. An attacker can cause a denial of service by repeatedly triggering the regeneration of mesh metadata, which forces connected devices to re-establish connections with the router. This process consumes significant computational resources and bandwidth, potentially leading to network instability or complete connectivity loss for all nodes in the mesh. Furthermore, the ability to kick stale information may disrupt legitimate user sessions, causing unexpected disconnections and requiring manual intervention to restore normal operation. In a broader context, this could be leveraged as part of a larger attack chain to facilitate further reconnaissance or lateral movement within a home or small business network environment where such routers are commonly deployed.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically highlighting the failure to enforce proper authorization checks before allowing actions that modify system state. Additionally, it relates to CWE-754, an improper check for unusual or exceptional conditions, as the system fails to validate the source and intent of MQTT messages targeting critical functions. In terms of offensive security frameworks, this exploit technique corresponds to MITRE ATT&CK T1098, which covers Account Manipulation, particularly in contexts where access control mechanisms are bypassed to alter system configurations. It also touches upon T1496, Resource Hijacking, due to the potential for resource exhaustion through repeated metadata regeneration attacks.
Mitigation strategies should focus on immediate patching of the affected firmware version if a vendor update is available. In the interim, network segmentation can help isolate vulnerable devices from untrusted networks or users. Administrators should disable MQTT services if they are not actively required for mesh functionality, thereby removing the attack surface entirely. Additionally, implementing strict firewall rules to restrict access to internal broker ports only to trusted IP addresses can provide a layer of defense against remote exploitation. Regular audits of network configurations and monitoring for unusual MQTT traffic patterns can also aid in early detection of such attempts.