CVE-2026-18602: Unauthenticated command injection in GL.iNet GL-MT3000
TL;DR - CVE-2026-18602 is a critical unauthenticated remote command injection in GL.iNet GL-MT3000 up to 4.4.5. - The bug is exposed via
/cgi-bin/glcinovpn-client.get_recommend_config. - Public exploit details exist, so exposed devices should be restricted and patched urgently.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-18602 |
| CVSS | 9.8 Critical |
| Attack vector | Remote, network-accessible command injection |
| Privileges required | None, based on public disclosure and NVD summary |
| Patch available | Yes, but the exact fixed build is not directly verified from a first-party advisory in the available source set |
This issue affects the GL.iNet GL-MT3000 router and is notable because it appears to allow unauthenticated attackers to reach a vulnerable API path and inject shell commands as root. According to the NVD description, the vulnerable function is ovpn-client.get_recommend_config in /cgi-bin/glc, specifically within the ovpn-client.so native plugin. NVD also states that the exploit has been publicly disclosed and may be used.
For defenders, the practical meaning of a 9.8-rated router RCE is straightforward: if the management/API surface is reachable from untrusted networks, the device should be treated as high risk until mitigated. Even though CISA has not added this CVE to the Known Exploited Vulnerabilities catalog at the time of writing, the existence of public exploit material materially raises the chance of opportunistic targeting.
What Is This Vulnerability?
CVE-2026-18602 is a command injection flaw in the GL.iNet GL-MT3000 firmware’s handling of an OpenVPN client recommendation/config retrieval function. The vulnerable path is exposed through /cgi-bin/glc, using the object ovpn-client and method get_recommend_config. Public technical analysis says that attacker-controlled hostname data in the JSON request body is incorporated into shell commands without sufficient sanitization or safe execution controls.
The root cause appears to be unsafe command construction. In the public disclosure referenced by NVD, the plugin appends protocol suffixes such as .tcp or .udp to the supplied hostname, then inserts that hostname into sprintf(...)-built command strings. Those command strings are then passed to fork_exec(cmd), which ultimately calls /bin/sh -c. If the attacker injects shell metacharacters or command substitution syntax such as $(), the shell interprets and executes the payload rather than treating it as plain data.
The combination of properties makes this bug especially dangerous. First, public reporting indicates there is no authentication check before invoking the plugin handler. Second, the shell invocation occurs through sh -c, which is a classic dangerous sink when inputs are not constrained. Third, the commands reportedly execute with root privileges on the target device. That means successful exploitation is not just a denial-of-service concern; it is a full device compromise scenario.
Technical Notes
The public write-up describes a request structure similar to the following:
{
"object": "ovpn-client",
"method": "get_recommend_config",
"args": {
"group_id": 1,
"proto": 0,
"servers": [
{
"country_name": "US",
"city_name": "Test",
"hostname": ["$(id>/tmp/poc)"]
}
]
}
}
It also shows vulnerable command construction patterns like:
sprintf(uuid_path, "/tmp/ovpn_download/%s.ovpn", hostname);
sprintf(dl_path, "/tmp/curl_uuid/%s.ovpn", hostname);
if (strstr(hostname, "tcp")) {
sprintf(cmd, "touch %s; curl -LsS --connect-timeout 35 -m 20 \
https://downloads.nordcdn.com/configs/files/ovpn_tcp/servers/%s.ovpn > %s; rm -f %s",
dl_path, hostname, uuid_path, dl_path);
} else if (strstr(hostname, "udp")) {
sprintf(cmd, "touch %s; curl -LsS --connect-timeout 35 -m 20 \
https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/%s.ovpn > %s; rm -f %s",
dl_path, hostname, uuid_path, dl_path);
}
fork_exec(cmd); // /bin/sh -c
Who Is Affected?
The confirmed affected product in the available source material is GL.iNet GL-MT3000. The NVD description states that the vulnerability affects the product up to version 4.4.5. The public write-up further identifies firmware version 4.4.5 and references the firmware image openwrt-mt3000-4.4.5-0811-1691754744.tar.
Based on the available evidence, defenders should assume that all GL-MT3000 deployments running 4.4.5 or earlier are potentially vulnerable unless they can prove otherwise through vendor documentation or in-lab validation. No broader product family impact is confirmed in the supplied sources, so it would be inappropriate to extend the claim to other GL.iNet models without additional evidence.
The fix version deserves careful wording. An externally corroborated source indicates that upgrading to 4.9.0_beta3-1012-0513-1778656146 resolves the issue, but that specific fixed build was not directly verified from an official GL.iNet advisory in the available research set. Because of that, defenders should treat this as a likely remediation target rather than a fully first-party-confirmed final statement. In practice, that means checking the GL.iNet download center and release notes before broad rollout.
If you operate GL-MT3000 devices in branch offices, home-office deployments, travel kits, or SMB environments, the greatest concern is any unit with management/API access exposed beyond a trusted administrative network. A local-only device behind strict ACLs is still vulnerable, but its attack surface is materially reduced compared with internet-reachable administration.
CVSS Score Breakdown
The NVD score for CVE-2026-18602 is 9.8 (Critical). While the full vector string was not included in the supplied NVD tool output, a 9.8 score typically aligns with the highest-risk remote exploitation profile: network-reachable, low complexity, no privileges required, and high impact to confidentiality, integrity, and availability.
That general scoring pattern matches the technical details in the public disclosure. The attack is remote because it targets an HTTP CGI endpoint. The complexity appears low because the attacker only needs to submit crafted JSON to a known method with malicious input in the hostname field. The privileges requirement appears to be none because the disclosure states there is no authentication check before the plugin path is invoked. The impact is severe because execution reportedly occurs as root.
From a defender’s perspective, the most important CVSS takeaway is not the number itself but what it implies operationally: this is not a niche edge-case bug requiring a logged-in administrator or a race condition. It appears to be a straightforward pre-auth router compromise path. That justifies rapid exposure review, access control hardening, and patch planning even in the absence of confirmed mass exploitation.
CVSS also does not account for your specific deployment context. A device exposed to the public internet or reachable via untrusted Wi-Fi segments carries significantly greater practical risk than one accessible only through an isolated management VLAN. Organizations should combine the published severity with their own exposure and business-impact analysis.
Exploitation Status
Public exploit details are available. NVD explicitly states that “The exploit has been publicly disclosed and may be utilized.” The GitHub technical disclosure referenced by NVD reportedly includes root cause analysis, vulnerable call-path documentation, a crafted request example, evidence of command execution, and a Python proof-of-concept.
The available material indicates proof of successful command execution by writing output that included uid=0(root) gid=0(root) on the target system. That is a strong signal that the public research moved beyond theoretical vulnerability discussion and into practical exploitation. For defenders, the existence of public PoC material means attackers do not need to reverse engineer the bug from scratch.
At the same time, confirmed in-the-wild exploitation is not established in the provided primary sources. This CVE is not listed in CISA KEV as of 2026-08-03, and no additional authoritative reporting in the supplied material confirms active exploitation campaigns. The most accurate status statement is therefore: PoC/public exploit details exist; in-the-wild exploitation is not confirmed by CISA KEV at this time.
That distinction matters. It would be incorrect to say the vulnerability is actively exploited if the evidence is not there. But it would also be risky to downplay the issue simply because KEV does not list it. Publicly documented pre-auth router RCE flaws often attract scanning and opportunistic abuse quickly after disclosure, especially when exploitation is simple and the target is a network appliance.
How to Detect It
Detection should start with HTTP request visibility to the router’s management/API interface, especially the /cgi-bin/glc path. Requests that invoke object=ovpn-client and method=get_recommend_config deserve scrutiny, particularly when the JSON payload includes servers[].hostname values containing shell metacharacters such as $(, backticks, semicolons, &&, or pipes.
You should also inspect the device for post-exploitation artifacts in temporary directories mentioned in the disclosure. The vulnerable code path reportedly works with files under /tmp/curl_uuid/ and /tmp/ovpn_download/, and the public proof wrote command output into /tmp/poc. Unexpected files in those paths, especially those created near suspicious POST requests to /cgi-bin/glc, are useful investigative leads.
Because logging quality on embedded devices varies, defenders should collect data from multiple places: reverse proxy logs if the router is fronted by one, network IDS telemetry, EDR or shell audit if available on an adjacent management host, and direct filesystem/process inspection on the device. In the absence of comprehensive logs, assume that any exposed vulnerable device may have been probed after public disclosure.
Technical Notes
Example HTTP indicators to search for:
POST /cgi-bin/glc
"object":"ovpn-client"
"method":"get_recommend_config"
"hostname":["$(id>/tmp/poc)"]
"hostname":["*;*"]
"hostname":["*&&*"]
"hostname":["*`*`*"]
Example grep patterns if you have exported web logs or packet captures in text form:
grep -R '/cgi-bin/glc' /var/log 2>/dev/null
grep -R 'get_recommend_config' /var/log 2>/dev/null
grep -R '\$(' /var/log 2>/dev/null
grep -R 'ovpn-client' /var/log 2>/dev/null
Example Sigma-style logic for HTTP telemetry:
title: Suspicious GL.iNet GLC OVPN command injection attempt
logsource:
category: webserver
detection:
sel_path:
cs-uri-stem: "/cgi-bin/glc"
sel_body_1:
request_body|contains:
- '"object":"ovpn-client"'
- '"method":"get_recommend_config"'
sel_body_2:
request_body|contains:
- '$('
- ';'
- '&&'
- '`'
condition: sel_path and sel_body_1 and sel_body_2
level: high
Example Suricata rule concept for inspection environments where HTTP body matching is available:
alert http any any -> $HOME_NET any (
msg:"Possible CVE-2026-18602 GL.iNet GL-MT3000 exploit attempt";
flow:to_server,established;
http.uri; content:"/cgi-bin/glc";
http.request_body; content:"\"object\":\"ovpn-client\"";
http.request_body; content:"\"method\":\"get_recommend_config\"";
http.request_body; pcre:"/\"hostname\"\s*:\s*\[.*(\$\(|;|&&|`)/";
classtype:web-application-attack;
sid:42018602; rev:1;
)
Mitigation and Patching
The primary remediation is to upgrade affected GL.iNet GL-MT3000 devices off vulnerable firmware. The affected range is up to 4.4.5. A likely fixed version, based on externally corroborated but not directly first-party-verified information in the supplied research set, is 4.9.0_beta3-1012-0513-1778656146. Before wide deployment, verify the exact remediation build in GL.iNet’s official download center or release notes.
If you cannot patch immediately, reduce exposure aggressively. Restrict access to the management/API interface so that /cgi-bin/glc is reachable only from a trusted admin network or over a secured management VPN. Do not expose the router’s administration surface directly to the internet. If remote administration is necessary, front it with IP allowlisting, VPN access controls, and preferably segmentation that prevents casual reachability from user or guest networks.
You should also assume that devices exposed before mitigation may already have been tested. That means patching alone may not be enough. Review suspicious requests, inspect /tmp for artifacts, check for unexpected processes or persistence mechanisms, rotate administrative credentials if compromise is suspected, and consider reimaging or factory-resetting affected units followed by a clean firmware install if you find evidence of exploitation.
Where patch information is incomplete, a conservative defender stance is appropriate: if you are on 4.4.5 or earlier, treat the device as vulnerable; if the exact fixed build is uncertain, move to the newest vendor-supported firmware validated by release notes or vendor support, then test the vulnerable request path in a controlled environment to confirm remediation.
Technical Notes
Example upgrade workflow on an OpenWrt-derived device can vary by vendor packaging and should be validated against GL.iNet documentation. If manual image flashing is required, administrators commonly stage the firmware image and invoke sysupgrade:
# Example only: verify exact image filename from GL.iNet's official download center first
scp openwrt-mt3000-<fixed-version>.tar root@<router-ip>:/tmp/
ssh root@<router-ip> 'sysupgrade /tmp/openwrt-mt3000-<fixed-version>.tar'
If you manage upgrades from the web UI, document the exact target firmware and verify the post-upgrade version immediately after reboot. On the device shell, you can check versioning with commands such as:
cat /etc/openwrt_version
cat /etc/os-release
uname -a
Interim access-control workaround examples:
# Example firewall restriction concept: allow management only from a trusted subnet
uci add firewall rule
uci set firewall.@rule[-1].name='Restrict-GLC-Management'
uci set firewall.@rule[-1].src='lan'
uci set firewall.@rule[-1].src_ip='192.168.10.0/24'
uci set firewall.@rule[-1].dest_port='80 443'
uci set firewall.@rule[-1].proto='tcp'
uci set firewall.@rule[-1].target='ACCEPT'
uci commit firewall
/etc/init.d/firewall restart
And if external management is enabled anywhere upstream, remove internet exposure at the edge firewall immediately. A simple compensating control is often more valuable in the first hour than waiting for a maintenance window.
References
The primary public reference is the NVD record for CVE-2026-18602, which identifies the affected product, affected version range, vulnerable function, and the fact that exploit details were publicly disclosed. That record is the strongest concise summary source in the available set and should be your first stop for tracking updates to severity or metadata.
The second key source is the public GitHub technical disclosure cited by NVD. It provides the most detailed explanation of the vulnerable call flow, shell injection sink, sample exploit request, and evidence of command execution. Because it is third-party research rather than a vendor advisory, defenders should use it carefully but not ignore it; for this CVE, it is central to understanding exploitability and what to monitor.
Additional context comes from the GL.iNet download center for firmware availability and from supplementary vulnerability listings such as VulDB, though secondary aggregators should not override vendor or NVD facts. Since the exact fixed version was not directly confirmed from a first-party advisory in the supplied research set, organizations should use official GL.iNet release material to validate the final remediation target before communicating patch guidance broadly.
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-18602
- Public technical disclosure / PoC details: https://github.com/StrTzz123/iot_vul/blob/main/GL-iNet/MT3000/4.4.5/ovpn_get_recommend_config_glc_rce/CVE.md
- Raw disclosure content: https://raw.githubusercontent.com/StrTzz123/iot_vul/main/GL-iNet/MT3000/4.4.5/ovpn_get_recommend_config_glc_rce/CVE.md
- GL.iNet MT3000 download center: https://dl.gl-inet.com/router/mt3000/stable
- VulDB entry: https://vuldb.com/cve/CVE-2026-18602
For most teams, the immediate actions are clear: find GL-MT3000 devices, identify any running 4.4.5 or earlier, remove unnecessary exposure to /cgi-bin/glc, and move to a vendor-supported fixed firmware version after validating the exact build.
You can also learn more about related vulnerabilities by checking out our articles on how to detect stored XSS in admin panels and CVE-2026-21548.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.