Na quarta-feira, 21 de outubro, o PHP publicou duas correções emergenciais para as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, que permitem execução remota de código em servidores com WordPress, MediaWiki, Magento, Joomla, Laravel e Drupal. A orientação é atualizar imediatamente as releases da linha 8.x. Para quem responde pelo risco da organização, a pergunta mais importante é quanto tempo a empresa leva para descobrir onde essas aplicações estão e corrigi-las antes que alguém as explore.
Por que uma falha no PHP atinge tantas empresas ao mesmo tempo?
O PHP sustenta uma parte grande das aplicações web corporativas, e muitas vezes isso acontece fora do radar da área de segurança. O site institucional mantido por uma agência roda em WordPress, a loja virtual foi construída em Magento, a base de conhecimento interna usa MediaWiki e a API de um fornecedor foi desenvolvida em Laravel. Cada uma dessas aplicações tem um responsável diferente, um ciclo de atualização diferente e, em muitos casos, nenhum registro centralizado que indique a versão do PHP em uso.
Quando a vulnerabilidade permite execução remota de código, o atacante passa a executar comandos no servidor com as permissões da aplicação, o que abre caminho para bancos de dados, credenciais armazenadas e outros sistemas da mesma rede. As correções foram liberadas às 11h no horário de Brasília, e a partir desse momento a própria correção pública passa a indicar aos atacantes onde procurar, o que torna o intervalo entre a divulgação e a exploração cada vez mais curto.
O que muda quando a IA reduz a experiência necessária para atacar?
Uma pesquisa divulgada pelo The Register avaliou dez modelos de IA em 16.980 testes realizados entre outubro de 2025 e setembro de 2026, com 576 ataques simulados contra sistemas industriais. Os três modelos com melhor desempenho elaboraram planos de ataque viáveis em cerca de 90% das tentativas de planejamento, e os pesquisadores afirmam que a tecnologia já permite desenvolver em dias ferramentas que antes levariam meses de trabalho.
Os mesmos pesquisadores ressaltam que os modelos ainda cometem erros e que o julgamento humano continua sendo necessário, e esse ponto merece atenção para que a análise não caia no alarmismo. Ainda assim, a consequência prática para quem gerencia risco é clara, porque o número de pessoas capazes de transformar uma CVE recém-publicada em um ataque funcional tende a crescer, enquanto o prazo que a empresa tem para corrigir tende a diminuir.
Por que o pentest anual não responde a esse tipo de cenário?
Um relatório de pentest descreve o ambiente no período em que o teste foi feito. Uma aplicação avaliada em março e aprovada sem achados críticos pode estar exposta em outubro por causa de uma dependência que ninguém da equipe controla diretamente, como aconteceu agora com o PHP. O mesmo vale para mudanças internas, já que uma migração de infraestrutura, uma nova integração ou a troca de um fornecedor alteram a arquitetura testada e reduzem a utilidade do relatório em poucas semanas.
O risco aumenta quando o pentest é mal executado. Uma varredura automatizada entregue com selo de pentest gera um PDF com centenas de itens sem priorização e sem contexto de negócio, e o conselho recebe a informação de que a empresa foi testada, o que cria uma sensação de cobertura que não corresponde à realidade. No dia em que surge uma falha como a do PHP, esse documento não ajuda a responder onde está a exposição, quem é o responsável pela correção e qual é o impacto se nada for feito.
Como traduzir uma CVE em uma decisão de conselho
A mesma vulnerabilidade tem pesos diferentes conforme o ativo que ela coloca em risco. Para um banco, uma execução remota de código em uma aplicação web pode afetar a integridade de transações e o dinheiro de clientes. Para uma instituição de ensino, o impacto principal recai sobre a reputação e sobre os dados de alunos, que sustentam a confiança das famílias e a captação de novas matrículas. Para um varejista que opera em Magento, o que está em jogo são os dados de pagamento e a continuidade das vendas.
Por isso, a conversa com o conselho precisa partir de quatro respostas objetivas, que são onde a empresa está exposta, qual ativo de negócio está em risco, quanto custa corrigir em comparação com o custo de um incidente e em quanto tempo a correção pode ser concluída. Sem essas respostas, o CISO pede orçamento com base em urgência técnica e o conselho decide sem conseguir avaliar o retorno.
Como manter visibilidade contínua sobre o que foi corrigido?
Foi para responder a essas perguntas que estruturamos o DevSecureHub na Ivy. O serviço combina pentest manual contínuo, com alvos definidos pelo cliente conforme o ambiente muda, e uma plataforma que acompanha cada vulnerabilidade desde a identificação até a correção, com responsáveis, status e histórico visíveis para a equipe técnica e para a liderança.
Os achados passam pela curadoria dos nossos especialistas, que têm certificações como OSCE3, OSWE, OSEP e OSCP, e por isso o time de desenvolvimento recebe uma fila priorizada em vez de uma lista extensa de itens sem contexto. A plataforma traduz cada vulnerabilidade em um problema de negócio, como a possibilidade de multa da LGPD a partir de uma injeção de SQL, e calcula o retorno sobre o investimento em segurança com base nos estudos da IBM sobre custo de vazamentos, ajustados à realidade de cada empresa.
O serviço inclui ainda um Security Champion, que orienta o time de desenvolvimento na correção sem assumir o código, a modelagem de ameaças da arquitetura e trilhas de treinamento geradas a partir das falhas mais recorrentes no próprio ambiente do cliente. Quando uma CVE crítica como a do PHP é publicada, a empresa já sabe quais aplicações são afetadas, quem responde por elas e qual delas deve ser corrigida primeiro, e o CISO chega à reunião com o conselho com números que sustentam a decisão.
Quanto tempo sua empresa levaria para responder à próxima falha crítica?
Falhas como as do PHP vão continuar surgindo, e o uso de IA por atacantes deve reduzir ainda mais o prazo entre a divulgação e a exploração. As organizações que conseguem medir o tempo entre a publicação de uma CVE e a correção em produção, e associar esse tempo ao valor dos ativos protegidos, passam a tratar segurança como um critério de decisão do negócio e conseguem defender cada investimento com dados.
Converse com os especialistas da Ivy e veja como o DevSecureHub pode reduzir esse tempo no seu ambiente.
