Protect.Computer
NEWS

Nine IP-KVM flaws expose root-level takeover paths across low-cost devices

· 2 min read · Network safety Device safety

What happened

Eclypsium researchers disclosed 9 vulnerabilities across 4 low-cost IP-KVM product lines: GL-iNet Comet RM-1, Angeet/Yeeso ES3, Sipeed NanoKVM, and JetKVM.

The most severe paths include unauthenticated file write and command execution on Angeet/Yeeso ES3, which can lead to root-level compromise of the KVM appliance. Because IP-KVM devices can inject keyboard/mouse input and control systems at BIOS/UEFI level, compromise can translate into near-physical control of attached hosts.

Which models are affected (and patch status)

  • GL-iNet Comet RM-1

    • CVE-2026-32290, CVE-2026-32291, CVE-2026-32292, CVE-2026-32293
    • Patch status: mixed. Some issues addressed in v1.8.1 beta; other findings remained without planned full fix at publication time.
  • Angeet / Yeeso ES3 KVM

    • CVE-2026-32297, CVE-2026-32298
    • Patch status: no public fix available at publication time.
  • Sipeed NanoKVM / NanoKVM Pro

    • CVE-2026-32296
    • Patch status: fixed in NanoKVM 2.3.6 and NanoKVM Pro 1.2.14.
  • JetKVM

    • CVE-2026-32294, CVE-2026-32295
    • Patch status: fixed in JetKVM 0.5.4.

How to check if you are affected

Use this quick checklist:

  1. Identify your IP-KVM vendor/model
    • Check device label, web UI “About” page, or inventory/asset records.
  2. Check firmware version in the management UI
    • Compare against the fixed versions above.
  3. Map your device to CVEs
    • Use the CVE links in Primary sources below to confirm impact and severity.
  4. If you run Angeet/Yeeso ES3
    • Treat as high risk until proven patched by vendor bulletin.
    • Isolate immediately to a management-only VLAN and block internet exposure.
  5. If you run GL-iNet RM-1
    • Move to latest available firmware and verify whether your deployed version includes the 1.8.1-beta mitigations.
    • Keep strict network isolation because not all findings had complete fix status in original disclosure.
  6. If you run JetKVM or Sipeed
    • Confirm you are at or above patched versions noted above.
    • If below, patch now and rotate credentials.
  7. Check external exposure
    • Ensure KVM web interfaces/ports are not internet-reachable.

Why this matters

A compromised KVM appliance can bypass assumptions many defenders rely on:

  • Access at BIOS/UEFI and pre-boot stages
  • Keystroke injection and remote media boot abuse
  • Persistence opportunities below endpoint tooling visibility

In practice, this can turn a small “management helper” into a high-impact pivot point for lateral movement and durable compromise.

Defensive actions to prioritize

  1. Place all IP-KVM devices on a dedicated management VLAN.
  2. Deny direct internet access to device management interfaces.
  3. Patch to vendor-fixed versions immediately where available.
  4. Replace or segment devices with no patch path for critical CVEs.
  5. Enforce strong auth (and MFA where supported), rotate credentials after patching.
  6. Monitor KVM-origin traffic and admin events for anomalies.

Primary sources

How to check if you’re affected

Affected scope: organizations or users potentially exposed to Nine IP-KVM flaws expose root-level takeover paths across low-cost devices conditions should validate immediately.

Quick verification steps:

  1. Confirm your exposure surface
    • Identify whether your environment uses the affected product/service/version mentioned in this advisory.
  2. Check official advisories and indicators
    • Compare your deployed versions/configuration against vendor or authority guidance.
  3. Review logs for suspicious activity
    • Investigate authentication, admin, process, and network anomalies tied to this threat pattern.
  4. Validate mitigations are active
    • Apply patches/workarounds and re-check for failed exploit attempts or recurring indicators.

Sources

Bottom line

If you use IP-KVM, verify your exact model + firmware today. Devices in this category should be treated as privileged infrastructure, not generic peripherals.

Related reading