Servidores web que utilizam PHP estão no centro de alertas sobre tentativas de exploração das vulnerabilidades CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell. A campanha relatada envolve variantes da botnet Mirai, incluindo a Potassium, e levanta preocupações sobre a possibilidade de invasores executarem códigos maliciosos em sistemas Linux expostos à internet.
A ameaça ganha relevância pelo alcance do PHP, linguagem amplamente utilizada em aplicações corporativas, plataformas de comércio eletrônico e sistemas de gerenciamento de conteúdo. Uma falha que permita execução remota de código (RCE) pode abrir caminho para o comprometimento de servidores, instalação de malware e utilização indevida de recursos computacionais.
Um dos aspectos mais importantes desse cenário envolve o ASLR (Address Space Layout Randomization), mecanismo de proteção de memória que dificulta determinadas técnicas de exploração. Embora essa barreira possa reduzir a confiabilidade dos ataques, ela não elimina a necessidade de correção. Para administradores de sistemas, a prioridade é identificar instalações potencialmente afetadas, verificar as atualizações disponíveis e monitorar atividades suspeitas.
Botnet Mirai amplia o interesse por falhas em servidores PHP
A Mirai é uma das famílias de malware mais conhecidas no universo das botnets. Sua atuação ganhou notoriedade pelo comprometimento de dispositivos conectados à internet, especialmente roteadores, câmeras IP e equipamentos com configurações inseguras.
Com o passar dos anos, diferentes operadores passaram a adaptar seu código e incorporar novos mecanismos de propagação. Essas variantes podem explorar vulnerabilidades em serviços expostos, além de aproveitar credenciais fracas e configurações inadequadas.
A Potassium, associada aos relatos de ataques contra o PHP2Shell, representa essa estratégia de expansão. O objetivo de campanhas automatizadas desse tipo é identificar sistemas vulneráveis e tentar incorporá-los a uma infraestrutura controlada por criminosos.
Em vez de depender exclusivamente de ataques direcionados, os operadores utilizam ferramentas capazes de testar grandes quantidades de endereços IP. Quando encontram um serviço aparentemente vulnerável, enviam requisições preparadas para tentar acionar a falha.
Se a exploração funcionar, o invasor poderá tentar executar comandos no contexto do processo comprometido. As consequências dependerão das permissões disponíveis, da configuração do servidor e das demais proteções implementadas.
Entre os riscos estão a instalação de programas maliciosos, a execução de processos não autorizados e o uso da máquina em ataques distribuídos de negação de serviço (DDoS).
Entretanto, uma tentativa de exploração não comprova que o servidor tenha sido invadido. A confirmação exige evidências adicionais, como execução de comandos, alterações em arquivos ou comunicações maliciosas identificadas nos registros do sistema.
Como funciona a infraestrutura de comando e controle
Botnets normalmente dependem de uma estrutura de comando e controle (C2) para coordenar dispositivos comprometidos.
Depois de infectada, uma máquina pode estabelecer comunicação com servidores administrados pelos operadores da campanha. Essa comunicação permite receber instruções, executar tarefas e participar de operações coordenadas.
Variantes derivadas da Mirai também podem empregar mecanismos de distribuição de executáveis preparados para diferentes arquiteturas de processadores.
Essa característica facilita a reutilização de componentes maliciosos em ambientes heterogêneos, embora a compatibilidade de cada variante dependa do sistema operacional e das condições encontradas.
Em um servidor Linux, a instalação de malware pode resultar em consumo excessivo de CPU, conexões inesperadas com endereços externos e execução de processos desconhecidos.
Esses sinais merecem investigação, principalmente quando surgem após requisições HTTP suspeitas.
PHP2Shell enfrenta barreiras técnicas impostas pelo ASLR
Um dos pontos centrais da discussão sobre as falhas PHP2Shell envolve a dificuldade de transformar uma vulnerabilidade de memória em um ataque confiável.
O ASLR é uma proteção utilizada por sistemas operacionais modernos para tornar menos previsíveis os endereços de memória de processos e bibliotecas.
Sem esse mecanismo, determinadas técnicas de exploração poderiam utilizar posições conhecidas para desviar o fluxo de execução de um programa.
Com a randomização habilitada, os endereços podem mudar entre execuções, dificultando o funcionamento de exploits que dependem dessas informações.
Isso representa um obstáculo importante para invasores que tentam explorar falhas de corrupção de memória.
Um ataque construído para determinada configuração pode falhar em outro ambiente, mesmo quando ambos executam versões vulneráveis do software.
Além disso, uma tentativa malsucedida pode provocar o encerramento inesperado de processos, erros na aplicação ou comportamentos inconsistentes.
Por que contornar o ASLR é importante para os invasores
Para superar essa proteção, determinadas técnicas de exploração procuram descobrir informações sobre a organização da memória do processo.
Uma vulnerabilidade de divulgação de informações, por exemplo, pode permitir que um invasor obtenha endereços necessários para tornar outra falha explorável.
Em outros cenários, o ataque pode depender de condições específicas de execução ou da combinação de diferentes problemas de segurança.
A eficácia dessas abordagens varia conforme a arquitetura do sistema, a compilação do software e as proteções adicionais presentes no ambiente.
Por isso, superar o ASLR não significa necessariamente obter acesso administrativo ao servidor.
Mesmo quando um invasor consegue executar código, mecanismos como SELinux, AppArmor, isolamento de processos e restrições de privilégios podem limitar suas ações.
No contexto das pesquisas relacionadas ao PHP2Shell, é fundamental diferenciar demonstrações experimentais de técnicas comprovadamente utilizadas em ataques reais.
Essa distinção permite avaliar melhor a gravidade operacional da ameaça e evita interpretar qualquer tentativa automatizada como uma invasão bem-sucedida.
Pesquisas da VulnCheck revelam limitações nos ataques ao PHP
A VulnCheck conseguiu reproduzir as falhas em sistemas ARM64 e em ambientes x86 sem ASLR, confirmando a viabilidade técnica de execução remota de código nessas condições.
Entretanto, a análise inicial mostrou uma limitação importante: os códigos públicos examinados ainda não apresentavam um método independente e confiável para contornar o ASLR em sistemas x86-64.
A situação é diferente na arquitetura ARM64, na qual determinadas configurações permitem ataques por força bruta contra a randomização de endereços com maior facilidade.
Essa diferença ajuda a explicar por que uma vulnerabilidade crítica nem sempre apresenta a mesma facilidade de exploração em todos os servidores.
Também demonstra que a simples publicação de códigos de prova de conceito, conhecidos como PoC, não significa que todas as barreiras técnicas tenham sido superadas.
Apesar dessas limitações, a possibilidade de execução remota de código em ambientes vulneráveis exige atenção imediata, principalmente porque novas técnicas podem surgir conforme os pesquisadores e invasores aprofundam suas análises.
Tentativas de exploração do PHP2Shell já aparecem em redes de monitoramento
A divulgação das falhas foi acompanhada por atividades de reconhecimento e tentativas de exploração observadas em sistemas de monitoramento.
Em 21 de outubro de 2026, a VulnCheck registrou requisições direcionadas a servidores PHP, incluindo sondagens que utilizavam identificadores associados ao PHP2Shell.
Entre os comportamentos identificados estavam consultas a páginas comuns, tentativas de localizar arquivos de diagnóstico e requisições POST construídas para testar possíveis caminhos de exploração.
Uma das atividades observadas tentou utilizar o mecanismo PHP_SESSION_UPLOAD_PROGRESS, relacionado ao acompanhamento do progresso de uploads em sessões PHP.
Nesse episódio, o invasor tentou preparar uma condição que permitiria instalar uma web shell, ferramenta maliciosa que pode oferecer acesso remoto ao servidor comprometido.
As tentativas subsequentes de leitura do arquivo, entretanto, retornaram erros HTTP 404. Isso significa que os registros apresentados não demonstraram sucesso nessa operação.
Os dados reforçam que os atacantes começaram a investigar rapidamente as falhas, mas também mostram a importância de separar reconhecimento, tentativa de exploração e comprometimento confirmado.
O que os registros de ataques revelam
O monitoramento de requisições suspeitas pode ajudar equipes de segurança a identificar campanhas automatizadas antes que elas produzam consequências mais graves.
Entre os indicadores que merecem investigação estão requisições incomuns a arquivos PHP, tentativas inesperadas de upload e sequências de erros que coincidam com comportamentos anormais dos processos.
Também é importante observar reinicializações frequentes de trabalhadores PHP, falhas de memória e conexões de saída não reconhecidas.
Entretanto, nenhum desses eventos isoladamente comprova uma exploração do PHP2Shell.
Um processo encerrado inesperadamente pode ter causas legítimas, assim como uma requisição a uma página de diagnóstico pode partir de uma ferramenta autorizada.
A análise precisa considerar o contexto, a origem das conexões e a correlação entre diferentes registros.
Para ambientes de grande porte, ferramentas de SIEM, EDR e monitoramento de aplicações podem facilitar essa investigação, reunindo eventos de servidores web, sistemas operacionais e dispositivos de proteção.
Quais versões do PHP estão vulneráveis e precisam de atualização
As duas vulnerabilidades receberam pontuação 9,2 no CVSS 4.0, classificação considerada crítica.
A CVE-2026-109618 envolve corrupção de memória durante o tratamento de situações em que o PHP fica sem memória disponível. Nessa condição, determinadas estruturas internas podem permanecer parcialmente inicializadas e ser utilizadas incorretamente durante a limpeza da requisição.
Já a CVE-2026-109619 está relacionada à manutenção de referências internas para regiões de memória que já foram liberadas. Uma requisição posterior pode utilizar esse estado inconsistente antes que a inicialização seja concluída.
Ambas podem permitir execução remota de código sem autenticação em condições vulneráveis.
O projeto PHP disponibilizou correções em 21 de outubro de 2026, contemplando as seguintes versões:
Instalações que utilizam versões anteriores dessas ramificações devem ser atualizadas.
As versões PHP 8.1 e anteriores não recebem mais atualizações regulares do projeto. Organizações que ainda dependem dessas edições devem migrar para versões suportadas ou verificar a disponibilidade de correções específicas fornecidas por distribuições Linux e fornecedores de suporte estendido.
O risco não está restrito a uma aplicação ou plataforma de hospedagem.
Ambientes que utilizam Apache com mod_php, PHP-FPM, php-cgi, LiteSpeed e FrankenPHP também precisam ser avaliados.
A atenção deve ser especialmente elevada em servidores com mod_php, configuração para a qual foi demonstrada exploração sem autenticação antes mesmo da execução do código da aplicação.
Como proteger servidores Linux contra os ataques
A principal recomendação é aplicar imediatamente as atualizações de segurança do PHP.
Administradores devem identificar todas as instalações existentes, incluindo versões executadas por servidores web, processos PHP-FPM, contêineres Docker e aplicações mantidas em ambientes separados.
O comando php -v permite verificar a versão utilizada no terminal, mas não garante que o servidor web esteja executando a mesma instalação.
Por isso, também é necessário examinar a configuração dos serviços e os pacotes instalados pelo gerenciador da distribuição.
Em sistemas como Ubuntu, Debian, Red Hat Enterprise Linux e derivados, as correções podem ser distribuídas por meio dos repositórios oficiais, inclusive utilizando backports.
A presença de uma versão numericamente anterior à versão corrigida do projeto PHP não significa necessariamente que o pacote permaneça vulnerável, desde que o fornecedor tenha incorporado a correção.
Medidas temporárias para reduzir a exposição
Quando a atualização imediata não for possível, algumas configurações podem reduzir caminhos conhecidos de exploração.
Para a CVE-2026-109618, as recomendações incluem revisar o limite de memória do PHP e restringir o tamanho e a complexidade das requisições recebidas.
A configuração memory_limit=-1, aplicada de forma que a aplicação não possa sobrescrevê-la, pode eliminar uma condição específica de falha por limite de memória do PHP. Entretanto, não impede todas as situações de esgotamento de memória e exige avaliação cuidadosa da capacidade do servidor.
Para a CVE-2026-109619, a desativação de session.upload_progress.enabled pode bloquear caminhos de exploração identificados. A alteração precisa ser aplicada na configuração efetiva do PHP e acompanhada da reinicialização dos processos envolvidos.
No PHP 8.5, desativar fatal_error_backtraces também pode reduzir a exposição a um caminho conhecido.
Essas medidas são mitigações parciais, não substitutos para a atualização.
Outras ações importantes incluem restringir privilégios dos processos, monitorar conexões externas, limitar serviços desnecessários e revisar os registros de segurança.
Servidores que apresentem sinais de comprometimento devem passar por investigação antes de retornar à operação normal.
Falhas no PHP reforçam alerta sobre ataques automatizados
As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 demonstram como problemas no gerenciamento interno de memória podem comprometer aplicações que dependem de tecnologias amplamente utilizadas.
O caso também lembra o impacto provocado pelo Log4Shell, especialmente pela necessidade de localizar rapidamente componentes vulneráveis distribuídos por diferentes ambientes.
Embora as características técnicas sejam distintas, ambos os episódios evidenciam a importância de manter inventários atualizados, acompanhar boletins de segurança e reduzir o intervalo entre a publicação de uma correção e sua instalação.
A possível utilização das falhas por variantes da Mirai amplia a preocupação com campanhas automatizadas, mas a atribuição de ataques específicos à Potassium exige evidências próprias, além da simples observação de requisições suspeitas.
Para administradores Linux, desenvolvedores e gestores de TI, a prioridade permanece clara: atualizar o PHP, verificar os serviços expostos e investigar qualquer atividade anormal nos servidores.
A aplicação rápida das correções é a medida mais eficaz para impedir que essas vulnerabilidades sejam utilizadas como porta de entrada para ataques contra a infraestrutura web.