Recently, [Jeff Geerling] dropped into the bad press feeding frenzy around Sipeed’s NanoKVM, most notably because of a ‘hidden’ microphone that should have no business on a remote KVM solution. The problem with that reporting is, as [Jeff] points out in the video below, that the NanoKVM – technically the NanoKVM-Cube – is merely a software solution that got put on an existing development board, the LicheeRV Nano, along with an HDMI-in board. The microphone exists on that board and didn’t get removed for the new project, and it is likely that much of the Linux image is also reused.
Of course, the security report that caused so much fuss was published back in February of 2025, and some of the issues pertaining to poor remote security have been addressed since then on the public GitHub repository. While these were valid concerns that should be addressed, the microphone should not be a concern, as it’d require someone to be logged into the device to even use it, at which point you probably have bigger problems.
Security considerations aside, having a microphone in place on a remote KVM solution could also be very useful, as dutifully pointed out in the comments by [bjoern.photography], who notes that being able to listen to beeps on boot could be very useful while troubleshooting a stricken system. We imagine the same is true for other system sounds, such as fan or cooling pump noises. Maybe all remote KVM solutions should have microphone arrays?
Of course, if you don’t like the NanoKVM, you could always roll your own.
Top image: the NanoKVM bundle from [Jeff]’s original review. (Credit: [Jeff Geerling])
The (excellent) GL.Inet IP KVMs include a microphone and speaker, and expose that fuctionality via the Web UI.
They do not include a physical microphone or speaker though? They just emulate them.
I have one of those and via the web UI you can use your local microphone on a remote device by enabling the microphone emulation.
I ordered the new Comet. Am I going to regret it?
Good point, it’s a legitimately useful feature of the board and it’s not being abused.
I can’t really understand what people have to complain about?
I guess that this is rage clicks, and for whatever reason humans are uniquely vulnerable to rage content on social media.
This is a gross misrepresentation. While it’s true that there is a microphone, that isn’t their most egregious transgression. The software it ships paints a far more damning picture.
Why does this extremely paired-back linux install contain TCPdump? And aricrack? If this microphone is an incidental hardware feature, why did they add ALSA software tools like amixer and arecord which make it immediately available for use by scripts? And of course it routs all it’s DNS queries through chinese servers.
And then on top of that this thing has terrible security. It shipped with a preset password and out-of-box SSH access. The web interface lacks CSRF defenses and doesn’t have any way to invalidate sessions. The key used to protect login passwords is hardcoded and shared across all devices. “According to the researcher, this had to be explained to the developers ‘multiple times’ before they acknowledged the issue.”
In my humble opinion, the picture this paints is that seeed is “seeding” the world with vulnerable KVM modules which are ripe to be taken over later by adversaries who will be able to simply drop a shellscript-based payload and find all the binaries they could ever want for pivoting their attack. And that’s in addition to any high-value targets attached to the KVMs themselves.
https://www.tomshardware.com/tech-industry/cyber-security/researcher-finds-undocumented-microphone-and-major-security-flaws-in-sipeed-nanokvm suggest that users install one of a few different alternative OS images to wipe out all of the above, but tbh I’d rather go with anything else.
Those “alternative OS” are not referenced anywhere in the article, and I personally could not find anything on the web in regards to any build of them (ie: pikvm) existing anywhere.
I have 4 of them NanoKVM that I purchased before the article in February came out and I’m just sitting on them (tested a bit).
If you could actually provide a link to those “alternativr OS”, that’d be great.
Allow me to quote the part of the article you missed:
“Thankfully, because NanoKVM is nominally open source, community members have begun porting alternative Linux distributions, first on Debian and later Ubuntu. Reflashing requires opening the case and writing a new image to the internal microSD card, but early builds already support Sipeed’s modified KVM code. Physically removing the microphone is possible, though the component’s size and placement make it a fiddly job without magnification. Sipeed has since addressed many of the security concerns around the device. However, the general consensus is that users should flash these devices to custom Linux distributions to mitigate potential issues, and many reviewers currently recommend Sipeed products for use in homelab environments.”
aircrack*
Seriously. What the hell is aircrack doing on a KVM device.
Thanks for reporting on this; I missed out on the February reports and nearly bought some Sipeed FPGAs a month ago before talking myself into waiting (too many projects on plate already). Will look elsewhere in the future; not sure what happened here, but that’s too much evidence of at least one bad actor.
the only thing that makes any of these claims materially interesting is that the device is chinese, I’ve seen routers and other network appliances from non chinese suppliers with the same flaws.
as I understood it the firmware is still in development, it makes sense that a network device has tcpdump for diagnostic purposes, aircrack also has non malicious uses too.
the real question is would they have left those tools in place on retail firmware.
it’s nice to know however that antichinese sentiment still exists in the west.
I enthusiastically and almost exclusively buy Chinese boards and MCUs anymore; I’ve abandoned Western brands like ARM and STMicro, Raspberry Pi and Arduino, but still have some favored brands like Mikrotik for routing. If you’ve got evidence of security problems/sloppiness this extensive on widely-used Western boards or routing equipment, def let us know, because I’m pretty ignorant of it (though I also probably don’t use them anymore and wouldn’t care).
It’s a pretty bold claim that people would be concerned about these issues primarily out of bigotry; it’s not necessarily a China problem, but it is necessarily a Sipeed problem.
Arduino Uno R3 and earlier can be built using off-the-shelf parts.
At heart, it’s just an ATMega168 or ATMega328 with a serial interface, a custom bootloader and some pin headers.
Sure you can use Chinese counterparts, if you want.
But building your own Arduino/Genuino is fun.
Schematic:
https://docs.arduino.cc/retired/boards/arduino-serial-single-sided-3/
Boot loader:
https://github.com/Optiboot/optiboot
Putting literal penetration testing tools like aircrack in an OS image for embedded devices is a MASSIVE red flag.
why? i use it all the time for raw wireless packet diagnostic work during embedded network appliance development, sure you ask the devs why it’s included in a development image, you don’t panic like a bunch of headless chickens.
The reason for a lot of those features could just be that it is built on top of the Linux image for the dev board that it contains, which means it makes sense to come with microphone support.
Really? why would aircrack be there?
Honestly speaking 99.9% of the companies in China just want to make a quick buck. So they’re jumping on an existing dev board and merely change the absolute minimum that is required to make their own idea work. The board is a dev board, intended to run Linux – which in that case seems to come with everything that’s needed to run and access the HW abilities. They just added a bit of their own stuff without paying close attention. That is in my experience fairly common and not necessarily done out of bad intentions but more to speed up time to marke.
That doesn’t explain any of the suspicious binaries like TCPdump or aircrack.
That’s informative. I wonder why aircrack and tcpdump are (allegedly as I can’t test) on this, they can’t serve a legitimate purpose in this location that I can think of.
I’d greatfully welcome anyone to teach me a plausible reason they are (allegedly) in a KVM? I can’t see that purpose. So am I missing something.
Because, as the author mentioned, the KVM is implemented using an existing general-purpose Linux computer module.
Those tools are almost certainly part of the base Linux development image for the module.
BS. Aircrack is a penetration testing tool and isn’t in any dev kit.
Pentesting could be useful for dev. You might put it in a devkit for developing secure networkable devices.
It is a development board, with presumably an OS based on the generic development OS. It is not out of the ordinary for small development boards to be used as pentesting tools.
Hanlon’s Razor?
That’s exactly what the video explains. It’s a demo board. The base image wasn’t built for a KVM, it was built to demo all those capabilities. Then someone at Sipeed said, hey KVMs are selling, our board can do that if we preload the KVM software package on it, let’s ship a product tomorrow.” And nobody bothered to remove the other packages from the base image, just like nobody bothered to remove the MEMS microphone chip.
Demo OS images don’t contain aircrack. The image shipped on the device does.
It’s my understanding that this is an open source project. Fork and change.
The microphone driver has been out of the building tree for over nine months.
Build tree*
Read the article. It was only changed after they were called out on it.
given the wide availability of small microphones and cameras, and big tech’s data farming shenanigans, im surprised we dont see more of this.
The really wild part is just how many microphones people willingly put in their homes. Their phones, smart speakers, smart displays, TVs, remote controls, et al.
I never understood why such development boards have no jumper option or tiny solder pads for such things.
It would have been so simple and cheap to make the microphone feature optional!
Hm. On a second thought, I blame nowadays’ SMD obsession here.
On an ordinary through-hole board there would always been enough physical space for a standard jumper installation.
Because the dev board is tiny and AI voice recognition is a big seller in the embedded space.
If you stop and think about it there are already solder pads making this mic optional 💀
Why not remove the software support for the Mic?
If it truly is a security problem a glob of silicone/adhesive, potting compound, or a well placed blow of a small drift or pin punch would probably detatch or mangle the mic handily.
What is flying over the heads of a lot of people is this is a dev board with an addon, so basically a prototype. The kicker is that it was so performant and cheap it could be sold as a product as-is, while massively undercutting other options.
If mass-produced you would obviously save the BOM cost of a mic and add opto-isolators for the power and reset lines and the power indicator. Also savings from ditching the ribbon cable and connector.
It is removed. The driver has been out of the building tree for the device image for over 9 months!
Are they still shipping penetration testing tools too?
That’s not what I was thinking of, though.
I was thinking about two two little pads next to each others (wired in series) that can be bridged by a solder blob.
So the circuit with the microphone is closed, as if the pads were a switch.
In the past, such pads sometimes had a tiny trace connected to each others if the default setting was a closed circuit.
To disable the connection, a carpet knife could be used.
To restore the connection, a solder blob could be used later on.
That’s much simpler than removing/adding parts to the PCB, I think.
Also makes prototyping easier, I think.
Here’s a sample picture of what I mean.
It’s not exactly good, but I couldn’t find something better right now.:
https://forum.kicad.info/t/trace-went-too-close-to-pad-yet-passes-drc/6906/11
Everything with a microphone IS a potential security problem, to my understanding.
But with things like TVs I can understand the reasoning, at least.
On a TV (smart TV), such an microphone could have been installed
because the manufacturer had considered adding a voice operated control in a future software update. Or to allow for Skype sessions etc.
On an embedded device it’s something different, I think, though.
“Hidden” devices shouldn’t start trying to listen to begin with.
They shouldn’t have any kind of sensors to scan people’s privacy, even.
It’s as if a DSL or cable router modem has an microphone installed.
Software solutions can never be fully trusted.
Makers of webcams had realized this a long ago and kept providing mechanical solutions to “disable” the camera sensor.
Since I’m a noob in so many respects, would someone be kind enough to explain why one would need a remote KVM? Wouldn’t it be easier to just remote into each device directly?🤔
You’re assuming it can boot and the network stack loads. If it won’t boot, won’t get on the network, or if you want to get into the setup of the motherboard or e.g. RAID card, a remote KVM is priceless.
Hmmmm…. Accidental spying. So, now that China knows about this, they are now actively trying to craft an exploit. Yeah, for a production unit, this mic has to go. If it isn’t now a security risk, it soon will be.
Maybe a blob of solder over the mic hole?
Or … you can try a software solution that just runs on whatever hardware you got, like [shameless advertising for something that gives me no money at all] github.com/ralsina/kv