Gateways Check Point invadidos via PHP2Shell: fabricante confirma ataques, backdoor e wiper

Monitoramento cibernético da Top-Secured: análise independente baseada nas fontes citadas abaixo. A Top-Secured não é afiliada às empresas mencionadas e nunca pedirá seus dados bancários nem suas senhas.

A Check Point afirma que atacantes exploraram as falhas PHP2Shell do portal Mobile Access de gateways sem correção e, em seguida, uma segunda falha para virar root. Em alguns alvos, instalaram um backdoor e passaram para hosts VMware ESXi para destruir arquivos.

O que aconteceu

Em 12 de novembro de 2026, a Check Point Research publicou uma análise de ataques contra os próprios firewalls do fabricante. Os atacantes usaram o PHP2Shell (CVE-2026-109618 e CVE-2026-109619), duas falhas do PHP que a Check Point avalia com nota 9,2 de 10 e tratou para seus gateways em um boletim publicado pela primeira vez em 21 de outubro. A atividade começou cerca de uma semana depois que a correção ficou disponível, ou seja, só gateways sem atualização foram atingidos. Uma primeira onda, em 30 de outubro, visou organizações israelenses, com destruição em algumas; uma segunda, em 2 de novembro, atingiu organizações de vários países e setores, sem destruição observada. A Check Point não informa o número de vítimas; seu boletim sobre a segunda falha menciona exploração ativa em algumas dezenas de clientes.

Como os atacantes entraram

A porta de entrada foi o portal Mobile Access exposto à Internet. Lá dentro, os atacantes usaram a CVE-2026-123039, uma falha local do serviço DynamicCLI, para obter privilégios de root. Eles deixaram webshells nos modelos do portal, um backdoor que sobrevive a reinicializações, uma biblioteca que funciona como proxy de rede e um scanner. A partir de alguns gateways, conectaram-se por SSH a hosts VMware ESXi e executaram ali um wiper para Linux. A Check Point vê semelhanças com ferramentas associadas a um grupo ligado à China, mas diz não conseguir determinar com segurança a verdadeira natureza da operação.

O que fazer agora

  1. Aplique a correção: Jumbo Hotfix Accumulator Take 14 ou posterior no R82.20, Take 52 no R82.10, Take 132 no R82, Take 174 no R81.20, ou o hotfix avulso da sk1000302 (exige reinicialização). Spark: R82.00.11 build 998002843 ou R81.10.17 build 996005005 e posteriores. Confira o Take instalado com cpinfo -y all.
  2. No R81.10 e anteriores (sem suporte), planeje uma atualização de versão: não há correção prevista para a CVE-2026-123039.
  3. Se não puder corrigir imediatamente, aplique a mitigação manual da sk1000302 e pare o dynamic_server conforme a sk1000362.
  4. Procure sinais de comprometimento, mesmo após a correção: /tmp/CPconfigdaemon, /lib/libcpfwcommon.so, arquivos zz*.tpl nos modelos do portal, um serviço escutando na porta TCP 11072 (netstat -tlnp) e os endereços IP publicados pela Check Point.
  5. Se encontrar algo, reinstale o gateway, troque seus segredos e certificados de VPN e verifique os hosts ESXi que ele consegue acessar.

Nossa opinião

Um firewall também é um servidor, e seus portais web usam as mesmas bibliotecas de qualquer site. Uma semana entre a correção e o ataque já é o normal: equipamentos de borda precisam do mesmo prazo de atualização que o servidor web mais exposto, e o acesso de administração deles aos hipervisores deve ser cortado.

Fontes

Como escolhemos, verificamos e escrevemos nossas análises →

O seu próprio servidor está exposto? Faça um teste gratuito — apenas informações públicas, sem intrusão:

Verificar um servidor Verificar um site

Preocupado com a exposição dos seus servidores? Nossa equipe audita, corrige e monitora infraestruturas Linux e cloud 24/7.

Fale com um especialista Nossos serviços de gestão de servidores →