Summary
A critical OS command injection weakness in the TOTOLINK N150RT Web Management Interface allows crafted input in the wlanif argument to reach the system function. Because the affected interface is remotely reachable, an attacker may execute commands on the router when the vulnerable request path is accessible.
Affected context
The issue occurs in the Web Management Interface function /boafrm/formWlSiteSurvey of TOTOLINK N150RT 3.4.0-B20201030. Risk is present when the wlanif parameter is incorporated into an operating-system command without adequate separation, validation, or neutralization, and the management interface can be reached by an attacker.
Exploit preconditions
- Attack surface: The router's remotely reachable Web Management Interface - Required access: Network access to the affected management request; whether
authentication is required depends on the device's access-control settings
- Trigger point: Processing of the wlanif argument by the wireless site survey
functionality
- Why exploitation is possible: User-controlled data can influence execution
of a system command rather than remaining a constrained data value
Why this happens
The underlying bug is command construction that allows externally controlled input to cross into an operating-system command execution API. When shell metacharacters or command syntax are not excluded through safe argument handling, the input may be interpreted as additional commands. This maps primarily to CWE-78, Improper Neutralization of Special Elements used in an OS Command, and is also related to CWE-77, Improper Neutralization of Special Elements in Command.
Potential impact
- An attacker may execute arbitrary commands on the router.
- The device could be fully compromised or rendered unavailable.
- Network traffic, credentials, or configuration data could be exposed.
- The router may be used for persistence, lateral movement, or attacks against other systems.
General mitigation guidance
Mitigation generally centers on removing shell interpretation from request handling and reducing trust in management-interface input. Secure-by-default patterns include invoking programs through APIs that pass fixed argument arrays, avoiding shell-based command construction, applying strict allowlist validation to interface identifiers, and separating data from executable context. Management services can be isolated from untrusted networks, exposed only through controlled administration paths, and operated with the least privileges needed for their functions. Configuration and access policies should also limit who can reach wireless survey operations.
How teams detect issues like this
Detection can include static-analysis rules for system, shell, process, or command-spawning APIs that receive request parameters, along with taint analysis from HTTP handlers into process execution. Code review should flag string concatenation or formatting used to build shell commands and weak validation of parameters such as wlanif. Runtime monitoring can alert on unexpected process creation by the web-management service, while network policy checks can identify management interfaces exposed beyond intended administration networks. Automated security review tools may help identify these patterns during development.
