Se a sua empresa usa um firewall SonicWall, ou se terceiriza a TI para um provedor de serviços gerenciados (MSP) que acessa seus sistemas remotamente para mantê-los atualizados e com backups, você tem dois motivos distintos para fazer uma ligação esta semana. Ambos envolvem vulnerabilidades que os invasores estão explorando neste momento, não riscos teóricos em um boletim do fornecedor que ninguém lê. Nenhum deles exige que você se torne especialista em segurança. O que é necessário é fazer perguntas específicas e esperar respostas específicas — datas, números de versão, confirmações — e não garantias vagas.

Veja o que está acontecendo em cada caso e uma lista de verificação que você pode copiar, colar e enviar a quem gerencia sua rede.

Problema 1: seu firewall SonicWall (CVE-2026-15409 e CVE-2026-15410)

A SonicWall divulgou e corrigiu duas vulnerabilidades em 14 de julho de 2026 — mas, segundo a própria linha do tempo da empresa, os invasores já as exploravam havia cerca de três semanas antes da divulgação pública. Isso significa que “corrigido agora” e “seguro agora” não são automaticamente a mesma coisa para um equipamento que ficou exposto à internet durante esse período.

O agente de ameaça mais consistentemente mencionado em conexão com essa cadeia de vulnerabilidades é o INC, uma operação de ransomware como serviço que pesquisadores da Rapid7 descrevem como um dos grupos desse tipo mais ativos no mundo atualmente (embora nem todo ataque que usa essas falhas tenha sido definitivamente associado especificamente ao INC — é quase certo que outros invasores oportunistas também estejam envolvidos). Separadamente, a empresa de segurança Huntress relatou uma onda rápida de ataques na qual 30 clientes da SonicWall foram comprometidos em menos de dois dias. Este não é um risco de evolução lenta.

Também há um histórico relevante aqui: a SonicWall divulgou anteriormente um incidente no qual um grupo patrocinado por um Estado roubou arquivos de configuração de firewall de todos os clientes da SonicWall que usavam seu recurso de backup na nuvem. Um arquivo de configuração roubado pode conter credenciais de contas locais e configurações de VPN. Se a configuração do seu firewall já foi copiada para o serviço de nuvem da SonicWall antes de o incidente ser contido, corrigir as falhas atuais não desfaz o que já foi exposto — talvez ainda seja necessário trocar as credenciais desse arquivo de configuração.

Lista de verificação para enviar ao seu provedor de TI ou MSP:

  • “Qual modelo e versão de firmware da SonicWall estamos usando atualmente, e essa versão corrige as CVE-2026-15409 e CVE-2026-15410?” (Peça que confirmem com base no próprio comunicado da SonicWall — não aceite “estamos na versão mais recente” sem um número de versão.)
  • “Em que data aplicamos a correção?” Se foi depois de 14 de julho de 2026, peça que verifiquem os logs das semanas anteriores em busca de sinais de acesso não autorizado — logins inesperados de administradores, novas contas locais ou sessões de SSLVPN provenientes de endereços IP desconhecidos.
  • “Nossa SSLVPN ou nosso portal de acesso remoto ficou exposto à internet durante esse período?” Se sim, peça uma redefinição obrigatória de senha para todas as contas que se autenticam por ele, não apenas a aplicação de uma correção.
  • “A configuração do nosso firewall já foi copiada para o serviço de nuvem da SonicWall e, em caso afirmativo, as credenciais desse arquivo de configuração foram trocadas desde então?”
  • “A autenticação multifator está habilitada em todas as contas de acesso remoto pelo firewall?” Caso não esteja, peça que a habilitem esta semana.

Problema 2: a ferramenta de gerenciamento remoto do seu MSP (CVE-2026-18577 no N-able N-central)

Este caso é diferente porque não se trata do seu equipamento — é uma ferramenta que seu provedor de TI pode usar para gerenciar dezenas ou centenas de empresas clientes, possivelmente incluindo a sua, a partir de um console central. O N-able N-central é uma dessas plataformas, e a CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA) adicionou uma vulnerabilidade nele — a CVE-2026-18577, classificada com gravidade 8,2 em 10 — ao seu catálogo de Vulnerabilidades Conhecidamente Exploradas depois de confirmar a exploração ativa desde 31 de julho de 2026. Segundo relatos, a falha permite que um invasor obtenha acesso administrativo completo ao próprio console do N-central.

Isso importa por causa do que um invasor pode fazer a partir dali. A Huntress relatou que ataques bem-sucedidos avançaram do console comprometido para os endpoints gerenciados por meio dele — o que significa que uma violação da ferramenta do MSP pode se transformar em uma violação dos seus sistemas sem que o invasor jamais tenha como alvo você diretamente. A Huntress também descobriu invasores criando túneis da Cloudflare em sistemas comprometidos, uma técnica que lhes dá uma forma persistente e criptografada de voltar ao sistema e que pode parecer tráfego web comum para um firewall.

Você não precisa saber se o seu provedor específico usa o N-central. Você precisa perguntar, e perguntar de forma mais ampla do que apenas pelo nome desse produto.

Lista de verificação para enviar ao seu provedor de TI ou MSP:

  • “Vocês usam o N-able N-central ou algum outro produto da N-able para gerenciar nossos sistemas?” Se sim: “Ele está corrigido contra a CVE-2026-18577 e, a partir de que data?”
  • “Vocês auditaram a atividade das contas de administrador e os logs de acesso no console de gerenciamento desde 31 de julho de 2026, em busca de algo que não consigam explicar?”
  • “Vocês verificaram especificamente nossos sistemas em busca de conexões externas inesperadas — particularmente processos de túnel da Cloudflare (às vezes exibidos como ‘cloudflared’) ou domínios de túnel que vocês não configuraram?”
  • “Alguma nova conta de administrador local, tarefa agendada ou política de gerenciamento remoto foi enviada aos nossos sistemas sem que vocês consigam atribuí-la à própria equipe?”
  • “Se vocês não usam o N-central, qual ferramenta de gerenciamento remoto usam no lugar dele e ela teve recentemente alguma vulnerabilidade adicionada ao catálogo de Vulnerabilidades Conhecidamente Exploradas da CISA?”

O que fazer com as respostas

Um bom provedor de TI responderá a essas perguntas com datas e detalhes, geralmente em até um dia, porque já deveria ter essas informações ou ser capaz de obtê-las rapidamente nos logs. Uma resposta vaga — “estamos cuidando disso”, “nossos sistemas estão seguros”, sem nenhuma data — também é uma informação útil: ela mostra que essa conversa precisa acontecer novamente, por escrito, com um prazo definido.

Se você gerencia sua própria SonicWall sem um MSP, a lista de verificação acima continua se aplicando diretamente a você — faça login no console de gerenciamento, verifique a versão do firmware e consulte a página de comunicados da SonicWall para descobrir a versão que corrige as duas CVEs.

Nenhuma dessas falhas exige que você rompa com um fornecedor ou demita um prestador de serviços. Elas exigem a confirmação de que a lacuna específica foi fechada e de que nada passou por ela enquanto esteve aberta. Faça as perguntas, obtenha as datas e coloque um lembrete no seu calendário para perguntar novamente na próxima vez que um fornecedor divulgar algo "explorado ativamente". Isso acontecerá novamente.