Em 21 de outubro de 2026, duas vulnerabilidades críticas, PHP2Shell (CVE-2026-109618 e CVE-2026-109619), foram divulgadas publicamente. Ambas possuem nota 9.2 e permitem a execução remota de código em servidores vulneráveis. Portais governamentais, serviços públicos e sites comerciais em vários países ficaram offline por precaução enquanto as equipes corriam para aplicar as correções.
Mas as falhas já eram conhecidas em 20 de outubro, e a correção só foi disponibilizada no dia 21. É nessa lacuna que os atacantes operam, e isso levanta a pergunta que toda equipe de segurança está fazendo: como proteger sistemas quando a vulnerabilidade é conhecida, mas a correção ainda não está disponível?
Onde a proteção baseada em assinatura falha
Os WAFs tradicionais dependem, pelo menos em parte, de assinaturas. Isso os torna previsíveis, mas também cria um atraso. Alguém precisa analisar o exploit, escrever a regra e distribuí-la; em muitos casos, os clientes ainda precisam realizar etapas manuais antes de estarem protegidos.
E se um exploit circular antes que seu fornecedor atualize o sistema? E se o atacante ajustar o payload para que ele não corresponda mais à assinatura? Com a IA ajudando atacantes a analisar falhas e gerar variantes de exploits em questão de horas, essa janela continua diminuindo.
O PHP2Shell torna isso ainda mais difícil. Ambas as CVEs decorrem de falhas de gerenciamento de memória no próprio motor PHP, e não da lógica de uma aplicação específica. Isso significa múltiplos caminhos de exploração com diferentes estruturas de requisição e condições de disparo. Uma assinatura que detecta uma variante não garante proteção contra a próxima.
Como é o ataque
Uma cadeia de ataque visando a CVE-2026-109618 inclui um campo PHP_SESSION_UPLOAD_PROGRESS em um upload multipart, mesmo que o endpoint da aplicação nunca o defina. Para um motor de assinatura, a requisição pode parecer um upload comum. (O payload neste exemplo foi omitido.)
Como a Salt enxerga isso
A Salt não precisa conhecer o exploit. A Salt aprende a estrutura de suas APIs, chamadas MCP e endpoints de aplicação: quais campos, parâmetros e formatos cada endpoint espera. Uma requisição contendo um campo PHP_SESSION_UPLOAD_PROGRESS para um endpoint que nunca aceitou um é uma anomalia, e nenhuma assinatura é necessária para detectá-la.
Mas detectar uma anomalia não é suficiente. Muitas requisições incomuns são inofensivas: uma nova versão de cliente, uma integração mal configurada, um desenvolvedor testando algo. Se cada anomalia gerar um alerta, os defensores se afogam em ruído e os ataques reais acabam passando despercebidos.
A peça que falta é a intenção. A detecção de intenção comportamental da Salt adiciona o contexto necessário para saber se uma anomalia está ligada a uma atividade maliciosa. A Salt analisa a maneira como o consumidor fez as requisições, compara com a forma como o endpoint da aplicação é usado normalmente e monitora e compara centenas de outros atributos comportamentais. Um campo estranho vindo de um cliente conhecido parece muito diferente do mesmo campo enviado por um consumidor que está sondando endpoints, alternando variações de payload e se comportando de forma totalmente diferente de um usuário legítimo.
A anomalia diz que algo está diferente. A intenção diz se é um ataque.
Já vimos esse filme antes
Isso não é um caso isolado. Quando o Log4Shell surgiu, a Salt detectou tentativas de exploração contra clientes antes mesmo de qualquer assinatura ter sido lançada. A vulnerabilidade era diferente, mas o princípio era o mesmo: ataques a falhas de infraestrutura ainda precisam chegar como requisições, e os consumidores que os enviam se comportam de maneira diferente dos usuários legítimos de suas APIs e endpoints de aplicação.
A detecção comportamental é eficaz exatamente nas situações em que as assinaturas falham. Quando uma falha reside na infraestrutura, e não no código da aplicação, uma única solicitação pode ser suficiente para assumir o controle de um sistema legítimo. Uma proteção que só começa a agir após a criação da assinatura chega tarde demais.
A conclusão: os ataques zero-day são apenas o aquecimento
Os ataques zero-day continuarão surgindo. O que está mudando é a superfície onde eles ocorrem.
À medida que as empresas avançam em suas transformações de IA, o tráfego entre máquinas cresce rapidamente. APIs, servidores MCP e agentes chamando outros agentes e serviços estão se multiplicando, e cada vez menos dessas chamadas envolvem qualquer intervenção humana. Isso significa mais alvos, mais consumidores e mais pontos onde uma única falha pode ser explorada.
Ao mesmo tempo, agentes de ameaças e agentes mal-intencionados não estão mais apenas batendo à porta. Eles já estão lá dentro. Uma vez lá, eles se comportam como qualquer outra carga de trabalho fazendo chamadas de API, e as ferramentas de perímetro criadas para inspecionar o tráfego na entrada muitas vezes nem chegam a detectá-los. Nesse ambiente, uma assinatura não tem nada com que comparar e uma anomalia estrutural por si só não é suficiente, porque quase tudo o que acontece internamente parece apenas uma máquina se comunicando com outra.
É por isso que a intenção importa mais do que nunca. A pergunta não é mais apenas "esta solicitação parece incomum?". É "quem está fazendo isso, como eles estão se comportando e o que estão tentando fazer?". O PHP2Shell é um exemplo claro da lacuna de correção, mas o cenário mais amplo é que essa lacuna agora existe em todos os lugares onde máquinas se comunicam com máquinas.
Os defensores precisam de uma proteção que entenda suas próprias APIs e a intenção de quem as está chamando, para que possam impedir ataques no dia zero, antes da correção, antes da assinatura e antes da variante que ninguém documentou ainda.
É para isso que a Salt foi criada.