Summary
GL.iNet GL-MT3000 routers up to firmware 4.4.5 contain a command injection flaw in the ovpn-client.get_recommend_config handler, reachable via the /cgi-bin/glc endpoint.
By manipulating the Hostname parameter, a remote attacker can inject system commands that execute with the router's web process privileges, making exposed devices highly susceptible to full compromise.
Affected context
The vulnerability exists in GL.iNet GL-MT3000 devices running firmware versions up to 4.4.5, specifically in the ovpn-client.so native plugin exposed through the /cgi-bin/glc CGI interface.
It manifests when the ovpn-client.get_recommend_config function incorporates the Hostname argument into shell-level operations without robust sanitization or strict command construction.
The issue is relevant when the router's management interface is reachable over the network (e.g., WAN access enabled, port forwarding, VPN access, or internal LAN adversaries).
Exploit preconditions
- Attack surface: HTTP(S) interface of the router, particularly requests to
/cgi-bin/glcinvokingovpn-client.get_recommend_config. - Required access: Network-level reachability to the administrative web service; authentication requirements depend on deployment configuration and any access controls in front of the endpoint.
- Trigger point: Submission of a crafted Hostname parameter that is later concatenated into or interpreted by an underlying shell command or script.
- Why exploitation is possible: User-controlled input (Hostname) is injected into command-line context without proper escaping, quoting, or use of safe subprocess APIs, allowing shell metacharacters to alter command structure.
Why this happens
At its core, this vulnerability stems from improper construction of system-level commands using untrusted input in the ovpn-client.get_recommend_config implementation.
The Hostname parameter, coming from an HTTP request, is likely concatenated into a shell command string or passed through a shell interpreter without rigorous validation and neutralization of metacharacters.
This behavior maps to CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection') and is closely related to CWE-74: Improper Neutralization of Special Elements in Output, where output that influences shell execution is not adequately sanitized.
The design flaw is treating configuration-like values as safe to embed directly in execution contexts, instead of strictly separating data from commands or using parameterized, shell-free invocation mechanisms.
Potential impact
- Remote execution of arbitrary OS commands on the router.
- Complete takeover of the device, including configuration tampering and persistence of malicious services.
- Use of the compromised router as a pivot point for attacks against internal LAN devices.
- Extraction of sensitive data, such as VPN credentials, configuration secrets, or network topology information.
- Participation of the router in botnets, DDoS campaigns, or other large-scale malicious activities.
General mitigation guidance
Effective mitigation focuses on removing the possibility for user data to influence shell interpretation and tightening trust boundaries around router management endpoints.
Recommended defensive patterns include:
- Refactor command execution paths to avoid shell parsing entirely; use APIs that pass arguments as structured lists rather than raw strings.
- Treat all web-supplied parameters, including Hostname, as untrusted and apply strict allowlists (e.g., valid hostname characters and length) rather than attempting to strip bad characters.
- Separate configuration handling from execution logic so that user-controlled values are never directly interpolated into commands or scripts.
- Apply least-privilege principles to web and plugin processes, ensuring that even if a command escapes, its ability to modify the system or network is constrained.
- Restrict and harden access to the router's administrative interface (e.g., disable WAN access, enforce strong authentication, and prefer management via VPN rather than open internet exposure).
How teams detect issues like this
Organizations and users can pursue a mix of static and dynamic techniques to detect similar command injection risks:
- Use static analysis or code review to flag any use of shell invocation APIs (e.g., system, popen, backticks) where arguments derive from HTTP parameters like Hostname without strict validation and safe argument handling.
- Review CGI or plugin code for string concatenation patterns constructing shell commands or pipelines, especially around VPN, networking, and diagnostic utilities.
- Apply security testing (DAST/fuzzing) against router web endpoints, injecting typical shell metacharacters and monitoring for abnormal behavior or error traces indicative of command execution.
- Incorporate automated policy checks in development workflows to enforce safe patterns for command execution and to prevent introduction of new CGI handlers that violate these policies.
