CVE-2026-91843: falha crítica na Check Point pode permitir execução remota como root
Uma vulnerabilidade crítica identificada em servidores Check Point Security Management e Log Server pode permitir que um invasor remoto, sem autenticação, execute código arbitrário com privilégios de root. Catalogada como CVE-2026-91843, a falha recebeu pontuação 9,8 no CVSS, o que indica risco máximo e necessidade de correção prioritária.
Até 16 de setembro de 2026, não havia confirmação pública de exploração da vulnerabilidade em ataques reais. Também não havia, na verificação disponível, um exploit público confirmado nem registro da falha no catálogo Known Exploited Vulnerabilities da CISA. Ainda assim, a ausência de evidências de abuso não elimina o perigo, principalmente porque a exploração pode ocorrer remotamente e sem exigir credenciais.
Como a vulnerabilidade funciona
A CVE-2026-91843 está relacionada a um estouro de pilha no processo de login dos servidores de gerenciamento e registro de logs da Check Point. Um atacante capaz de alcançar o serviço vulnerável pela rede pode enviar dados especialmente manipulados e provocar a execução de comandos no sistema.
A falha combina vários fatores de alto risco:
– exploração remota;
– ausência de autenticação;
– baixa complexidade técnica;
– nenhuma interação do usuário;
– execução de código com privilégios de root.
Na prática, um ataque bem-sucedido pode comprometer a confidencialidade, a integridade e a disponibilidade do ambiente. O invasor poderia alterar configurações de segurança, acessar informações sensíveis, instalar mecanismos de persistência ou usar o servidor comprometido como ponto de entrada para outros sistemas.
Produtos e versões afetados
Os registros associados à vulnerabilidade apontam impacto nas seguintes versões do Quantum Security Management:
– R82.10 com Jumbo Hotfix Take 44 ou anterior;
– R82 com Take 126 ou anterior;
– R81.20 com Take 166 ou anterior;
– R81.10 com Take 190 ou anterior.
Também aparecem como afetadas versões antigas das linhas R81, R80.40, R80.30, R80.20, R80.10 e R80 que já estão fora do ciclo regular de suporte.
O Smart-1 Cloud não é afetado, pois a correção já havia sido aplicada ao serviço. Mesmo assim, administradores devem confirmar essa condição no ambiente utilizado e verificar se não existem componentes locais ou integrações independentes que permaneçam vulneráveis.
Correção recomendada pela Check Point
A orientação oficial é instalar o LivePatch indicado no artigo de suporte sk1000155. Clientes que mantêm as atualizações automáticas ativas já podem estar protegidos, mas essa condição precisa ser validada tecnicamente, e não presumida.
A equipe responsável deve:
1. identificar todos os servidores Security Management e Log Server em operação;
2. registrar a versão instalada e o nível do Jumbo Hotfix;
3. confirmar a aplicação do LivePatch;
4. reiniciar serviços ou equipamentos caso o procedimento exija;
5. repetir a verificação após a atualização;
6. documentar a correção para fins de auditoria.
Em ambientes de produção, a aplicação do patch deve ser planejada para reduzir impactos no gerenciamento das políticas, na coleta de logs e nas integrações com ferramentas de monitoramento.
Medidas de contenção
Enquanto a correção não for concluída, o acesso às interfaces de gerenciamento deve ser limitado ao menor conjunto possível de endereços confiáveis. A Check Point recomenda restringir os Trusted Clients a IPs internos, específicos e previamente conhecidos.
Também é importante:
– bloquear o acesso direto pela internet;
– separar a rede de gerenciamento das redes de usuários;
– utilizar firewalls intermediários e listas de controle;
– revisar regras de acesso remoto e VPN;
– monitorar tentativas incomuns de autenticação;
– restringir o acesso administrativo por estação e segmento de rede;
– verificar alterações inesperadas em políticas e objetos de segurança.
Essas medidas reduzem a superfície de ataque, mas não substituem a instalação do LivePatch. Como a falha não exige autenticação, controles baseados apenas em credenciais podem ser insuficientes caso o serviço continue exposto a uma rede não confiável.
Por que o impacto é tão elevado
Servidores de gerenciamento de segurança concentram funções privilegiadas e mantêm relações de confiança com gateways, dispositivos de rede, sistemas de registro e plataformas de monitoramento. Por isso, o comprometimento de um desses servidores pode ter consequências mais amplas do que a invasão de um equipamento isolado.
Com privilégios de root, um invasor pode tentar modificar políticas, interromper registros, apagar evidências, alterar regras de inspeção e interferir nos mecanismos usados para detectar incidentes. Em determinadas arquiteturas, o servidor também pode servir como caminho para movimentação lateral contra outros ativos administrados pela organização.
A priorização, portanto, não deve considerar somente a nota CVSS. A função desempenhada pelo ativo, sua exposição de rede e o nível de confiança com outros sistemas são fatores igualmente importantes.
Como investigar possíveis sinais de comprometimento
Mesmo sem exploração pública confirmada, organizações devem revisar os registros de segurança. A análise pode incluir:
– tentativas anormais de acesso ao processo de login;
– conexões originadas de endereços externos ou incomuns;
– criação inesperada de contas administrativas;
– alterações em políticas sem solicitação de mudança;
– processos desconhecidos executados com privilégios elevados;
– arquivos modificados em horários fora da rotina;
– interrupções ou falhas incomuns na coleta de logs;
– mudanças nos Trusted Clients e em regras de administração.
Caso sejam encontrados indícios suspeitos, o servidor deve ser tratado como potencialmente comprometido. A equipe deve preservar evidências, restringir o acesso ao equipamento, revisar credenciais administrativas e avaliar a necessidade de reconstrução a partir de uma imagem confiável.
Atenção especial a versões fora de suporte
Sistemas antigos representam um risco adicional porque podem não receber correções permanentes ou apresentar limitações de compatibilidade. Se a organização ainda utiliza uma versão fora de suporte, a instalação do patch disponível deve ser acompanhada de um plano de atualização para uma versão mantida pelo fabricante.
A migração deve considerar dependências, integrações, políticas existentes, capacidade dos appliances e procedimentos de recuperação. Manter plataformas legadas por tempo indefinido aumenta a exposição a novas vulnerabilidades e dificulta a resposta quando surgem falhas críticas.
Conclusão
A CVE-2026-91843 deve ser tratada como uma correção emergencial em ambientes Check Point potencialmente afetados. A possibilidade de execução remota sem autenticação e com privilégios de root torna a vulnerabilidade especialmente perigosa, ainda que não exista confirmação pública de exploração até a data analisada.
Administradores devem verificar versões e hotfixes, aplicar o LivePatch recomendado, restringir o acesso às interfaces de gerenciamento e revisar os registros em busca de sinais de abuso. A combinação entre correção rápida, segmentação de rede, monitoramento e atualização de plataformas antigas é a forma mais eficaz de reduzir o risco operacional.