Um equipamento instalado para impedir invasores de entrar na rede pode, quando vulnerável, acabar se transformando:
na própria porta de entrada.
A Check Point liberou atualizações emergenciais para duas vulnerabilidades críticas encontradas no processamento de certificados relacionado a VPNs em seus produtos de segurança.
As falhas receberam as identificações:
CVE-2026-85102
e
CVE-2026-85103.
As duas receberam pontuação:
CVSS 9,8 de 10.
E compartilham uma característica particularmente preocupante:
podem permitir que um atacante remoto e não autenticado execute código arbitrário em sistemas afetados, sob determinadas condições.
Isso significa que, no cenário descrito para as vulnerabilidades, o invasor não precisaria possuir previamente:
usuário;
senha;
conta administrativa;
sessão autenticada.
Também não seria necessária interação de um funcionário, como:
abrir um arquivo ou clicar em um link.
Não é apenas uma falha de “validação de certificado”
A descrição que circula nas redes sociais pode fazer o problema parecer menos grave do que realmente é.
Embora certificados estejam no centro das duas vulnerabilidades, a consequência potencial não se limita a:
aceitar certificado incorreto;
permitir conexão indevida;
burlar uma verificação.
O impacto indicado nos registros das vulnerabilidades é:
execução remota de código — RCE.
Em equipamentos posicionados no perímetro da rede, isso coloca as falhas entre as categorias que merecem atenção imediata das equipes de segurança.
A primeira vulnerabilidade é a CVE-2026-85102
Ela está relacionada à:
validação inadequada da confiança de certificados durante a negociação VPN.
Em termos simples, um certificado digital funciona como uma espécie de:
identidade criptográfica.
Durante determinadas conexões, sistemas precisam verificar se aquele certificado:
é válido;
foi emitido corretamente;
pertence à cadeia de confiança esperada;
pode ser aceito naquele contexto.
A CVE-2026-85102 ocorre justamente nessa etapa de validação.
O resultado pode ser execução de código no gateway
Segundo a descrição técnica da vulnerabilidade, a falha pode permitir que:
um atacante remoto não autenticado execute código arbitrário no Security Gateway.
O vetor CVSS ajuda a entender por que a nota chegou a 9,8:
ataque pela rede;
baixa complexidade;
nenhum privilégio necessário;
nenhuma interação do usuário.
Além disso, os impactos potenciais sobre:
confidencialidade;
integridade;
disponibilidade
foram classificados como:
altos.
Isso é praticamente a combinação que defensores não querem encontrar
Imagine uma vulnerabilidade que exige:
acesso físico;
conta administrativa;
clique da vítima;
configuração extremamente rara.
Ela ainda pode ser grave, mas existem várias barreiras.
Agora imagine outra que, sob as condições necessárias, pode ser alcançada:
remotamente pela rede.
Sem autenticação.
Sem clique.
Com baixa complexidade indicada pelo CVSS.
É exatamente esse conjunto de características que ajuda a explicar:
9,8.
A segunda falha é diferente
A CVE-2026-85103 também está relacionada ao processamento de certificados VPN, mas o problema técnico é outro.
Nesse caso existe um:
heap-based buffer overflow.
A falha acontece durante a decodificação da estrutura:
ASN.1
de um certificado VPN.
ASN.1 é amplamente utilizada em sistemas criptográficos
ASN.1 significa:
Abstract Syntax Notation One.
É uma linguagem utilizada para representar estruturas de dados e aparece em diversos protocolos e formatos relacionados a:
telecomunicações;
certificados;
criptografia;
redes.
Certificados digitais normalmente carregam estruturas complexas que precisam ser:
interpretadas pelo software.
E interpretar dados enviados por outra parte é uma operação extremamente sensível.
Um certificado malformado pode atingir a memória
No caso da CVE-2026-85103, o problema está no processamento dessas informações.
Um erro de:
heap buffer overflow
significa que o programa pode escrever dados além dos limites de uma região de memória alocada no heap.
Dependendo da implementação e da capacidade de exploração, vulnerabilidades desse tipo podem permitir:
travamento;
corrupção de memória;
alteração do fluxo de execução;
execução arbitrária de código.
É justamente a última possibilidade que aparece no registro dessa vulnerabilidade.
A CVE-2026-85103 também recebeu 9,8
O vetor CVSS novamente aponta:
ataque pela rede;
baixa complexidade;
nenhum privilégio;
nenhuma interação do usuário;
alto impacto sobre confidencialidade;
alto impacto sobre integridade;
alto impacto sobre disponibilidade.
Ou seja:
CVSS 9,8.
E a segunda vulnerabilidade alcança também o sistema de gerenciamento
Essa diferença é importante.
A CVE-2026-85102 está descrita especificamente em relação ao:
Quantum Security Gateway.
Já a CVE-2026-85103 pode afetar:
Quantum Security Gateway
e
Quantum Security Management.
O segundo é utilizado justamente para administrar a infraestrutura de segurança.
Firewalls e gateways são alvos especialmente valiosos
Imagine a arquitetura tradicional de uma empresa.
Internet.
Depois:
firewall.
Depois:
rede interna.
O firewall existe para controlar:
o que entra;
o que sai;
quem conecta;
quais serviços são permitidos.
Agora imagine comprometer:
o próprio firewall.
O atacante deixa de estar simplesmente tentando atravessar uma barreira.
Ele passa potencialmente a controlar:
a barreira.
É por isso que vulnerabilidades em equipamentos de perímetro são tão perigosas
VPN gateways, firewalls e appliances semelhantes costumam possuir uma característica inevitável:
precisam estar acessíveis pela rede.
Um serviço de Remote Access VPN, por exemplo, existe justamente para receber conexões externas.
Isso significa que uma vulnerabilidade pré-autenticação pode ser particularmente valiosa para criminosos.
A VPN é uma das portas legítimas da empresa
O trabalhador remoto precisa entrar.
O administrador precisa entrar.
A filial precisa conversar com outra unidade.
Para isso existe:
VPN.
O problema é que qualquer serviço exposto para receber usuários legítimos também pode ser encontrado por:
atacantes.
Por isso, gateways VPN tornaram-se alvos recorrentes de grupos de:
ransomware;
espionagem;
acesso inicial.
Um invasor não precisa necessariamente atacar o notebook
Muitas campanhas começam com:
phishing.
Mas existe outro caminho:
explorar o equipamento que conecta todos os notebooks à rede.
Se o atacante encontra uma vulnerabilidade no gateway:
não precisa convencer ninguém a clicar.
Isso pode eliminar uma das maiores dificuldades de um ataque:
a interação humana.
As versões afetadas precisam ser verificadas com cuidado
Os registros publicados para as duas vulnerabilidades apontam como afetadas as seguintes ramificações, dentro dos limites de Jumbo Hotfix indicados:
R82.10 — Jumbo Hotfix Take 43 ou anterior;
R82 — Jumbo Hotfix Take 125 ou anterior;
R81.20 — Jumbo Hotfix Take 165 ou anterior.
Isso não significa que qualquer equipamento Check Point existente no mundo esteja vulnerável.
A exposição depende de:
produto;
versão;
hotfix;
configuração;
serviços utilizados.
A Check Point começou a distribuir correções em 9 de setembro
A empresa divulgou as vulnerabilidades e iniciou a disponibilização das proteções em:
9 de setembro de 2026.
Existem dois caminhos principais para atualização.
Um deles é:
Check Point Live Patch.
A tecnologia permite aplicar determinadas correções de segurança rapidamente sem depender necessariamente de uma atualização completa tradicional.
O Live Patch começou a ser distribuído automaticamente
Clientes elegíveis utilizando esse mecanismo começaram a receber proteção com o rollout iniciado pela Check Point.
Outra alternativa é instalar:
Jumbo Hotfix Accumulator atualizado
correspondente à versão utilizada.
Administradores precisam verificar exatamente:
produto;
release;
Take instalado;
proteção aplicada.
CERT-EU pediu atualização imediata
O CERT-EU publicou um alerta específico sobre as duas vulnerabilidades e recomendou que organizações apliquem:
os hotfixes disponíveis o mais rápido possível.
A prioridade deve ser dada principalmente a:
appliances de perímetro e sistemas expostos à internet.
Essa recomendação faz sentido.
Quanto mais acessível estiver o componente vulnerável:
maior pode ser a superfície de ataque.
A CVE-2026-85103 possui uma nuance especialmente interessante
Embora esteja relacionada ao processamento de certificados VPN, a discussão técnica da Check Point indicou que o cenário pode não se limitar simplesmente a:
“VPN ligada = vulnerável; VPN desligada = seguro.”
Um representante da empresa explicou que o problema está relacionado ao:
processamento de certificados.
Em teoria, portanto, determinados ambientes que não estejam usando ativamente a VPN ainda podem exigir análise caso:
certificados VPN estejam presentes.
Isso torna perigoso confiar apenas em:
“não usamos VPN, então podemos ignorar.”
Administradores precisam verificar a orientação específica do fabricante
Essa é a resposta correta para uma vulnerabilidade desse tipo.
Não assumir.
Não generalizar.
Não concluir apenas pela descrição resumida.
É necessário conferir:
versão;
configuração;
certificados;
hotfix;
status do Live Patch.
Nenhum ataque conhecido — por enquanto
A Check Point afirmou que encontrou:
as duas vulnerabilidades internamente.
Até a divulgação, a empresa não tinha indicação de que:
CVE-2026-85102
ou
CVE-2026-85103
estivessem sendo exploradas em ataques reais.
Isso é uma boa notícia.
Mas existe uma diferença enorme entre:
“não há exploração conhecida”
e
“a vulnerabilidade não será explorada.”
A divulgação inicia uma corrida
Antes da publicação:
poucas pessoas conheciam os detalhes.
Depois:
defensores sabem;
pesquisadores sabem;
criminosos sabem.
Todos podem começar simultaneamente a:
analisar patches;
comparar versões;
estudar código;
procurar equipamentos expostos;
desenvolver provas de conceito.
Isso cria uma janela crítica:
patch gap.
Patch gap é o intervalo entre correção e atualização
O fabricante publica:
patch.
Mas empresas levam:
horas;
dias;
semanas
para instalá-lo.
Durante esse período, o atacante possui uma informação valiosa:
existe uma falha e existe uma correção para estudar.
Comparando software antes e depois da atualização, pesquisadores podem descobrir exatamente:
o que mudou.
Essa técnica é conhecida como:
patch diffing.
O patch pode ensinar como explorar
É um paradoxo da segurança.
Para proteger clientes, o fabricante precisa:
corrigir.
Mas a correção revela pistas sobre:
onde estava o problema.
Atacantes podem comparar:
binários;
funções;
validações;
fluxos.
E tentar reconstruir:
a vulnerabilidade.
Por isso, vulnerabilidades críticas em equipamentos de perímetro precisam ser corrigidas:
rapidamente.
O histórico recente da Check Point torna o alerta ainda mais importante
Em junho de 2026, a própria Check Point revelou outra vulnerabilidade crítica em sua infraestrutura VPN:
CVE-2026-50751.
Ela afetava determinadas implantações de Remote Access VPN e Mobile Access configuradas com o protocolo legado:
IKEv1.
Nesse caso, havia:
exploração ativa.
Aquela falha permitia contornar autenticação
A CVE-2026-50751 explorava uma fraqueza lógica relacionada à validação de certificados.
Um atacante podia estabelecer uma sessão VPN sem possuir:
uma senha válida.
A Check Point afirmou ter observado ataques contra algumas dezenas de organizações.
Em pelo menos um caso, atividade posterior ao comprometimento foi associada a um afiliado do ransomware:
Qilin.
Mas atenção: não confunda as vulnerabilidades
Esse detalhe é extremamente importante.
As novas:
CVE-2026-85102
e
CVE-2026-85103
não são a mesma vulnerabilidade explorada em junho.
E, até agora:
não existe indicação pública de exploração das duas novas falhas.
Misturar os casos poderia gerar a falsa impressão de que os CVEs recém-divulgados já estão sendo utilizados pelo Qilin.
Não há evidência pública disso.
A conexão está no tipo de superfície atacada
Os casos mostram um problema recorrente:
VPNs são infraestrutura crítica.
Em junho:
uma falha de autenticação.
Agora:
duas vulnerabilidades capazes de levar a execução remota de código.
Isso reforça uma lição conhecida por equipes de segurança:
equipamento de segurança também precisa ser protegido.
Firewall não é invisível para o atacante
Existe uma percepção equivocada de que instalar:
firewall;
VPN;
EDR;
antivírus
automaticamente reduz o risco.
Essas tecnologias reduzem riscos quando:
configuradas;
monitoradas;
atualizadas.
Mas elas próprias possuem:
software.
E software possui:
vulnerabilidades.
Quanto mais privilegiado o equipamento, maior o impacto potencial
Um firewall possui acesso privilegiado à rede.
Um VPN gateway autentica usuários.
Um servidor de gerenciamento controla políticas.
Um controlador de domínio administra identidades.
Um hypervisor controla máquinas virtuais.
Por isso, vulnerabilidades nesses componentes são tão valiosas.
O invasor não quer comprometer apenas:
uma máquina.
Ele procura comprometer:
o ponto que controla várias máquinas.
O CVSS 9,8 não significa que todos serão invadidos
Outra distinção importante.
CVSS mede:
severidade técnica potencial.
Não mede automaticamente:
probabilidade real de ataque;
quantidade de equipamentos vulneráveis;
número de vítimas;
exploração confirmada.
Uma vulnerabilidade 9,8 pode nunca ser amplamente explorada.
Uma vulnerabilidade 7,0 pode virar parte de uma campanha enorme.
Mas 9,8 exige atenção imediata
Nesse caso, a combinação é particularmente preocupante:
remoto + não autenticado + sem interação + execução de código.
Isso é exatamente o tipo de vulnerabilidade que deve chegar rapidamente à fila prioritária de:
SOC;
Blue Team;
administradores de rede;
equipes de infraestrutura.
Empresas precisam começar pelo inventário
A primeira pergunta não é:
“fomos atacados?”
É:
“temos algum produto afetado?”
Isso exige inventário atualizado.
Qual appliance?
Qual versão?
Qual Take?
Qual função?
Qual exposição?
Sem inventário, até uma excelente correção pode não chegar:
ao equipamento certo.
Depois vem a verificação do patch
Administradores devem confirmar se a proteção:
foi realmente aplicada.
Não basta presumir que:
“tem atualização automática.”
Sistemas corporativos podem possuir:
políticas diferentes;
janelas de manutenção;
Live Patch desativado;
versões fora de suporte;
restrições operacionais.
A confirmação precisa ser:
técnica.
Sistemas expostos à internet merecem prioridade
Se houver dezenas de appliances para atualizar, a ordem importa.
Primeiro:
perímetro.
Depois:
sistemas acessíveis por redes menos confiáveis;
ambientes internos;
laboratórios.
É justamente por isso que o CERT-EU destacou appliances:
internet-facing.
Também é prudente revisar logs
Mesmo sem exploração conhecida publicamente, organizações podem aproveitar a atualização para revisar:
conexões incomuns;
falhas de negociação;
eventos de VPN;
alterações administrativas;
processos inesperados;
comunicações externas anômalas.
A ausência de exploração conhecida pelo fabricante não prova que:
nenhum ataque jamais ocorreu em lugar algum.
A boa notícia é que a correção chegou antes de ataques conhecidos
Essa é exatamente a situação que defensores preferem.
Vulnerabilidade descoberta.
Fabricante informado.
Correção preparada.
Divulgação coordenada.
Nenhuma exploração conhecida.
Agora existe uma oportunidade:
fechar a porta antes que alguém tente entrar.
Mas essa oportunidade tem prazo
A partir do momento em que dois CVEs com:
9,8
e potencial de:
RCE sem autenticação
se tornam públicos, o interesse ofensivo tende a aumentar.
Pesquisadores vão estudar.
Empresas vão corrigir.
E criminosos também podem estudar.
A corrida já começou.
O maior erro seria esperar aparecerem ataques
Existe uma lógica perigosa:
“não está sendo explorado, então podemos atualizar depois.”
Mas vulnerabilidades de perímetro funcionam exatamente ao contrário.
A melhor situação é:
corrigir antes da primeira exploração.
Esperar evidências de ataques significa permitir que:
os criminosos definam o cronograma.
A Check Point conseguiu descobrir as duas falhas internamente
Esse detalhe também merece destaque.
Segundo as informações disponíveis, ambas foram encontradas pela própria empresa.
Isso possibilitou desenvolver:
correções;
Live Patch;
orientações
antes que existissem evidências públicas de exploração.
É o cenário ideal de:
defesa antecipada.
Agora a responsabilidade passa para quem administra os equipamentos
A Check Point publicou a correção.
CERT-EU emitiu alerta.
Os CVEs são públicos.
A severidade é conhecida.
A partir daqui, cada organização precisa responder:
meu ambiente está exposto?
Porque equipamentos de segurança ocupam uma posição paradoxal.
Eles existem para proteger:
a entrada da rede.
Mas quando uma vulnerabilidade crítica aparece justamente neles, a mesma entrada criada para proteger usuários legítimos pode se transformar:
no caminho que o atacante estava procurando.
E com duas falhas nota 9,8 permitindo potencial execução remota de código sem autenticação, esperar para descobrir se criminosos irão explorá-las é uma aposta que equipes de segurança:
não precisam fazer.
