[CVE-2025-15101] Command Injection in AsusWRT Firmware

This research was covered by PCGamer.

Summary

We reported three vulnerabilities to ASUS in late 2025: a command injection, a reflected XSS, and an information disclosure. Testing was performed on the ASUS ZenWiFi BT8, but the command injection (CVE-2025-15101) exists in the shared AsusWRT httpd binary and affects all ASUS routers running firmware version 3.0.0.6_102 and earlier. The vulnerable endpoint appears to have been present in the firmware for years.

Background

Consumer routers are common targets that rarely receive the same scrutiny as enterprise equipment. ASUS routers are fairly ubiquitous on the consumer market, sold through Telia, among other ISPs. A popular model is the ASUS ZenWifi BT8, so we picked one up running stock firmware.

The highest severity finding was not specific to this model. The vulnerable code lives in the shared AsusWRT firmware platform and affects a wide range of ASUS routers.

Methodology

We mapped the router's attack surface and moved to static analysis. ASUS publishes their firmware source code, so we focused on the httpd binary, the web server behind the management interface and the main handler for user input.

Command Injection in /dns_ping.cgi (CVE-2025-15101)

Finding the sink

We traced calls to dangerous sinks in httpd back to user input. One stood out. Below is the decompiled function in Ghidra, cleaned up for readability:

The function reads user input via get_request_param_string from the dns_ping_list parameter and passes it to the dns_ping binary. The first highlighted line is the injection point: user-controlled data concatenated into a string and passed to system().

Cross-references

Ghidra's cross-reference feature shows no callers of this function other than the HTTP routing table.

The function is not referenced anywhere in the UI code, but it is still registered as the handler for /dns_ping.cgi:

The endpoint responds with 200 OK.

The dns_ping binary

The dns_ping binary in /usr/sbin/ does not produce usable output:

Monitoring the process list after hitting the endpoint (watch -n 1 "ps | grep dns_ping") shows what it attempts to do:

shsh -c ping -c 5 -W 1 1.1.1.1 > /tmp/dns_ping_result/1.1.1.1 2>&1 || true && echo "" >> /tmp/dns_ping_resu..
sh -c ping -c 5 -W 1 1.0.0.1 > /tmp/dns_ping_result/1.0.0.1 2>&1 || true && echo "" >> /tmp/dns_ping_resu..
sh -c ping -c 5 -W 1 8.8.8.8 > /tmp/dns_ping_result/8.8.8.8 2>&1 || true && echo "" >> /tmp/dns_ping_resu..
sh -c ping -c 5 -W 1 8.8.4.4 > /tmp/dns_ping_result/8.8.4.4 2>&1 || true && echo "" >> /tmp/dns_ping_resu..
sh -c ping -c 5 -W 1 168.95.1.1 > /tmp/dns_ping_result/168.95.1.1 2>&1 || true && echo "" >> /tmp/dns_pin..

It pings a list of well-known DNS servers and writes results to a log file. The ASUS web UI already has a working ping feature under Network Tools. dns_ping appears to be an earlier implementation that was superseded but never removed. The endpoint remained registered and the system() call remained unsanitized. The code first appears in ASUS GPL release 388_20566 from late 2022.

Exploitation

The input is concatenated into a shell command. Appending a semicolon followed by an arbitrary command is sufficient:

sh; touch /tmp/home/cyloq.txt

The server hangs for roughly two seconds while the pings execute, then runs the injected command:

Impact

The endpoint requires authentication, which limits direct exploitation. However, it accepts GET requests, making it vulnerable to CSRF. An attacker can craft a link that executes arbitrary commands on the router when clicked by an authenticated administrator.

The endpoint is not linked anywhere in the UI and only appears in the routing table during static analysis, which likely explains why it persisted for as long as it did.

Reflected XSS (CVE pending)

We identified a reflected XSS in an unauthenticated endpoint. ASUS has developed a fix but has not yet released it publicly. We will update this post with technical details once the patch is available to users.

Information Disclosure via /get_webdavInfo.asp

The endpoint /get_webdavInfo.asp requires no authentication but is gated by a key parameter. The httpd binary reveals how this key is derived:

culong get_webdavinfo(undefined8 param_1,FILE *param_2)
{
 ...
  __s2 = (char *)get_request_param_string("key",uVar4);
  pcVar5 = nvram_get("label_mac");
  strncpy(local_c8,pcVar5,0xf);
  if (pcVar5 == (char *)0x0) {
    pcVar5 = "";
  }
 ...
  snprintf(local_88,0x21,"ASUS%sRouter",local_c8);
  MD5_Init(&MStack_60);
  len = strlen(local_88);
  lVar7 = 0;
  MD5_Update(&MStack_60,local_88,len);
  MD5_Final(local_d8,&MStack_60);
  pcVar5 = local_b0;
  do {
    pbVar1 = local_d8 + lVar7;
    lVar7 = lVar7 + 1;
    snprintf(pcVar5,3,"%02x",(ulong)*pbVar1);
    pcVar5 = pcVar5 + 2;
  } while (lVar7 != 0x10);
  toUpperCase(local_b0);
  iVar2 = strcmp(local_b0,__s2);
  if ((iVar2 == 0) || (iVar2 = nvram_get_int("x_Setting"), iVar2 == 0)) {
    uVar6 = show_webdavinfo(param_1,param_2);
  }
  else {
    fprintf(param_2,"{\n\"error_status\":\"%d\"\n}\n",2);
    uVar3 = fflush(param_2);
    uVar6 = (ulong)uVar3;
  }
  return uVar6;
}

The process is:

1. Read the router's MAC address (label_mac) and take the first 15 characters
2. Construct the string ASUS<mac>Router
3. MD5 hash it
4. Uppercase the hex digest

So for a router with MAC address BC:FC:E7:2C:8F:9C:

1. First 15 characters: BC:FC:E7:2C:8F:
2. String: ASUSBC:FC:E7:2C:8F:Router
3. MD5: 5e06cd4315091cd0be55aeffafc10459
4. Uppercased: 5E06CD4315091CD0BE55AEFFAFC10459

Requesting the endpoint with the constructed key returns the firmware version and open ports:

The MAC address is the only secret component, and MAC addresses are not secret. They are disclosed to any device on the local network and can often be obtained through other means.

Note

This was patched by ASUS but a CVE was not prescribed.

Conclusion

The command injection is the most notable of the three. The endpoint serves no visible purpose, the backing binary is non-functional, and nothing in the UI references it. This makes it effectively invisible to black-box testing. It only surfaced through static analysis of the routing table in httpd.

ASUS has patched all three issues. The fixes landed around the same time ASUS was publicly touting its "strong product security" in response to the US FCC's restrictions on foreign-made routers, a coincidence that PCGamer noted.