Is Your IP KVM a Back Door? Seven Checks After the 2026 Flaws

Summary: Nine flaws in four low-cost IP KVMs showed how much access these small boxes carry. Here is what to lock down, and when a plain KVM switch is the safer buy. 

An IP KVM does something no remote desktop tool can. It sits between a computer and its keyboard, mouse and screen, so whoever controls it sees the BIOS, can mount boot media and can power the machine off and on.

IT teams and home labs like that. It is also exactly why a weak one is a problem. 

In March 2026, Eclypsium published research on nine vulnerabilities across four low-cost models: the GL.iNet Comet RM-1, JetKVM, Sipeed NanoKVM and Angeet/Yeeso ES3.

Anyone new to the category can start with Byrdpilot’s guide to IP KVMs, which explains how these devices differ from remote desktop and from a traditional KVM switch.

The short version: an IP KVM gives access before the operating system loads, which is why a flaw in one matters more than a flaw in an ordinary app. 

What Eclypsium found

The scores below are Eclypsium’s. Other trackers list different numbers for some of them. 

• Angeet/Yeeso ES3 (two flaws). An upload endpoint on port 8888 allowed arbitrary file writes without a login (CVSS 9.8), and unsanitized input in a configuration script allowed command injection as root (8.8). Chained together, they give an unauthenticated attacker root. Eclypsium listed no fix and said deployed units warrant immediate network isolation.

• GL.iNet Comet RM-1 (four flaws). The serial (UART) interface gave a root shell with no credentials, though only to someone with physical access (7.6). The web login had no rate limiting, and the same password was used for SSH by default (5.3). The other two were weak firmware verification (4.2) and a cloud setup step that did not check certificates (3.1).

• JetKVM (two flaws). Firmware updates were verified only by a SHA-256 hash from the same server, with no signature (6.7), and login attempts were not rate-limited (7.3). Both were fixed in version 0.5.4.

• Sipeed NanoKVM (one flaw). A Wi-Fi configuration endpoint needed no authentication (5.4).

Eclypsium also noted that some devices ship with authentication switched off, and that three of the four vendors did not verify firmware signatures. 

Exposure was growing too. RunZero found 404 of these devices reachable from the internet in June 2025. By January 2026 Eclypsium counted 1,611, using Shodan data. 

Seven checks before plugging one in

1. Ask whether remote access is needed at all. Plenty of desks only need to share one keyboard and screen between two computers. A regular KVM switch has no network port, so it has no network attack surface to defend. Byrdpilot’s KVM switch picks cover that route for Mac and PC setups. 

2. Keep it off the public internet. Never port-forward an IP KVM. The jump from 404 to 1,611 exposed devices is the pattern to avoid. 

3. Put it on its own network. A dedicated management VLAN keeps a compromised KVM away from everything else on the network. 

4. Reach it through a VPN. Eclypsium names WireGuard and Tailscale as options. Remote access then runs through a tunnel instead of an open port. 

5. Turn authentication on and set a strong, unique password. Use multi-factor authentication where the device supports it. Missing rate limits made weak passwords easy to guess on two of the products. 

6. Update the firmware, and read the vendor’s advisory. JetKVM owners need 0.5.4 or later. For GL.iNet and NanoKVM, Eclypsium’s own write-up gives different fixed version numbers in different places, so the safe course is the vendor’s latest release and its security notes. For the ES3, no fix was listed: isolate it or replace it. 

7. Treat physical access as access. The GL.iNet serial port needed no credentials, so the device belongs somewhere only trusted people can reach. Eclypsium also suggests inventorying IP KVMs on the network, searching Shodan for titles such as JetKVM, NanoKVM and GLKVM to spot exposed units, and watching for unexpected outbound connections. 

The takeaway

Nothing here makes an IP KVM a bad idea. An unmanaged one is the bad idea. Treated like any other management interface, with its own network, a VPN, current firmware and a strong password, it does the job it was bought for.

For anyone who only wanted to share a keyboard, the simpler box removes the question.