Summary
GL.iNet GL-MT3000 routers up to firmware 4.4.5 contain a command injection flaw in the ovpn-client.check_config handler within the native ovpn-client plugin.
By manipulating the filename argument sent to the /cgi-bin/glc endpoint, a remote attacker can inject system commands, leading to full device compromise when the vulnerable code path is invoked.
Affected context
The vulnerability occurs in GL.iNet GL-MT3000 devices running firmware versions up to 4.4.5 that expose the ovpn-client functionality via the /cgi-bin/glc interface.
It is relevant in deployments where the router's web or API interface is reachable and processes filename parameters through ovpn-client.check_config.
The risk increases when this interface is accessible from untrusted networks or when users or scripts can supply arbitrary filename values without strict validation.
Exploit preconditions
- Attack surface: HTTP requests to the /cgi-bin/glc endpoint on the GL-MT3000 router, specifically invoking ovpn-client.check_config.
- Required access: Ability to send requests that control the filename argument (authentication requirements depend on router configuration and management UI exposure).
- Trigger point: Processing of the filename parameter by the ovpn-client.so native plugin, where its value is incorporated into shell commands.
- Why exploitation is possible: User-controlled data is concatenated into command-line invocations without adequate sanitization or neutralization, enabling injection of arbitrary shell metacharacters and commands.
Why this happens
This issue stems from unsafe command construction in native plugin code, where the filename parameter is treated as trusted input and directly embedded into shell commands.
The behavior maps to CWE-77: Command Injection and CWE-74: Injection, since external input is incorporated into command strings without proper escaping, whitelisting, or structured APIs.
Conceptually, instead of using parameterized or API-based operations, the implementation relies on building command lines from raw strings, allowing attackers to extend or replace intended commands with their own instructions.
Potential impact
- Remote execution of arbitrary commands on the router operating system.
- Complete compromise of the device, including configuration and stored credentials.
- Modification of firewall, VPN, and routing rules, enabling traffic interception or redirection.
- Use of the router as a pivot point for attacks against internal network hosts.
- Deployment of persistent malware or involvement of the router in botnet activity.
General mitigation guidance
Effective mitigation focuses on removing direct string-based command construction and reducing trust in user-supplied arguments.
Recommended design patterns include:
- Replacing shell invocation with library or system APIs that accept structured parameters rather than raw command strings.
- Applying strict allowlists for acceptable filename values and rejecting or normalizing any input containing shell metacharacters or unexpected paths.
- Separating user input from execution contexts by avoiding shell interpretation entirely, using safe process execution primitives.
- Running router services with least-privilege accounts and minimizing the number of exposed management interfaces to limit impact if command injection paths exist.
- Introducing centralized validation routines for parameters used by native plugins, ensuring consistent sanitization before any system-level interaction.
How teams detect issues like this
Detection commonly involves:
- Static analysis rules that flag concatenation of user-controlled parameters into command strings or calls to shell execution functions within router code and native plugins.
- Targeted code review of CGI handlers and VPN-related components, looking for unchecked use of filename or path parameters in system(), popen(), exec*, or equivalent functions.
- Runtime monitoring on devices for atypical command executions, unexpected processes spawned by management interfaces, or anomalies in VPN and firewall configurations.
- Policy-based security checks in the development pipeline that prohibit direct shell command construction with external input and require use of safe wrappers or APIs.
