The KVM with a Secret: NanoKVM Ships with Critical Flaws and a Covert Microphone
In February, a Slovenian information security researcher published an analysis of the Chinese remote-management device NanoKVM, revealing that the inexpensive €30–60 KVM kit shipped with a host of vulnerabilities—along with a concealed microphone that could be activated remotely over SSH. Although the manufacturer has addressed some of these issues in recent months, the episode serves as a stark reminder of the dangers of indiscriminately introducing opaque “black boxes” into one’s networks.
NanoKVM is a compact RISC-V board that entered the market last year as a budget alternative to PiKVM. It can capture HDMI video, emulate a USB keyboard and mouse, control power, and provide browser-based access to a connected computer. For administrators and enthusiasts, it offers a convenient way to maintain an uninterrupted “lifeline” to a server or home machine—from the BIOS stage to operating-system installation—without requiring any software on the target system itself. Unsurprisingly, such devices have begun appearing within real-world IT infrastructures.
According to the researcher, security issues arise quite literally from the moment the device boots. Early batches of NanoKVM shipped with a default password and open SSH access. He reported this to Sipeed, and the company later modified these settings. However, the web interface remains only minimally protected: it lacks CSRF safeguards and offers no mechanism to forcibly invalidate active sessions—meaning a user cannot truly log out.
Password handling presents an even more troubling case. The encryption key NanoKVM uses to protect login credentials in the browser was found to be hard-coded into the firmware and identical across all devices. This means that anyone obtaining the key could potentially decrypt passwords from any NanoKVM unit. The researcher noted that he had to explain the severity of this issue “several times” before the developers acknowledged it.
The device’s network behavior also raised concerns. By default, it sent DNS queries through servers in China and maintained regular connections to Sipeed’s infrastructure for updates and a proprietary binary component. The verification key for that component was stored openly on the device, and the integrity of downloaded firmware was not checked at all. This creates a convenient vector for supply-chain attacks—whether initiated by the manufacturer itself or by actors compromising its servers.
Compounding the unease was the strange composition of the installed Linux image: a heavily stripped-down system lacking common administrative tools, yet preloaded with tcpdump and aircrack—utilities more closely associated with traffic analysis and Wi-Fi testing than with a turnkey product intended for privileged networks.
Against this backdrop, the discovery of a miniature onboard microphone appeared particularly alarming. It is never mentioned in any official documentation, yet ALSA utilities such as amixer and arecord were readily available in the system, fully capable of capturing audio. Many deployed devices continued to use default SSH credentials, and the researcher demonstrated that recording and exfiltrating audio from NanoKVM required only minimal effort. For real-time streaming, he estimated that merely a small additional script would suffice.
One mitigating factor is that NanoKVM is formally positioned as an open-source platform. The community quickly mobilized and began porting alternative Linux distributions to the device—first Debian, then Ubuntu. Reflashing requires opening the case and writing a new image to the internal microSD card, but early builds already work with modified versions of Sipeed’s KVM code. Physically removing the microphone is also possible, though its size and placement make it a delicate operation without magnification tools.
According to the researcher, Sipeed has addressed a substantial portion of the reported vulnerabilities over recent months. Nevertheless, many in the community agree that relying solely on the stock firmware is unwise. The prevailing recommendation is clear: if you intend to use NanoKVM, consider reflashing it with a custom Linux distribution and strictly limiting access to the device. For now, these boards are viewed more as toys for homelab experimentation than as instruments suitable for mission-critical corporate environments.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
