TALOS-2026-2437
CVE-2026-10137
A stack-based buffer overflow vulnerability exists in the boa formUpload() functionality of X2000R (version(s): TOTOLINK-X2000R-Gh-V1.0.0-B20250421.1327). A specially crafted HTTP request can lead to arbitrary code execution. An attacker can make an authenticated HTTP request to trigger this vulnerability.
The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.
X2000R (version(s): TOTOLINK-X2000R-Gh-V1.0.0-B20250421.1327)
X2000R - https://www.totolink.net/home/menu/newstpl/menu_newstpl/products/id/242.html
9.1 - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
CWE-121 - Stack-based Buffer Overflow
The Totolink X2000R is a popular budget gigabit home router primarly found in eastern markets. Supporting IPV6, WPA3, mesh capabilities among other features, the Totolink X2000R is a solid choice for the price point.
The Totolink X2000R mainly relies on the standalone boa binary for all web administration and subsequent configuration. While normally a security risk in itself due to the age, it appears that the version running on the X2000R has been patched. Regardless, for the current set of vulnerabilities we only pay attention to the Totolink-specific issues, so we start from the point where authentication has already occurred via the /boafrm/formLogin webpage, and then we can successfully interact with another /boafrm/form* page, each of which have a corresponding callback. While today’s vulnerability is within a seperate binary entirely, in order to get that binary to run we must examinne the /boafrm/formUpload functionality:
0044c8a8 size_t formUpload(struct client* cli)
0044c8e4 char str[0xc8]
0044c8e4 memset(&str, c: 0, n: 0xc8)
0044c8f4 char var_2d0[0xc8]
0044c8f4 memset(str: &var_2d0, c: 0, n: 0xc8)
0044c904 int32_t out = 1
0044c908 char _deviceMac
0044c908 memset(str: &_deviceMac, c: 0, n: 0x99)
0044c910 char* uploadbuf = cli->uploadbuf
0044c914 int32_t read_offset = get_readstart_offset(uploadbuf) // [1]
0044c914
0044c924 if (read_offset != 0xffffffff)
0044c9e8 int32_t dmac_slot_1 = handleFirmwareFile(msgbuf: uploadbuf, max_size: cli->message_size_maybe, read_offset) // [2]
0044c9f4 int32_t dmac_slot = dmac_slot_1
0044c9f4
0044c9f0 if (dmac_slot_1 == 0)
0044ca08 sprintf(dst: &str, fmt: "Upload successfully (size = %d bytes)!<br><br>Firmware update in progress.",
0044ca08 cli->message_size_maybe)
0044ca20 void* _AutoReset = sessionCheck(cli, varname: "AutoReset", &cgi_var_pref, nullptr, 1)
0044ca30 apmib_get(MIB_DO_Mcli, &out)
0044ca38 int32_t MeshEnabled = out
0044ca3c char* redirect-url
0044ca3c
0044ca3c if (MeshEnabled != 1) // [3]
// [...]
0044ca3c else
0044ca54 printf("===========================Start mesh upgrade function: %s\n", &upload_filename)
0044ca60 get_filename_from_buf(buf: cli->uploadbuf, dst: &upload_filename)
To start, the program finds the offset of the file that we are uploading at [1] via parsing HTTP POST data, and then at [2] treats this uploaded file as a firmware file at [2] with the handleFirmwareFile function. If we wish to sidestep actually flashing anything, we can use and the following commented python code to generate a buffer that’s considered “valid firmware” but doesn’t flash.
####################
buf = b""
buf += struct.pack("<I", 0x26d19a37) # magic bytes
buf += struct.pack("<I", 0x1) # tftp mode
buf += struct.pack("<I", 0x12345678) # svn (just needs to be != fw_ver from above...)
buf += b"\x11\x22\x33\x44\x55\x66" # mac addr, needs to be != \x00\x00\xaa\xbb\xcc\xdd
buf += csid # the csid, this needs to match our fw_key HTTP POST param from above
buf += b"\x00"
while len(buf) < 0x94:
buf += b"A"
Continuing on, assuming that our device is currently in easy mesh mode [3], or we set that configuration ourselves via other HTTP requests, we can then continue on within the formUpload() function:
0044ca94 void* _controller_upgrade = sessionCheck(cli, varname: "controller_upgrade", &cgi_var_pref, nullptr, &data_490000)
0044cab8 int32_t _deviceNum = atoi(str: sessionCheck(cli, varname: "deviceNum", &cgi_var_pref, nullptr, &data_490000)) // [4]
0044cacc printf("devicenum :%d\n", _deviceNum)
0044cadc char* format = "enable%d"
0044cae8 char* str2 = &ON
0044cae8
0044caf0 while (_deviceNum s>= MeshEnabled)
0044cc3c char varname[0x64]
0044cc3c snprintf(dst: &varname, 0x14, format, MeshEnabled) // [5]
0044cc3c
0044cc64 if (strcmp(str1: sessionCheck(cli, &varname, &cgi_var_pref, nullptr, &data_490000), str2) != 0)
0044cc68 MeshEnabled += 1
0044cc64 else
0044cc78 snprintf(dst: &varname, 0x14, format: "devicemac%d", MeshEnabled) // [6]
0044cc8c char* _devicemac%d = sessionCheck(cli, &varname, &cgi_var_pref, nullptr, &data_490000)
0044cc8c
0044cc9c if (sx.d(*_devicemac%d) == 0)
0044cca0 MeshEnabled += 1
0044cc9c else
0044ccb0 printf("device mac:%s\n", _devicemac%d)
0044ccb0
0044ccbc if (dmac_slot s< 3)
0044ccd4 strcpy(dest: &(&_deviceMac)[dmac_slot * 0x33], src: _devicemac%d) // [7]
The program goes back to reading our HTTP POST parameters, most importantly the deviceNum parameter at [4], which determines how many times we enter the loop further down. For each loop iteration, we look first for generated enable%d parameter, where %d is the loop iteration. Assuming this HTTP POST parameter is found and is non-zero, then we hit the line at [6] and try to look for a devicemac%d parameter as well. If this is found, then we copy the value to an array slot with strcpy at [7]. Since there is no length check on any given devicemac%d value, we find ourselves with a classic stack-based buffer overflow and subsequent code execution.
Program received signal SIGSEGV, Segmentation fault.
0x7737c230 in ?? () from /lib/libc.so.0
[^_^] SIGSEGV
***********************************************************************************
***********************************************************************************
v0 : 0x41414141 | s3 : 0x00000025
v1[S] : 0x7f8cc894 | s4[L] : 0x7737c4b0
a0 : 0x00000008 | s5[X] : 0x004780c0
a1 : 0x00000000 | s6[X] : 0x004780c0
a2 : 0x00000000 | s7 : 0x00000002
a3[S] : 0x7f8cc8e0 | t8[X] : 0x0048c128
t0 : 0x00000000 | t9[L] : 0x77382810
t1 : 0x00000000 | k0 : 0x0000000a
t2 : 0x00000001 | k1 : 0x00000000
t3 : 0x41414141 | gp[L] : 0x773d2400
t4 : 0x00000080 | sp[S] : 0x7f8cc7e8
t5[L] : 0x773d2400 | ra[L] : 0x7737c184
t6 : 0x00000000 | status : 0x0000f413
t7[H] : 0x00490000 | badvaddr : 0x41414141
s0[S] : 0x7f8cc848 | pc[L] : 0x7737c230
s1[S] : 0x7f8cc870 | fcsr : 0x00000000
s2 : 0x41414141 | restart : 0x00000000
***********************************************************************************
0x7737c220: sw a0,-4(v0)
0x7737c224: lw s4,-31556(gp)
0x7737c228: li s3,37
0x7737c22c: move v0,s2
=> 0x7737c230: lbu v1,0(v0)
0x7737c234: bnez v1,0x7737c25c
0x7737c238: nop
0x7737c23c: lw v0,24(s0)
0x7737c240: li v1,8
***********************************************************************************
#0 0x7737c230 in (0x77344000 0x773ba000 0x76000 0x0 r-xp /lib/libuClibc-0.9.33.so)(+0x38230)
***********************************************************************************
2026-06-16 - vulndev@cisco.com - Initial Vendor Notification
2026-06-23 - vulndiscovery@external.cisco.com - Follow-up sent
2026-06-25 - fae_hardware@zioncom.net - Vendor Acknowledged
2026-06-25 - vulndiscovery@external.cisco.com - Resent all notifications
2026-07-16 - vulndiscovery@external.cisco.com - Follow-up sent
2026-09-15 - vulndiscovery@external.cisco.com - Follow-up sent
Lilith Wyatt of Cisco Talos