Uma falha crítica no Check Point VPN deixou gateways corporativos abertos a invasores sem necessidade de senha durante 31 dias, entre 7 de maio e 8 de junho de 2026. Rastreada como CVE-2026-50751, com nota CVSS 9.3, a brecha permite que atacantes remotos não autenticados contornem a autenticação de Remote Access e Mobile Access e estabeleçam conexões VPN válidas. Pelo menos um caso confirmado levou ao ransomware Qilin, e a CISA adicionou a falha ao seu catálogo de vulnerabilidades exploradas no mesmo dia do anúncio oficial.

Resumo da falha crítica

  • CVE-2026-50751 afeta Check Point VPN e firewalls Spark configurados com o protocolo IKEv1 obsoleto.
  • Janela de 31 dias sem patch (7 de maio a 8 de junho de 2026), com ataque confirmado pelo ransomware Qilin.
  • Mitigação imediata: aplicar o hotfix SK185033, desativar IKEv1 e exigir certificado de máquina.

O que é a falha CVE-2026-50751

A vulnerabilidade é uma falha de by-pass de autenticação causada por uma fraqueza no fluxo lógico de validação de certificados nas lâminas (blades) de Remote Access VPN e Mobile Access dos Security Gateways da Check Point. Para que um gateway seja explorável, ele precisa estar configurado para usar o protocolo de troca de chaves IKEv1, uma tecnologia legada mantida por compatibilidade com clientes antigos. Quando essa condição existe, um atacante remoto e não autenticado consegue estabelecer uma sessão VPN sem possuir uma senha de usuário válida.

A nota CVSS de 9.3 coloca o problema na categoria de severidade crítica. A própria Check Point classificou o risco como alto e confirmou que, segundo sua investigação, a exploração esteve limitada a algumas dezenas de organizações visadas globalmente, mas com tentativas em aumento no início de junho. Ou seja: o ataque era cirúrgico e direcionado, não um varredura massiva, o que dificulta a detecção pelas equipes de segurança.

A janela crítica de 31 dias

O detalhe mais alarmante desta história é a linha do tempo. A Check Point só abriu a investigação interna em 4 de junho, quase um mês depois da primeira exploração conhecida, datada de 7 de maio. O hotfix SK185033 só chegou em 8 de junho, encerrando uma janela de 31 dias durante a qual não existia patch público nem identificador CVE divulgado. Isso significa que qualquer gateway exposto esteve, na prática, com a porta aberta por um mês inteiro.

No mesmo dia 8 de junho, a agência federal norte-americana CISA adicionou a falha ao seu catálogo Known Exploited Vulnerabilities (KEV) e impôs um prazo de 72 horas para que agências civis federais aplicassem a correção. Para o setor privado, esse prazo não é obrigatório, mas funciona como um sinal claro: quando a CISA move tão rápido, é porque o risco é real. Essa foi a escalada mais rápida de um zero-day de VPN feita pela agência em 2026.

Como o Qilin ransomware entrou

A Check Point avaliou com média confiança que o grupo por trás da exploração é financeiramente motivado e opera como afiliado do ransomware Qilin. Em pelo menos um caso confirmado, a invasão pelo Check Point VPN levou a atividade pós-comprometimento associada ao Qilin, o que inclui roubo de dados, movimentação lateral e, por fim, a criptografia e extorsão típica de operações de ransomware.

Os indícios técnicos são consistentes com uma operação profissional. O atacante utilizou o software de código aberto Rclone para exfiltrar dados, comunicou-se pelo protocolo Tox e operou a partir de infraestrutura de servidores privados virtuais (VPS) hospedada em provedores como Kaupo Cloud HK, Shock Hosting e Vultr Holdings. A própria Check Point alertou que essa mesma infraestrutura provavelmente explora outras vulnerabilidades de VPN publicadas por Palo Alto, Fortinet e F5. Ou seja, o Qilin trata a borda de VPN como um alvo sistemático e não um acaso.

Quais produtos são afetados

Nem todo gateway Check Point está exposto. A vulnerabilidade exige uma configuração específica (IKEv1 habilitado). A tabela abaixo resume o alcance:

