Falhas em IP KVM expõem acesso root e execução de código em quatro fornecedores

Nove vulnerabilidades em dispositivos GL-iNet, Angeet/Yeeso, Sipeed e JetKVM afetam controles de atualização, autenticação, provisionamento, limitação de tentativas e interfaces expostas.

Componente	Dispositivos IP KVM GL-iNet Comet RM-1, Angeet/Yeeso ES3 KVM, Sipeed NanoKVM e JetKVM.
Vetor	Falhas em autenticação, verificação de firmware, limitação de força bruta, provisionamento inicial, endpoints de configuração, UART e injeção de comandos do sistema operacional.
Impacto	As falhas mais severas permitem acesso root sem autenticação ou execução de código arbitrário, com risco de controle remoto sobre teclado, vídeo e mouse dos hosts conectados.
Prioridade	Atualizar firmware quando houver correção, isolar IP KVM em VLAN de gerenciamento, restringir exposição externa e monitorar tráfego inesperado desses dispositivos.
Versões	GL-iNet Comet KVM tem correções planejadas para CVE-2026-32290 e CVE-2026-32291; GL-iNet 1.8.1 BETA corrige CVE-2026-32292 e CVE-2026-32293; JetKVM 0.5.4 corrige CVE-2026-32294 e CVE-2026-32295; NanoKVM 2.3.1 e NanoKVM Pro 1.2.4 corrigem CVE-2026-32296; Angeet ES3 KVM não tinha correção disponível para CVE-2026-32297 e CVE-2026-32298.
Artefatos	A classe de problemas inclui ausência de validação de assinatura de firmware, controles de acesso quebrados, ausência de proteção contra força bruta e interfaces de depuração expostas.

Resumo técnico

Nove vulnerabilidades em dispositivos IP KVM de baixo custo ampliam o risco operacional de ambientes que usam acesso remoto a teclado, vídeo e mouse para administrar servidores, estáções e equipamentos sem depender do sistema operacional do host. Os produtos citados são GL-iNet Comet RM-1, Angeet/Yeeso ES3 KVM, Sipeed NanoKVM e JetKVM. O ponto crítico não é apenas a presença de falhas individuais, mas a combinação de funções privilegiadas com controles básicos ausentes ou incompletos. Um IP KVM opera em uma posição sensível porque permite interação remota com a máquina conectada no nível de console, inclusive antes do carregamento completo do sistema operacional.

As vulnerabilidades abrangem verificação insuficiente de autenticidade de firmware, acesso root via UART, proteção limitada contra força bruta, provisionamento inicial inseguro por conexão de nuvem não autenticada, verificação insuficiente de atualização, endpoint de configuração exposto, ausência de autenticação em função crítica e injeção de comandos do sistema operacional. A consequência defensiva é direta: um dispositivo que costuma ser tratado como periférico de administração pode se tornar um canal de controle persistente sobre máquinas conectadas, com baixa visibilidade para agentes de segurança instalados no sistema operacional dessas máquinas.

Fluxo técnico

Os dispositivos IP KVM fornecem acesso remoto à entrada de teclado, saída de vídeo e controle de mouse do host, inclusive em fases como BIOS/UEFI, telas de bloqueio, mídia de inicialização e rotinas de recuperação. Quando a camada de gerenciamento do KVM é comprometida, o operador malicioso não precisa interagir com o host por protocolos tradicionais como acesso remoto do sistema operacional. Ele pode injetar teclas, navegar por menus de inicialização, tentar contornar proteções de disco quando houver condições para inicialização alternativa e manipular a sessão visualmente como se estivesse diante do equipamento.

A superfície de ataque descrita combina falhas de software embarcado e decisões inseguras de exposição. CVE-2026-32290, com CVSS 4.2, envolve verificação insuficiente de autenticidade de firmware no GL-iNet Comet KVM. CVE-2026-32291, com CVSS 7.6, trata de acesso root por UART no mesmo produto. CVE-2026-32292, com CVSS 5.3, descreve proteção insuficiente contra força bruta, enquanto CVE-2026-32293, com CVSS 3.1, envolve provisionamento inicial inseguro por conexão de nuvem não autenticada. No JetKVM, CVE-2026-32294, com CVSS 6.7, cobre verificação insuficiente de atualização, e CVE-2026-32295, com CVSS 7.3, aborda limitação insuficiente de taxa. No Sipeed NanoKVM, CVE-2026-32296, com CVSS 5.4, expõe endpoint de configuração. No Angeet ES3 KVM, CVE-2026-32297, com CVSS 9.8, permite execução de código arbitrário por ausência de autenticação em função crítica, e CVE-2026-32298, com CVSS 8.8, permite execução arbitrária de comandos por injeção de comandos do sistema operacional.

O impacto deve ser analisado no contexto físico-lógico do KVM. Um comprometimento do dispositivo não equivale a uma falha isolada em um sensor ou equipamento secundário de rede. O KVM pode permanecer entre o operador remoto e o host, conservar alterações no próprio firmware ou na configuração do aparelho e reiniciar interações mesmo depois de uma limpeza no sistema operacional conectado. Quando a verificação de atualização é fraca ou não há validação criptográfica adequada, também existe risco condicionado de adulteração de firmware durante distribuição ou atualização, desde que o adversário controle algum ponto relevante desse fluxo.

