Summary
A high-severity command injection vulnerability in the GL.iNet AX1800 RPC endpoint allows attacker-controlled input supplied through the args.id argument to influence command execution.
Because the affected RPC function may be reachable remotely, an attacker who can access the endpoint could potentially execute operating-system commands with the privileges of the service.
Affected context
The vulnerability occurs in the remove_rule function within /usr/share/gl-ngx/oui-rpc.lua, which is used by the device's RPC endpoint. It becomes risky when the endpoint accepts externally influenced values for args.id and incorporates them into an operating-system command without sufficiently separating data from command syntax. Exposure depends on network access controls, authentication, and the device's RPC configuration.
Exploit preconditions
- Attack surface: The GL.iNet AX1800 RPC endpoint
- Required access: Network reachability to the affected endpoint; authentication requirements depend on device configuration
- Trigger point: Processing of the
args.idargument by theremove_rulefunction - Why exploitation is possible: Insufficient separation between untrusted input and command construction may allow input to alter the intended command
- Exposure factor: Devices running affected software and exposing the RPC interface to an attacker are at greater risk
Why this happens
The underlying bug is an OS command injection flaw caused by using externally influenced input in command execution without adequate validation, escaping, or argument separation. This maps primarily to CWE-77: Improper Neutralization of Special Elements used in a Command, with the broader CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component also applicable. The insecure pattern is treating an RPC parameter as a trusted command component rather than as ordinary data.
Potential impact
- An attacker may execute arbitrary operating-system commands
- The device could be compromised with the privileges of the vulnerable service
- Network configuration, firewall rules, or device settings could be altered
- Sensitive information stored on the router may be exposed
- The device could be used for lateral movement or further attacks
General mitigation guidance
Mitigation generally focuses on removing shell interpretation from request handling and reducing trust in RPC parameters.
Common defensive patterns include:
- Replacing shell command construction with direct APIs or structured process invocation
- Treating
args.idas a typed identifier and enforcing strict allowlist validation - Separating command arguments from command names rather than concatenating strings
- Restricting RPC exposure to trusted management networks and enforcing authentication
- Running management services with only the privileges they require
- Applying defense-in-depth controls such as firewalling and service isolation
How teams detect issues like this
Organizations can look for command injection risks through:
- Static analysis rules identifying shell execution APIs that receive RPC or HTTP-derived values
- Code review checks for string concatenation or interpolation in command-building paths
- Searches for unsanitized request parameters reaching shell interpreters or process-spawning functions
- Runtime monitoring for unexpected process creation by the RPC service
- Network and access-control policy checks ensuring management endpoints are not broadly exposed
- Automated security review tools that flag data flows from request parameters to command execution
