Skip to main content

Free 30-min security demo  — We'll scan your real code and show live findings, no commitment Book Now

Offensive360
ZeroDays CVE-2023-50921
Critical CVE-2023-50921 CVSS 9.8 GL.iNet C/Shell

Unauthenticated Privilege Escalation in GL.iNet Router Management Interface

CVE-2023-50921 exposes critical pre-authentication privilege escalation in GL.iNet routers through unsafe add_user API endpoint, affecting 12 device models across firmware versions 4.3.7-4.5.0.

Offensive360 Research Team
Affects: 4.3.7 through 4.5.0
Source Code

Overview

CVE-2023-50921 represents a critical privilege escalation vulnerability affecting GL.iNet’s widely-deployed router firmware. The vulnerability exists in the system module’s add_user interface, which fails to properly validate authentication and authorization before processing user creation requests. Security researchers discovered that unauthenticated attackers can directly invoke this API endpoint to create administrative accounts and gain root-level access to affected devices without any prior authentication.

This vulnerability impacts twelve distinct GL.iNet router models spanning three firmware versions: 4.3.7, 4.4.6, and 4.5.0. Affected devices include the AR series (AR300M, AR750, AR750S), MT series (MT1300, MT2500, MT3000, MT6000), AX/AXT series (AX1800, AXT1800), and legacy models (A1300, B1300). With a CVSS v3.1 base score of 9.8, this vulnerability qualifies as Critical, requiring immediate patching across all affected installations. The attack surface is particularly concerning given that many GL.iNet devices are deployed as primary network gateways in enterprise and residential environments with direct internet exposure.

Technical Analysis

The vulnerability stems from improper access control in the system module’s user management functionality. The add_user API endpoint fails to implement authentication checks before processing requests, allowing any network-accessible attacker to invoke the interface regardless of their privilege level or authentication status.

Vulnerable Code Pattern:

# Simplified representation of vulnerable endpoint
/api/system/add_user
{
  "username": "attacker",
  "password": "malicious_pass",
  "group": "root"
}

The endpoint accepts parameters directly without:

  • Verifying the requester’s session token or authentication state
  • Validating the requesting user’s authorization level
  • Implementing rate limiting or request throttling
  • Sanitizing or validating group assignments

Attack Flow:

An attacker can craft an HTTP POST request to the vulnerable endpoint with administrative group parameters. The system processes the request without authentication verification and creates a new user account with root privileges. Subsequently, the attacker authenticates using these newly created credentials to gain complete administrative control.

# Example attack payload
POST /cgi-bin/luci/api/system/add_user HTTP/1.1
Host: 192.168.8.1
Content-Type: application/json

{
  "username": "backdoor_admin",
  "password": "pwned123",
  "group": "root",
  "email": "[email protected]"
}

The root cause is the absence of authentication middleware in the router’s API framework. Most GL.iNet endpoints should enforce session validation before processing administrative operations. Instead, this endpoint was exposed without any gatekeeping mechanism, treating unauthenticated requests identically to authenticated ones.

Affected CWE Classifications:

  • CWE-287: Improper Authentication
  • CWE-306: Missing Authentication for Critical Function
  • CWE-352: Cross-Site Request Forgery (CSRF) - secondary aspect
  • CWE-269: Improper Access Control - Generic

Impact

The implications of this vulnerability extend beyond simple account creation. An unauthenticated remote attacker can:

Immediate Exploitation:

  • Create administrative user accounts without existing credentials
  • Gain root shell access to the router’s operating system
  • Execute arbitrary commands with the highest privilege level
  • Modify firewall rules, DNS settings, and routing tables
  • Deploy persistent backdoors or malware

Extended Compromise:

  • Intercept and manipulate network traffic from connected devices
  • Perform man-in-the-middle (MITM) attacks on corporate VPNs
  • Harvest Wi-Fi credentials and client data
  • Use compromised routers as botnet nodes or attack relay points
  • Exfiltrate sensitive data transiting the network

Business Impact: Enterprise deployments relying on GL.iNet routers for branch office connectivity, remote site management, or IoT gateway functions face complete network compromise. The absence of authentication requirements makes this vulnerability trivial to exploit at scale—requiring only network reachability to the device’s management interface.

