Summary
GL-iNet GL-MT3000 routers contain a command injection flaw in the wg-server native plugin, where the public_key parameter to server.set_peer is unsafely handled.
An attacker who can send crafted requests to the /cgi-bin/glc endpoint may execute arbitrary system commands on the device, making any exposed management interface a high-risk target.
Affected context
The vulnerability appears in GL-iNet GL-MT3000 devices running firmware versions up to 4.4.5 that expose the /cgi-bin/glc endpoint using the wg-server.so native plugin.
It affects scenarios where the router's web administration or related APIs are reachable to an attacker, such as from the local network, VPN, or improperly exposed WAN interfaces.
The flaw is triggered when the server.set_peer function processes user-supplied public_key values that are later incorporated into command execution without proper sanitization.
Exploit preconditions
- Attack surface: HTTP(S) interface providing access to
/cgi-bin/glcon the GL-MT3000 router. - Required access: Ability to send HTTP requests to the router's management or API interface (local network, authenticated session, or exposed WAN, depending on deployment).
- Trigger point: Invocation of
server.set_peerwith a craftedpublic_keyparameter that injects shell metacharacters or additional command segments. - Why exploitation is possible: The implementation appears to construct shell commands or invoke system utilities using unvalidated
public_keydata, causing it to be interpreted by the command interpreter (shell) instead of being treated as inert input.
Why this happens
This issue stems from improper neutralization of user-controlled input before it is used in a command execution context, a classic command injection pattern.
The public_key argument in server.set_peer is likely concatenated or interpolated directly into a shell command, or passed to a system execution API that invokes a shell, without robust quoting, escaping, or avoiding shell interpretation entirely.
This behavior maps to:
- CWE-77: Command Injection, where input is not correctly sanitized, allowing attackers to inject additional commands.
- CWE-74: Improper Neutralization of Special Elements, because special characters (such as
;,&&,|) are not neutralized and thus alter the structure of the command being executed.
The abstract insecure pattern is: user-supplied data flowing into a command-line string or shell context, with the shell responsible for interpreting that string, rather than using APIs that separate code from data.
Potential impact
- Remote execution of arbitrary commands on the GL-MT3000 router's operating system.
- Full compromise of router configuration, including manipulation of VPN, firewall, and routing rules.
- Extraction of sensitive information, such as VPN keys, Wi-Fi credentials, or stored tokens.
- Use of the router as a pivot point for attacking other devices on the local network.
- Deployment of persistent malware or backdoors on the router, enabling long-term unauthorized access.
- Participation of compromised routers in wider botnets or distributed attacks.
General mitigation guidance
Long-term resilience against this class of bug comes from eliminating shell-dependent command construction and enforcing strong separation between user input and executable logic.
Common defensive patterns include:
- Avoiding use of shell-interpretive APIs (e.g., generic system command strings) and instead using parameterized or structured APIs (e.g., exec-family calls with argument arrays) that do not invoke a shell.
- Applying strict validation and normalization to parameters like
public_key, enforcing expected formats (length, character set, encoding) and rejecting any input that deviates. - Centralizing input handling for router management APIs, so that command-line relevant parameters are uniformly sanitized and constrained.
- Running management plugins and auxiliary services with least-privilege identities and restricted capabilities, reducing the blast radius if a command is compromised.
- Designing plugin interfaces such that configuration changes operate on data structures or configuration files, not through dynamically constructed shell commands.
How teams detect issues like this
Detection typically relies on identifying both the insecure coding pattern and anomalous runtime behavior.
High-level approaches include:
- Static analysis: Define rules to flag uses of system command APIs (e.g.,
system,popen,exec*with"/bin/sh -c"patterns) where user input, including parameters likepublic_key, can reach the command string. - Code review cues: During manual review of router management and native plugin code, look for string concatenation or formatting involving user data that feeds into shell or command-line utilities, especially for network-exposed handlers.
- Configuration and policy checks: Enforce secure coding guidelines that disallow shell-based command composition in web-CGI handlers and native plugins, and require validation functions for all externally reachable parameters.
- Runtime monitoring: Use logging or telemetry (where available) to detect abnormal command executions or unexpected arguments being passed from CGI handlers, and correlate with suspicious requests.
- Automated security scanners and SAST tools can be configured to focus on CGI binaries and native modules that process HTTP parameters, highlighting potential command injection flows early in development or QA.