Superfície afetada

A exposição relevante inclui qualquer ambiente que mantenha IP KVM conectado a servidores, estáções administrativas, laptops corporativos, equipamentos de laboratório, appliances ou máquinas usadas para manutenção fora de banda. O risco aumenta quando a interface de gerenciamento é acessível pela internet, quando as credenciais são fracas, quando não há autenticação multifator, quando o KVM compartilha a mesma rede de usuários ou quando logs e fluxos de rede desses dispositivos não entram na monitoração de segurança.

O conjunto de falhas também afeta práticas de resposta a incidente. Se a investigação focar apenas no host controlado pelo KVM, a causa de reinfecções, alterações de boot, entradas de teclado inesperadas ou retornos recorrentes de persistência pode ficar fora do escopo. Em ambientes com múltiplos servidores conectados ao mesmo aparelho, o impacto potencial se expande porque o dispositivo passa a ser uma ponte operacional para todos os sistemas sob seu controle.

• GL-iNet Comet KVM com falhas em assinatura de firmware, UART, força bruta e provisionamento inicial.
• JetKVM com falhas em verificação de atualização e limitação de taxa.
• Sipeed NanoKVM e NanoKVM Pro com endpoint de configuração exposto antes das versões corrigidas.
• Angeet/Yeeso ES3 KVM com falhas sem correção disponível no material analisado para execução de código e comandos arbitrários.
• Hosts acessíveis via console KVM, incluindo sistemas em BIOS/UEFI, telas de bloqueio e processos de inicialização.

Hunting e telemetria

A detecção precisa considerar que a ação principal pode não aparecer como processo malicioso no host. Como o IP KVM atua fora do sistema operacional, a telemetria deve combinar rede, identidade, inventário, gerenciamento de ativos, alterações de firmware e sinais indiretos no host. Conexões de origem incomum para a interface do KVM, tentativas repetidas de autenticação, tráfego inesperado para serviços de nuvem de provisionamento, atualização de firmware fora de janela autorizada e mudanças súbitas de configuração devem ser tratados como eventos relevantes.

Também é importante correlacionar eventos no host com atividade no KVM. Inicializações inesperadas, mudanças em ordem de boot, entrada de mídia removível, desbloqueios em horários anômalos, sessões administrativas sem origem de rede tradicional e reinstalação recorrente de artefatos após remediação podem indicar que a camada de console está sendo usada como caminho de controle. A ausência de alerta em EDR não deve encerrar a investigação quando houver um KVM administrando o equipamento.

• Exposição pública de painéis ou portas de gerenciamento de IP KVM identificada por varredura defensiva e inventário externo.
• Falhas repetidas de login, tentativas em alta frequência ou ausência de limitação efetiva contra força bruta.
• Alterações de firmware, configuração ou provisionamento fora do fluxo de mudança aprovado.
• Tráfego inesperado de entrada ou saída envolvendo dispositivos KVM em VLAN de gerenciamento.
• Eventos de boot, BIOS/UEFI, mídia removível ou console incompatíveis com janelas de manutenção.

Mitigação

A primeira medida é tratar IP KVM como ativo privilegiado de administração, não como acessório. Dispositivos corrigidos devem receber firmware atualizado conforme a versão disponível para cada produto. GL-iNet Comet KVM tem correções planejadas para duas falhas e correções em 1.8.1 BETA para as vulnerabilidades de força bruta e provisionamento. JetKVM corrige as falhas citadas na versão 0.5.4. NanoKVM e NanoKVM Pro corrigem a exposição de endpoint nas versões 2.3.1 e 1.2.4. Para Angeet ES3 KVM, o material analisado indica ausência de correção disponível para as duas falhas mais severas, o que exige compensações de rede e avaliação de substituição ou retirada de exposição.

A segmentação deve colocar os KVMs em VLAN dedicada de gerenciamento, com acesso restrito a administradores autorizados e sem publicação direta na internet. Quando houver suporte, a autenticação multifator deve ser aplicada. O acesso administrativo precisa passar por salto controlado, registro de sessão ou VPN corporativa, conforme a arquitetura local. Dispositivos com verificação fraca de firmware exigem cadeia de atualização controlada: obter firmware apenas por canais aprovados, registrar versão instalada, validar mudança por inventário e monitorar alterações não planejadas.

A resposta a incidente deve incluir o KVM na contenção. Se um host administrado por esses aparelhos apresentar comportamento recorrente após limpeza, a equipe deve isolar o KVM, revisar credenciais, capturar configuração, verificar firmware e examinar logs de rede antes de recolocar o equipamento em produção. A rotação de senhas administrativas, a remoção de contas não usadas e o bloqueio de caminhos de nuvem não necessários reduzem a probabilidade de abuso persistente.

• Aplicar firmware corrigido nas versões disponíveis para GL-iNet, JetKVM, Sipeed NanoKVM e NanoKVM Pro.
• Isolar IP KVM em VLAN de gerenciamento com regras explícitas de origem, destino e portas permitidas.
• Habilitar autenticação multifator quando suportada e revisar senhas, contas locais e permissões administrativas.
• Remover exposição direta à internet e verificar periodicamente a presença externa desses dispositivos.
• Monitorar tráfego, mudanças de firmware, provisionamento, tentativas de login e eventos de console associados aos hosts conectados.