CVE-2026-51748 in TOTOLINK
Summary
by MITRE • 09/01/2026
Incorrect access control in the sendStaticInfoToMaster function of TOTOLINK T6 4.1.5cu.748_B20211015 allows unauthenticated attackers to update stored slave inventory records via sending a crafted MQTT message to the cs_broker component.
If you want to get the best quality for vulnerability data then you always have to consider 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 device's internal communication architecture. Specifically, the flaw resides in the sendStaticInfoToMaster function, which is responsible for handling data transmission between slave components and the master controller or broker system. This component interacts with an MQTT (Message Queuing Telemetry Transport) broker service known as cs_broker, a common protocol used in Internet of Things devices for lightweight publish-subscribe messaging. The core issue stems from the absence of proper authentication checks when processing incoming messages intended to update stored slave inventory records. Consequently, any actor capable of reaching the network interface hosting this MQTT service can interact with these functions without providing valid credentials or security tokens.
From a technical perspective, this vulnerability is classified under CWE-269, which denotes Improper Privilege Control, and more specifically aligns with CWE-862 regarding Missing Authorization. The attacker exploits the lack of input validation and access verification by crafting specific MQTT messages that mimic legitimate inventory update requests. Because the system does not verify the identity or permissions of the sender before executing the write operation on the slave inventory database, malicious actors can inject false data into the device's configuration state. This manipulation allows for unauthorized modification of critical operational parameters, potentially altering how the router identifies and manages connected devices within its network topology.
The operational impact of this vulnerability is significant due to the potential for both denial of service and further lateral movement within a local area network. By updating slave inventory records with crafted data, an attacker can disrupt normal routing operations, cause instability in device discovery processes, or hide malicious devices from legitimate management interfaces. Furthermore, if these inventory records are used by higher-level security policies or firewall rules to determine trust levels for connected endpoints, manipulating them could allow unauthorized devices to bypass network segmentation controls. This creates a pathway for attackers to establish persistent footholds within the internal network, facilitating subsequent attacks such as data exfiltration or ransomware deployment against other vulnerable systems on the same subnet.
In terms of threat modeling and adversary behavior, this exploitation technique corresponds to ATT&CK tactic T1078, specifically Valid Accounts, although in this case it involves impersonating a valid service account without actual credentials due to the authentication bypass. It also relates to T1562, Impair Defenses, as modifying inventory records can obscure detection mechanisms that rely on accurate asset lists. The attack vector is classified as Network-based (T1078) and requires low complexity with no user interaction, making it highly attractive for automated scanning tools targeting exposed IoT devices.
Mitigation strategies must focus on immediate remediation of the access control logic within the cs_broker component. Firmware updates provided by TOTOLINK that patch this specific CVE should be applied immediately to restore proper authentication checks before processing MQTT messages destined for inventory management functions. In environments where updating firmware is not immediately feasible, network-level controls such as firewall rules restricting inbound traffic on the MQTT port (typically 1883 or 8883) to only trusted internal IP addresses can serve as a compensating control. Additionally, implementing mutual TLS authentication for all MQTT communications ensures that both client and server verify each other's identities before any data exchange occurs, effectively neutralizing this specific vector of unauthorized access.