Produto Condição para risco Patch disponível
Security Gateway com Remote Access VPN IKEv1 habilitado Hotfix SK185033 (R81.20+)
Security Gateway com Mobile Access / SSL VPN IKEv1 habilitado Hotfix no dia 8 de junho
Spark Firewall (PMEs e MSPs) IKEv1 para Remote Access Hotfix no dia 8 de junho
Gateways em fim de suporte (R80.20.X, R80.40, R81, R81.10) IKEv1 habilitado Sem patch

O ponto crítico aqui é o último: gateways em versões sem suporte, como R80.20.X, R80.40, R81 e R81.10, não receberam correção alguma. Para quem ainda roda essas versões, a única proteção real é desativar o IKEv1 ou isolar o equipamento até uma atualização completa.

IKEv1: protocolo obsoleto e arriscado

O fator comum a toda essa cadeia de ataques é o IKEv1, o protocolo de troca de chaves definido no RFC 2409, lá de 1998. Ele foi substituído pelo IKEv2 (RFC 7296) há mais de uma década, mas permanece habilitado em muitos ambientes por compatibilidade com clientes legados. O problema estrutural é claro: manter um protocolo obsoleto ativo só porque algo antigo ainda depende dele cria uma superfície de ataque permanente.

As mitigações indicadas pela Check Point seguem exatamente essa lógica. A primeira e mais eficaz é garantir que o deployment não use IKEv1, migrando para IKEv2. As demais incluem remover o suporte a conexões de cliente de Remote Access legado e exigir um certificado de máquina válido para estabelecer a conexão. Nenhum desses passos é novidade para quem acompanha boas práticas, mas a realidade é que milhares de gateways ainda rodam com configurações perigosas apenas para não quebrar compatibilidade.

O que fazer agora

Para equipes de segurança que administram Check Point VPN, a lista de ações imediatas é direta:

  1. Aplicar o hotfix SK185033 em todas as versões com suporte, sem esperar janela de manutenção.
  2. Desativar o IKEv1 e migrar para IKEv2 onde for possível, eliminando o vetor de raiz.
  3. Auditar logs desde 7 de maio de 2026, buscando conexões VPN de origens anômalas ou de geolocalização incompatível com o usuário.
  4. Verificar os indicadores de comprometimento divulgados pela Check Point, incluindo os IPs e hashes de arquivo ligados ao afiliado do Qilin.
  5. Planejar a atualização de gateways em fim de suporte, que ficaram sem correção e seguem expostos.

Em organizações que já sofreram atividade suspeita, a prioridade é o response forense: revisar configuração, rastrear movimentação lateral e confirmar se houve exfiltração via ferramentas como o Rclone antes de qualquer notificação de incidente.

Risco real para o Brasil

O Check Point VPN é uma das soluções de perímetro mais usadas por empresas brasileiras de médio e grande porte, incluindo instituições financeiras, indústrias e operadoras. A combinação de um produto amplamente implantado com uma falha que dispensa senha e abre caminho para ransomware é exatamente o cenário que mais preocupa times de TI no país. E o problema não se limita à Check Point: a constatação de que o mesmo grupo explora falhas equivalentes em Palo Alto, Fortinet e F5 mostra que a borda de VPN virou o vetor de acesso inicial favorito de operações financeiramente motivadas.

Para quem busca contexto mais amplo sobre como o ransomware evoluiu como ameaça, vale conferir nosso relato sobre como o ransomware Gentlemen usou EDR-killer contra 504 vítimas e o caso da VPN da Palo Alto hackeada pela falha CVE-2026-0257, que segue o mesmo padrão de exploração de perímetro. Também recomendamos a leitura sobre o alerta da CISA sobre falhas com exploração ativa, que reforça a urgência de manter o catálogo KEV sob vigilância constante.

A lição central do CVE-2026-50751 não é técnica, mas operacional: protocolos obsoletos mantidos por inércia são um passivo de segurança. Enquanto equipes adiarem a remoção do IKEv1 e de configurações legadas, ataques como este continuarão encontrando a porta entreaberta. O patch existe, mas a verdadeira correção é eliminar a dependência do que já deveria ter saído de cena há muito tempo.

Referências