PHP2Shell: Cloudflare registra milhões de tentativas de exploração após divulgação das falhas
A divulgação das vulnerabilidades conhecidas como PHP2Shell foi seguida por uma onda de atividade maliciosa. A Cloudflare afirma ter identificado milhões de tentativas de exploração em sua rede, indicando que sistemas expostos passaram a ser procurados de forma automatizada. Para as organizações, o alerta não se limita à gravidade técnica das falhas: é necessário descobrir quais serviços podem estar vulneráveis, confirmar se as correções foram aplicadas e investigar sinais de acesso indevido.
O aumento das tentativas ocorreu após a publicação de informações técnicas sobre as falhas. Esse intervalo entre a divulgação e a exploração em larga escala pode ser curto, pois ferramentas automatizadas permitem que operadores examinem muitos endereços e enviem requisições sem selecionar manualmente cada alvo.
A Cloudflare relata que o tráfego associado às tentativas cresceu rapidamente e que mecanismos de proteção, incluindo regras em sua camada de firewall de aplicações web, foram acionados. O número divulgado, porém, não significa que milhões de servidores foram invadidos. Ele representa tentativas observadas na infraestrutura da empresa. Uma sondagem, uma requisição bloqueada e uma exploração bem-sucedida são situações diferentes e precisam ser avaliadas separadamente.
As falhas relacionadas ao episódio são identificadas pelos códigos CVE-2026-109618 e CVE-2026-109619. A exposição depende de fatores como a versão do PHP, a configuração do ambiente e as condições necessárias para que o caminho de exploração esteja acessível. Assim, o fato de um site usar WordPress, por exemplo, não basta para concluir que ele está vulnerável: é preciso examinar a versão do PHP e os componentes que executam a aplicação.
A escala das tentativas reforça a importância de conhecer todos os ativos conectados à Internet. Além dos servidores principais, a verificação deve incluir ambientes de teste e homologação, contêineres, sistemas antigos, APIs e serviços administrados por fornecedores. Instâncias esquecidas ou fora do processo regular de manutenção podem permanecer expostas mesmo depois que a equipe acredita ter concluído a atualização.
Atualização e proteção em camadas
A primeira medida é levantar as versões de PHP em uso e compará-las com os avisos de segurança correspondentes. Em seguida, as equipes devem instalar as versões corrigidas recomendadas para cada ramo suportado. Não basta atualizar uma máquina central: é necessário confirmar, por meio de inventário ou ferramentas de gestão, que a correção chegou a todos os ambientes relevantes.
Também é importante verificar qual versão está realmente em execução. Um servidor pode ter recebido um pacote atualizado sem que o processo responsável pela aplicação tenha sido reiniciado; em outros casos, diferentes contêineres ou nós de um serviço podem continuar usando versões antigas. A validação posterior deve considerar a configuração ativa, e não apenas o registro da instalação.
Regras de firewall de aplicações web podem ajudar a bloquear padrões de ataque conhecidos e reduzir a exposição enquanto a correção é preparada. Ainda assim, essa proteção não substitui a atualização do PHP. As requisições podem ser alteradas, codificadas de outra forma ou adaptadas para contornar regras específicas. Por isso, controles de borda devem fazer parte de uma estratégia mais ampla, que inclua correções, monitoramento e restrição de acessos desnecessários.
Se houver suspeita de comprometimento, a análise deve reunir diferentes fontes de informação. Logs do proxy e do servidor web podem ser correlacionados com a atividade dos processos do PHP, alterações incomuns em arquivos, conexões de saída e criação de contas ou tarefas não autorizadas. Um sinal isolado não comprova que houve exploração do PHP2Shell, mas a combinação de eventos, horários e contexto pode indicar a necessidade de uma investigação mais aprofundada.
Como organizar a resposta
Um procedimento prático começa pela identificação dos ativos e pela definição de responsáveis por cada sistema. Para cada servidor, convém registrar a versão do PHP, sua função, o nível de exposição à Internet e a situação da atualização. Essa organização ajuda a priorizar os serviços mais críticos, como portais de atendimento, lojas virtuais e APIs que processam dados ou transações.
Durante a correção, equipes podem reduzir temporariamente a superfície de ataque desativando componentes desnecessários, limitando acessos administrativos e restringindo serviços que não precisam ficar disponíveis publicamente. Essas medidas não eliminam a vulnerabilidade, mas podem diminuir as oportunidades de exploração enquanto a atualização é aplicada e validada.
A análise dos registros também deve distinguir tráfego bloqueado de tráfego que alcançou a aplicação. Uma grande quantidade de requisições suspeitas não confirma, por si só, que houve execução de código ou acesso a dados. Por outro lado, a ausência de alertas não garante que um sistema esteja seguro, especialmente quando a coleta de logs é incompleta ou não cobre todos os componentes.
Depois da correção, vale revisar contas privilegiadas, chaves de acesso, tarefas agendadas e arquivos modificados recentemente. Se a investigação encontrar indícios consistentes de invasão, a organização deve tratar o evento como um possível comprometimento: preservar evidências, limitar a atividade suspeita e avaliar a necessidade de trocar credenciais. Quando houver evidência de acesso não autorizado, apenas atualizar o PHP pode não ser suficiente para remover persistência deixada no ambiente.
A resposta também precisa abranger ambientes administrados por terceiros. Contratos e procedimentos operacionais devem esclarecer quem atualiza o runtime, como a correção é confirmada e de que forma incidentes são comunicados. Sem essa confirmação, uma empresa pode acreditar que seus serviços estão protegidos enquanto uma instância terceirizada continua desatualizada.
O episódio evidencia como a publicação de detalhes técnicos pode acelerar a busca por sistemas vulneráveis. Para reduzir o risco, as organizações precisam combinar inventário atualizado, aplicação rápida de correções, controles de borda e análise contínua de sinais suspeitos. Milhões de tentativas detectadas não equivalem a milhões de invasões, mas mostram que a janela para corrigir serviços expostos pode ser estreita.