CVE-2026-11450: Remote Command Injection in GL.iNet GL-MT3000

Detection and investigation guidance

Start with the basics: identify GL-MT3000 devices, enumerate firmware versions, and assess whether the HTTP management or RPC interface is reachable from untrusted networks. If you find firmware 4.4.5, treat the asset as exposed to this CVE until it is upgraded or access is restricted. If the router is managed remotely, confirm whether access to /rpc is limited to a trusted admin network or VPN.

Next, review available web server, reverse proxy, firewall, and network telemetry for requests targeting /rpc, especially those referencing nas-web.eject_disk, unusual dev_name values, or malformed parameter sequences. The vendor mitigation note says that in 4.7, direct calls to that method through the default endpoint return Invalid params. That response can be useful both as a validation signal after patching and as a clue during retrospective investigation.

Detection will vary based on how much logging the device itself exposes. In many SMB and edge-router environments, the most useful telemetry may come from upstream firewalls, SPAN captures, or a reverse proxy if one sits in front of administrative access. If the device logs process execution, shell invocation, or RPC handler errors, inspect those records for evidence of unexpected command execution flowing from web requests.

Technical Notes

Example network and log hunting patterns

Look for HTTP requests to /rpc with references to the suspicious method name:

POST /rpc HTTP/1.1
Host: <router>
Content-Type: application/json

{"method":"nas-web.eject_disk","params":{"dev_name":"<suspicious input>"}}

Simple grep-style searches for exported logs or reverse-proxy records:

grep -R '/rpc' /var/log 2>/dev/null
grep -R 'nas-web.eject_disk' /var/log 2>/dev/null
grep -R 'Invalid params' /var/log 2>/dev/null

Example Splunk search for web logs:

index=network OR index=web
("/rpc" AND "nas-web.eject_disk")
OR ("/rpc" AND "dev_name")
OR ("Invalid params" AND "/rpc")

Example Sigma-style concept for proxy or web logs:

title: GL.iNet MT3000 Suspicious RPC Method Access
logsource:
  category: webserver
detection:
  sel1:
    cs-uri|contains: "/rpc"
  sel2:
    cs-uri-query|contains:
      - "nas-web.eject_disk"
      - "dev_name="
  condition: sel1 and sel2
level: high

If you capture packet data, a lightweight signature concept is to alert on JSON bodies containing both /rpc and nas-web.eject_disk. Exact wire signatures should be tuned locally to avoid false positives and account for encryption or proxy termination points.

Mitigation and patching

The primary remediation is to upgrade GL.iNet GL-MT3000 devices from firmware 4.4.5 to firmware 4.7. That is the fixed version explicitly identified in the available material. The vendor-confirmed behavior change is important: from version 4.7 onward, method-level validation is enabled at the HTTP /rpc layer, and nas-web.eject_disk is no longer in the whitelist of allowed methods. Direct calls should return Invalid params, which blocks the known exploit chain.

If you cannot patch immediately, reduce attack surface first. Restrict access to the management interface and /rpc endpoint to trusted administrative networks only. Remove any internet exposure, require VPN-based administration, and use firewall rules to limit source IPs. Because the exact authentication requirements are not confirmed in the available record, defenders should not assume that existing admin login controls are sufficient compensating controls.

A good mitigation plan has three parallel tracks: patch, isolate, validate. Patch vulnerable firmware. Isolate the management plane from untrusted networks. Then validate behavior after the change by confirming that direct invocation of the previously reachable method no longer works as it did before. Also review credentials and device integrity if there is any sign of prior probing or suspicious requests, because command injection raises the possibility of persistent changes.

Technical Notes

Upgrade and validation workflow

Exact GL.iNet upgrade steps can vary by deployment and whether devices are managed through the web UI or CLI. If you use the underlying OpenWrt-style shell for verification, start by checking the current version:

cat /etc/openwrt_release
uname -a

If your operational process uses the web interface, upload or select firmware 4.7 for the GL-MT3000 and complete the vendor-supported upgrade flow. If you manage images manually on a maintenance bench, follow vendor documentation for the specific hardware revision before issuing any flash command. Do not guess firmware paths or use generic OpenWrt flashing steps unless you have confirmed they apply to this device model and image format.

As a workaround when immediate upgrade is not possible, block access to the management endpoint from untrusted sources. Example upstream firewall controls:

# Example only: restrict HTTPS admin access to a trusted subnet
iptables -A INPUT -p tcp --dport 443 ! -s 10.0.10.0/24 -j DROP

# Example only: restrict HTTP admin access if enabled
iptables -A INPUT -p tcp --dport 80 ! -s 10.0.10.0/24 -j DROP

Post-upgrade, validate that the dangerous RPC path is no longer reachable through the default endpoint:

curl -sk https://<router>/rpc \
  -H 'Content-Type: application/json' \
  -d '{"method":"nas-web.eject_disk","params":{"dev_name":"test"}}'

Based on the vendor statement quoted in the NVD record, a remediated system should return behavior consistent with:

Invalid params

If the endpoint still accepts the method without that rejection behavior, treat the device as not fully remediated and re-check firmware level, image provenance, and exposure.

References

The primary references for this CVE are:

For practitioners, the bottom line is clear: if you run GL.iNet GL-MT3000 firmware 4.4.5, move to 4.7 as soon as operationally feasible, restrict /rpc exposure, and review logs for requests targeting nas-web.eject_disk or suspicious dev_name values. Even without confirmed in-the-wild exploitation, the combination of remote attackability and a public PoC is enough to justify immediate action.

For further understanding, you may want to check our articles on what is an indicator of compromise and risk management in cybersecurity.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.