Skip to main content
After my Silverpeas research, I wanted to try something different from another open-source web application. Router firmware seemed like a good next step. I had recently watched Low Level’s video, I Hacked This Temu Router. What I Found Should Be Illegal., and it made me curious about how well AI coding agents could handle firmware extraction, binary analysis, and emulation.
I briefly tried a few other router images without finding anything worth pursuing. The Netis NX10 was the first one that worked out, and the vulnerabilities were almost ridiculous in their simplicity. The final chain used two bugs to go from no credentials to a root shell on the router. Both were so basic that the firmware almost felt like a CTF challenge rather than a production device.
Disclaimer

I found no evidence that either vulnerability was deliberately introduced. I use “backdoor” here because of how direct the path was, not as a claim about Netis’s intent.

​
Why the Netis NX10

The NX10 firmware was publicly downloadable and the V4 branch was newer than the versions covered by the existing public Netis research I found. It was also suitable for local emulation, which meant I could test the actual web interface and CGI binaries instead of relying only on static analysis. I downloaded the official V4.0.1.5808 image and later repeated the testing against V3.0.0.4142. Both firmware branches contained the same vulnerable behavior.

​
Review setup

This research used Anthropic’s Claude and OpenAI’s Codex models through a newer version of my security research harness. Compared with the loose, free-flowing agent setup I used for Silverpeas, this workflow gave different agents narrower research roles and added a separate validation step for testing candidates against a running target. The harness was still much less mature than it is today, but the research was already more structured. Firmware emulation was new to me at the time. The LLMs introduced me to FirmAE, which I then added to the harness so the agents could inspect the extracted filesystem while interacting with the emulated router. All dynamic testing was performed locally under FirmAE and QEMU. I did not test a physical NX10. V4.0.1.5808 needed one emulation-only adjustment because /etc/passwd and /etc/group pointed into a runtime filesystem that FirmAE left empty. I replaced those links with files containing the expected root entries so that Boa could start. The vulnerable netis.cgi binary was not modified. V3.0.0.4142 booted without that adjustment.

​
Findings

The command injection is authenticated when on its own, and the credential disclosure supplies the required administrator session, making the complete chain an unauthenticated root RCE. I scored the chained result as CVSS 3.1 9.8 Critical: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

​
The command injection

The command injection was the first finding. One of the agents identified a simple shell-command construction in the router’s ping diagnostic. A request to /web/cgi-bin/skk_set.cgi with tools_set=1 and type=1 reaches pingHandler in the stripped bin/netis.cgi binary. The handler reads the IpAddr parameter and places it directly into a command equivalent to:
There was an input filter, but it rejected only four characters: That still left most shell syntax available. Backtick command substitution passed the filter, and ${IFS} supplied spaces without using a literal space. The following IpAddr value started a bind shell:
Boa and its CGI handlers ran as root, so the injected process was root as well. The vulnerability looked like a classic command-injection exercise: user input appended to a shell command, a four-character blocklist, and a standard ${IFS} bypass.

​
Inaccurate initial assessment from the agents

The agents originally reported this as an unauthenticated root RCE. Their rationale was that a factory-state NX10 had no administrator password, and its setter actions were available without a session. I pushed back on that assessment - my reasoning was that if the device had no configured administrator password and exposed the entire management interface, the lack of authentication was a property of the factory state. It doesn’t mean this is an “unauthenticated” vulnerability. Once I set an administrator password, unauthenticated requests to the diagnostic handler were redirected to the login page and did not execute. We also tested roughly 28 other setter actions, with the same result. Therefore, the command injection technically is only available to authenticated users, and its CVSS score should only be 7.2 High.

​
The authentication bypass

The deeper pre-authentication review led to /web/cgi-bin/skk_get.cgi?sysinfo. The login page requested this endpoint without a session so that it could display basic device information. The response also included a password field:
I initially had trouble understanding what I was looking at. A pre-authentication request used by the login page was returning the administrator credential I had configured. It was not a temporary login challenge or a session identifier. More importantly, the login handler accepted the disclosed value verbatim:
The response returned the plaintext administrator password, which is also a valid administrator session cookie. No password cracking or recovery of the original plaintext was required. I would argue that using the password hash as a reusable login token would probably be more secure that what is being implemented here. Strictly speaking, this is an unauthenticated credential disclosure. In practice, it acts as an authentication bypass because the disclosed value can immediately be exchanged for an administrator session.

​
Chaining both findings to root

With the credential disclosure in front of the command injection, the complete attack required three HTTP requests and a connection to the resulting shell:
The router used a minimal BusyBox environment, so some commands I would normally use to demonstrate impact were missing. In particular, the image did not provide id or uname. Therefore I have to confirm our identity through /proc/self/status and hostname instead:
The result showed filesystem UIDs of 0 and the hostname Netis-NX10, which also distinguished the guest from the host running QEMU.

Chaining the unauthenticated credential disclosure with the ping command injection to obtain a root shell

​
Affected firmware and impact

I reproduced the complete chain under emulation on both firmware branches available during testing (V4.0.1.5808 and V3.0.0.4142). An attacker who can reach the management interface can take full control of the router without knowing its administrator password. Root access allows the attacker to read or change the device configuration, modify DNS and routing, access stored secrets, monitor or redirect traffic, install persistence, and use the router as a foothold into the local network. The management interface is available from the LAN by default. A deployment that exposes remote administration could also make the chain reachable from the WAN.

​
Some final thoughts

This research was a useful comparison with the earlier Silverpeas experiment. The Silverpeas review was mostly free-form: I pointed coding agents at areas of interest, reviewed their leads, and validated the promising ones manually. By the time I looked at Netis, I had started breaking the work into more deliberate stages and assigning separate agents to exploration, proof construction, and review. The agents again made important contributions. They found the vulnerable command construction, introduced me to FirmAE, helped bring the firmware up under emulation, and found the credential disclosure after I redirected the search toward the pre-authentication surface. However, the agents also inaccurately flagged the initial factory-state result as unauthenticated RCE. As the human operator, I was able to spot the logic flaw and reject that result, which led to the discovery of a proper authentication bypass and a stronger finding. Hey - at least I was still able to contribute :P. Those problems influenced how I continued building my harness. My current version uses specialized agent swarms to explore different parts of the attack surface, but findings still have to pass a separate validator. The validator reproduces the exploit against a fresh local deployment, checks the required privileges and state, and records evidence that can be replayed without trusting the model’s description. The framework is much more mature now, but the basic lesson from Netis remains the same: agents are very good at generating and tracing leads, while impact and correctness still need an independent gate.

​
Disclosure timeline

VulnCheck declined to coordinate directly with Netis because it could not identify a public security-reporting channel for the vendor. It asked me to publish the findings using the assigned IDs and indicated that it would populate the public CVE records afterward. At the time of publication, no fixed firmware had been confirmed.

​
References

​
Acknowledgements

Thank you to Low Level for publishing the router-hacking video that inspired me to explore firmware security, and to VulnCheck for triaging the vulnerabilities and assigning the CVE IDs.
Last modified on September 8, 2026