How to Fix It

GL.iNet released patched firmware versions addressing this vulnerability. Immediate action is required:

For End Users:

  1. Identify affected devices by checking firmware version in System Settings → About
  2. Upgrade firmware immediately to patched versions:
    • AR/MT legacy devices: Update to 4.3.8 or later
    • Mid-range devices: Update to 4.4.7 or later
    • Recent models: Update to 4.5.1 or later
  3. Access web interface at 192.168.8.1 (default)
  4. Navigate to System → Firmware Upgrade
  5. Download and install latest firmware from official GL.iNet servers

For Network Administrators:

# Verify current firmware version via SSH
ssh [email protected]
cat /etc/os-release | grep VERSION

# After patching, verify security hotfix is applied
cat /etc/os-release | grep PATCH_VERSION

Patched Code Example:

The corrected implementation includes authentication middleware:

// Authentication middleware applied before add_user endpoint
int authenticate_request(struct request *req) {
    char *session_token = get_request_header(req, "X-Session-Token");
    
    if (!session_token || !validate_session(session_token)) {
        return UNAUTHORIZED;
    }
    
    struct user *current_user = get_authenticated_user(session_token);
    if (!current_user || current_user->privilege_level < ADMIN) {
        return FORBIDDEN;
    }
    
    return OK;
}

// Handler with proper access control
int handle_add_user(struct request *req) {
    // Verify authentication before processing
    if (authenticate_request(req) != OK) {
        return HTTP_401_UNAUTHORIZED;
    }
    
    // Validate input parameters
    validate_username(req->username);
    validate_password(req->password);
    
    // Restrict group assignment to lower privileges
    if (strcmp(req->group, "root") == 0) {
        return HTTP_403_FORBIDDEN;
    }
    
    // Process user creation
    return create_user(req->username, req->password, req->group);
}

Our Take

This vulnerability exemplifies a critical gap in API security maturity—the failure to apply consistent authentication checks across all endpoints, regardless of perceived risk. In embedded router firmware, where development cycles are often rapid and security review processes less rigorous than enterprise software, such oversights propagate easily.

The incident reflects a broader industry pattern: developers implementing administrative interfaces sometimes assume “because it’s on the router, it must be protected” without explicitly enforcing authentication. Network-adjacent access is not equivalent to authenticated access.

Our recommendations for enterprises:

  1. Inventory all GL.iNet deployments immediately and prioritize patching based on internet exposure
  2. Implement network segmentation to restrict management interface access to authorized administrative networks
  3. Monitor router logs for suspicious account creation or API requests to /api/system/ endpoints
  4. Enforce strong default credentials and change default passwords on all network infrastructure
  5. Deploy SAST scanning in router firmware development to catch missing authentication checks before release

Vendors must establish automated security testing that flags administrative API endpoints lacking authentication decorators. This is a pattern-detectable issue that should never reach production.

Detection with SAST

Static Application Security Testing tools detect this vulnerability through multiple analysis techniques:

Pattern-Based Detection:

  • Identifying HTTP endpoint handlers without preceding authentication middleware
  • Flagging API routes that process sensitive operations (user creation, privilege modification) without session validation
  • Detecting missing @authenticate decorators, check_auth() function calls, or equivalent authorization barriers

CWE-306 (Missing Authentication for Critical Function) Detection: SAST engines scan for functions that modify system state without authentication checks. The add_user endpoint represents a “critical function” as defined by CWE-306 because it grants administrative privileges.

Data Flow Analysis: Advanced SAST tools trace user-supplied input from HTTP request parameters directly to system calls (e.g., useradd, passwd, group modifications) without intervening authentication validation. Any direct flow from request to privilege-modifying system call raises high-severity findings.

Offensive360’s approach flags:

  • API handlers instantiated without authentication middleware in the call chain
  • Group/privilege parameters accepted from untrusted request sources
  • Absence of session token validation before administrative operations
  • Hardcoded bypass paths or undocumented administrative interfaces

References

#privilege-escalation #authentication-bypass #api-vulnerability #embedded-systems #router-security

Detect this vulnerability class in your codebase

Offensive360 SAST scans your source code for CVE-2023-50921-class vulnerabilities and thousands of other patterns — across 60+ languages.