CVE-2026-11451: Remote Command Injection in GL.iNet GL-MT3000 Firmware
| Field | Value |
|---|---|
| CVE ID | CVE-2026-11451 |
| CVSS score | 7.3 (High) |
| Attack vector | Remote |
| Auth required | Unknown from primary vendor/NVD data; public write-up claims none |
| Patch status | Fixed in firmware 4.8.1 |
TL;DR - GL.iNet GL-MT3000 firmware 4.4.5 has a remote command injection flaw in
/cgi-bin/glc. - Upgrade affected devices to 4.8.1 and restrict exposure to management interfaces now. - Public PoC exists; in-the-wild exploitation is not confirmed.
What this vulnerability is and why it matters
CVE-2026-11451 is a command injection vulnerability affecting GL.iNet GL-MT3000 firmware version 4.4.5. According to the NVD description, the issue exists in the /cgi-bin/glc path, specifically in the FTP protocol handler through the media_dir argument. The impact is serious because attacker-controlled input can be incorporated into shell commands and ultimately executed via system().
For defenders, the practical issue is not just that a router feature is buggy. This is an edge device vulnerability on hardware that may sit at branch offices, homes, labs, or SMB environments with broad network reach. If a remote attacker can reach the vulnerable interface and the public analysis is correct about missing authentication checks, the result may be arbitrary command execution as root. On a router-class device, that can mean persistence, DNS manipulation, traffic interception, pivoting, credential theft, or use of the device in a botnet.
Exploitation status: what is known
There is public proof-of-concept material and a technical write-up on GitHub referenced by NVD. The write-up describes a request chain involving /cgi-bin/glc, the nas-web object, and the set_proto_config method, with the vulnerable payload placed in media_dir under FTP configuration.
There is no authoritative confirmation in the provided sources that exploitation is occurring in the wild. The vulnerability is not listed in CISA KEV. So the correct defender statement is: PoC exists, active exploitation is not confirmed from the available primary sources. If your environment includes internet-exposed GL-MT3000 devices, treat that as enough reason to patch urgently anyway.
Affected versions and fixed version
The confirmed affected version from the available primary-source-backed data is GL.iNet GL-MT3000 firmware 4.4.5. The fixed version is firmware 4.8.1. At the time of writing, the safest supported statement is narrow: version 4.4.5 is confirmed vulnerable, and version 4.8.1 is confirmed fixed.
It is important not to overstate the affected range. The sources provided do not establish that every version before 4.8.1 is vulnerable. They establish that 4.4.5 is vulnerable and that 4.8.1 addresses the issue. If you are running any version other than 4.4.5 or 4.8.1 and cannot verify exposure from vendor documentation, assume risk until validated, especially if the device exposes /cgi-bin/glc to untrusted networks.
Quick risk assessment for practitioners
This bug is rated CVSS 7.3 High by NVD. The full vector string was not available in the provided data, so defenders should avoid filling in missing assumptions as fact. Still, the combination of remote reachability, command injection, and a public exploit write-up makes this operationally important.
The absence of CISA KEV listing does not make this low risk. It means there is no CISA confirmation of known exploitation in the wild at this time. However, there is a public PoC and technical analysis referenced by NVD. In practice, public exploit details often lower the barrier for opportunistic attacks, especially against exposed edge devices.
How the bug works
The NVD entry says the flaw affects the function snprintf in /cgi-bin/glc within the FTP Protocol Handler, and that manipulating the media_dir argument can lead to command injection. The key security problem is that attacker input reaches a shell command construction path, then gets executed.
The public technical write-up gives a more concrete root-cause chain. It claims the request reaches a NAS service running as root, where media_dir is inserted into shell command strings and passed to system(). The example code in the write-up shows command generation similar to this:
snprintf(buf, 0x200,
"echo 'anon_root=/tmp/mountd%s' >> /etc/vsftpd.conf",
pcVar6);
system(buf);
snprintf(buf, 0x200,
"mkdir -p /home/ftp;chmod 777 -R '/tmp/mountd%s'",
pcVar6);
system(buf);
If the attacker can inject a single quote into media_dir, they can break out of the quoted string, append arbitrary shell commands, and comment out the remaining text. The write-up illustrates the general pattern with input like:
/x';<cmd>>/tmp/out 2>&1;#
That transforms a benign configuration command into a shell execution primitive. According to the vendor-supplied fix description included in NVD, firmware 4.8.1 escapes single quotes with escape_single_quote() before writing media_dir into the FTP configuration command, preventing the quoted-string break-out used by the PoC.
Technical Notes
The public write-up shows a request body shaped like this:
{
"object": "nas-web",
"method": "set_proto_config",
"args": {
"protos": [{
"name": "ftp",
"enable": 1,
"media_dir": "/codexp20';id>/tmp/nas_proto_poc 2>&1;#"
}]
}
}
The targeted endpoint is:
POST /cgi-bin/glc HTTP/1.1
Host: <target>
Content-Type: application/json
One detail requires care: the write-up claims the route may be unauthenticated, but the user supplied research note also says that point is based on the public GitHub reference rather than a vendor-authenticated statement. Defenders should therefore phrase it carefully: public analysis claims no authentication is required, but if you cannot confirm locally, assume any exposed management path is high risk and restrict access immediately.
Bottom line
CVE-2026-11451 is a high-severity remote command injection issue in GL.iNet GL-MT3000 firmware 4.4.5, fixed in 4.8.1. A public PoC exists, but active exploitation in the wild is not confirmed from the available primary sources. If you operate this model, treat internet or untrusted-network exposure as unacceptable until you have upgraded and validated access controls.
For further reading on related topics, check out our articles on VPN vs Zero Trust Network Access and How to Perform a Cybersecurity Risk Assessment.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection and hunting guidance
Start with basic exposure validation. Identify GL.iNet GL-MT3000 devices and determine which are running firmware 4.4.5. Then determine whether /cgi-bin/glc is reachable from the internet, partner networks, guest segments, or any untrusted internal VLANs. In many SMB and branch setups, exposure of router management interfaces is accidental rather than intentional.
After scoping exposure, hunt for evidence of exploitation attempts. The public PoC uses HTTP POST requests to /cgi-bin/glc with JSON keys such as "object":"nas-web"**, **“method”:”set_proto_config”, and **"media_dir"**. Payloads are likely to contain shell metacharacters such as single quotes, semicolons, redirection operators, and#` comments. Even failed exploit attempts may leave log or config artifacts.
Technical Notes
A practical web or reverse-proxy log pattern to search for is a POST to the vulnerable path with JSON references to FTP configuration:
POST /cgi-bin/glc
"object":"nas-web"
"method":"set_proto_config"
"media_dir":
"name":"ftp"
Example grep for exported logs:
grep -R -E 'POST /cgi-bin/glc|set_proto_config|media_dir|nas-web|"name":"ftp"' /var/log
Example Sigma-style logic for HTTP logs:
title: GL.iNet GL-MT3000 glc FTP config command injection attempt
logsource:
category: webserver
detection:
selection_path:
cs-uri-stem: "/cgi-bin/glc"
cs-method: "POST"
selection_body:
request_body|contains:
- '"object":"nas-web"'
- '"method":"set_proto_config"'
- '"media_dir"'
selection_injection:
request_body|contains:
- "';"
- "2>&1"
- "#"
condition: selection_path and selection_body and 1 of selection_injection
level: high
If you have packet capture or IDS coverage, flag POSTs to /cgi-bin/glc containing JSON strings with both media_dir and shell metacharacters:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80,443 (
msg:"Possible GL.iNet GL-MT3000 CVE-2026-11451 exploit attempt";
flow:to_server,established;
content:"POST"; http_method;
content:"/cgi-bin/glc"; http_uri;
content:"media_dir"; http_client_body;
pcre:"/media_dir.{0,120}[';#]|2>&1/smi";
sid:2026114511;
rev:1;
)
Also inspect the device for suspicious outcomes, such as unexpected files in /tmp, altered FTP configuration, or unexplained process execution. The public PoC writes markers to temporary locations; attackers may adapt that behavior, but any recent anomalous file creation around exploit timing is worth investigating.
Mitigation and patching
The primary remediation is clear: upgrade GL.iNet GL-MT3000 from firmware 4.4.5 to firmware 4.8.1 or later. The vendor-supplied fix description states that version 4.8.1 escapes single quotes in the vulnerable code path and that similar payloads no longer triggered command execution during verification.
If you cannot patch immediately, reduce exposure as aggressively as possible. Block access to /cgi-bin/glc and router administration interfaces from untrusted networks. Disable external administration if it is enabled. Limit access to a dedicated management VLAN or a VPN-only path. Because public analysis suggests root-level command execution may be possible, incident response should include integrity review, credential rotation, and configuration validation on any device that was exposed while vulnerable.
Technical Notes
Where shell access is available, first confirm current firmware version before changing anything:
cat /etc/os-release 2>/dev/null
uname -a
Because GL.iNet firmware management commands can vary by build and model, a universal CLI upgrade command is not confirmed in the provided sources. Defenders should therefore use the vendor-supported firmware upgrade workflow for the GL-MT3000 and validate that the resulting installed version is 4.8.1 or later. In the absence of a confirmed CLI method, the safe workaround is to remove exposure:
# Example temporary block for web management from WAN-facing interface
iptables -I INPUT -i wan -p tcp --dport 80 -j DROP
iptables -I INPUT -i wan -p tcp --dport 443 -j DROP
If remote management is controlled upstream, apply ACLs there instead. For example, only allow admin access from a bastion or VPN subnet and deny all other sources. After patching, retest reachability and confirm the vulnerable endpoint is not unnecessarily exposed.
Validation after remediation
After upgrading, verify that the device is actually on firmware 4.8.1 or later and not merely staged for update. Then test that your management plane is restricted as intended. From outside approved admin networks, requests to the web interface should fail or be filtered.
Finally, review historical logs for prior exploit attempts. Because a command injection flaw can lead to persistence, patching alone may not be enough if compromise occurred before the upgrade. Look for unauthorized startup changes, suspicious cron entries if present, unexplained firewall or DNS changes, and any modifications to FTP-related configuration files.
References
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-11451
- Public technical write-up / PoC: https://github.com/StrTzz123/iot_vul/blob/main/GL-iNet/MT3000/4.4.5/nas_proto_media_dir_glc_rce/Readme.md
- CISA KEV Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog