PHP2Shell: O que isso significa para seus sites e como a Nexusguard pode ajudar

Você deve ter visto notícias esta semana sobre um par de falhas graves de segurança no PHP, o software que executa uma grande parte dos sites em todo o mundo — incluindo WordPress, lojas virtuais e muitas aplicações empresariais personalizadas.

‍

Em 21 de outubro de 2026, o projeto PHP lançou atualizações de emergência para dois problemas conhecidos coletivamente como PHP2Shell (CVE-2026-109618 e CVE-2026-109619). Ambos são classificados como críticos. Em termos simples: alguém na internet, sem nome de usuário ou senha, pode conseguir executar seu próprio código em um servidor web vulnerável. Isso é tão sério quanto parece. Não significa que todo site PHP já esteja comprometido, e não significa que o WAF de Proteção de Aplicações da Nexusguard esteja em risco.

‍

Aqui está o que é o problema, se você foi afetado, o que estamos fazendo e o que você deve fazer a seguir.

‍

O que é

Pense no PHP como o motor por trás de muitos sites. Quando um visitante carrega uma página, preenche um formulário ou faz o upload de um arquivo, o PHP é frequentemente o software que recebe essa solicitação e a transforma em uma resposta.

‍

O PHP2Shell não é um bug em um plugin ou em uma marca específica de construtor de sites. Ele está no próprio PHP — na forma como o motor lida com solicitações web recebidas, especialmente o tipo de solicitação que os navegadores usam para uploads de arquivos. O problema pode aparecer antes de o código do seu próprio site sequer começar a rodar. Atualizar um tema ou um plugin não é suficiente. O software PHP no servidor precisa ser atualizado.

‍

Existem duas falhas relacionadas:

‍

Quando o PHP fica sem memória. Se o PHP for levado além do seu limite de memória ao processar uma solicitação, ele pode falhar de uma maneira insegura. Em vez de simplesmente parar, ele pode deixar o servidor em um estado que um invasor pode aproveitar. Avisos públicos confirmam que isso pode levar a uma tomada de controle total do servidor web.

‍

Quando dados residuais são reutilizados. Servidores web frequentemente reutilizam o mesmo processo PHP para muitos visitantes, um após o outro. Se uma solicitação deixa esse processo em um estado desorganizado, a próxima solicitação no mesmo processo pode ser mal processada. Pesquisadores mostraram que isso, também, pode levar a uma invasão. Um gatilho confirmado envolve um recurso nativo do PHP que rastreia o progresso do upload de arquivos. Esse recurso está ativado por padrão, mesmo que sua aplicação nunca tenha solicitado.

‍

Relatórios públicos descreveram invasores usando essas falhas antes antes de serem anunciadas. Esse é um motivo para tratar a atualização como urgente. Não é uma prova de que seu site específico foi atingido.

‍

Você foi afetado?

Você pode ser afetado se algum dos seus sites públicos, APIs ou portais de clientes executar PHP e ainda não tiver recebido a atualização de emergência de 21 de outubro.

‍

Você está no caminho certo se:

• seus sites não usam PHP de forma alguma, ou
• seu provedor de hospedagem, equipe de TI ou parceiro de serviços gerenciados já aplicou as versões corrigidas do PHP (8.5.12, 8.4.27, 8.3.36 ou 8.2.35) e reiniciou o PHP, ou aplicou a atualização de segurança do fornecedor do seu sistema operacional.

‍

O PHP 7.4 até 8.1 recebe apenas backports mínimos em nível de código-fonte. O PHP 7.3 e versões anteriores não serão corrigidos. Se você estiver usando uma dessas versões, precisa de um plano para migrar para uma ramificação do PHP com suporte — um pequeno patch não é suficiente.

‍

Se você não tem certeza, isso é comum. Muitas organizações executam o PHP sem pensar nisso — é simplesmente "o site". Pergunte a quem cuida da sua hospedagem, do WordPress ou dos servidores de aplicação.

‍

O Nexusguard foi afetado?

O WAF de Proteção de Aplicações do Nexusguard não foi impactado. Nosso WAF não é PHP. Ele não executa o código PHP do seu site, e essas falhas não são um defeito na plataforma Nexusguard.

‍

Se você executa PHP em seus próprios servidores (ou nos servidores do seu provedor de hospedagem) por trás do Nexusguard, esses servidores ainda podem estar em risco até que o PHP seja atualizado. Esse é um problema de software de origem — o mesmo tipo de questão de "por favor, corrija a aplicação" que vemos com outros softwares web amplamente utilizados. Atualizar o PHP é a ação principal.

‍

Isso também não é um ataque de inundação DDoS. A proteção DDoS do Nexusguard não é o caminho que um invasor usa para o PHP2Shell. O risco é para o tempo de execução da aplicação no servidor web, não para a capacidade da rede.

‍

Como estamos ajudando

Sabemos que corrigir um conjunto de sites leva tempo: você precisa encontrar onde o PHP está sendo executado, planejar uma janela de manutenção e testar. Enquanto você faz isso, não deve ficar desprotegido.

‍

Estamos implementando regras de WAF em toda a plataforma de Proteção de Aplicações do Nexusguard para detectar tentativas de exploração visando o CVE-2026-109618 e o CVE-2026-109619. Essas regras oferecem uma camada extra de visibilidade e proteção enquanto você realiza as correções.

‍

Por favor, trate-as como um cinto de segurança, não como o conserto. Elas não substituem a atualização do PHP. Corrigir seus servidores continua sendo a única solução completa. Alguns dos caminhos do PHP2Shell residem dentro do próprio servidor e não podem ser totalmente fechados por um firewall de aplicação web, não importa o quão bem ajustado ele esteja.

‍

A proteção em nível de rede também só ajuda o tráfego que realmente passa por ela. Se seus servidores de origem ainda aceitam tráfego web diretamente da internet, um invasor pode contornar o Nexusguard. Certifique-se de que esses servidores aceitem tráfego web apenas do seu serviço de proteção.

‍

Se você tiver dúvidas sobre sua exposição ou precisar de ajuda para analisar tráfego suspeito, entre em contato com nossa equipe de suporte. Estamos aqui para acompanhar você nisso — você não precisa ser um engenheiro de segurança para perguntar.

‍

O que você deve fazer

Mesmo que você não seja a pessoa que acessa o servidor, entregue esta lista à sua equipe de TI, provedor de hospedagem ou parceiro de site. Inclua WordPress, Magento e quaisquer aplicativos web personalizados que estejam acessíveis pela internet.

‍

1. Atualize o PHP imediatamente. As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Se você utiliza os pacotes PHP do fornecedor do seu sistema operacional, aplique a atualização de segurança desse fornecedor. Não espere por uma semana mais tranquila se os sites forem públicos.

2. Reinicie todos os processos PHP (workers) após a atualização. Isso significa pools do PHP-FPM, Apache e quaisquer processos PHP de longa duração. Instalar o pacote não é suficiente. A correção não entra em vigor até que os processos antigos sejam encerrados.

3. Planeje uma atualização se você utiliza uma versão do PHP que já atingiu o fim da vida útil (EOL). O PHP 7.4 até 8.1 recebem apenas backports mínimos em nível de código-fonte, e o PHP 7.3 e versões anteriores não serão corrigidos. Se você estiver em uma dessas versões, migre para uma ramificação com suporte o mais rápido possível.

4. Aplique medidas de mitigação provisórias se não puder aplicar o patch imediatamente. Elas reduzem o risco, mas não substituem a aplicação do patch. Peça ao seu administrador para realizar as alterações na configuração do servidor principal ou do pool do PHP-FPM e, em seguida, reinicie o PHP. Configurações feitas via ini_set() ou .user.ini não protegem contra essas falhas.

• Defina session.upload_progress.enabled = 0.
• Reduza o post_max_size para o menor valor com o qual sua aplicação consiga operar.
• Bloqueie o limite de memória para que as aplicações não possam substituí-lo — por exemplo,
  ‍php_admin_value[memory_limit] na configuração do pool do PHP-FPM, ou
  ‍php_admin_value memory_limit no Apache.
• No PHP 8.5, defina fatal_error_backtraces = 0.

5. Revise seus logs. Procure por requisições POST incomuns com multipart/form-data corpos, especialmente aqueles que contenham um campo PHP_SESSION_UPLOAD_PROGRESS junto com um cookie de sessão PHPSESSID . Procure também por travamentos ou reinicializações inesperadas de workers PHP. Recomendamos revisar a atividade a partir de 17 de outubro de 2026 em diante.

6. Não deixe seus servidores de origem diretamente expostos. A proteção em nível de rede só ajuda o tráfego que passa por ela. Certifique-se de que seus servidores de origem aceitem tráfego web apenas do seu serviço de proteção, e não diretamente da internet.

7. Entre em contato conosco se precisar de ajuda. Fale com nossa equipe de suporte caso tenha dúvidas sobre exposição ou para analisar tráfego incomum. Você não precisa diagnosticar isso sozinho.
   ‍

Conclusão

O PHP2Shell é uma ameaça urgente para sites que ainda executam versões do PHP sem correção. Este não é um problema do motor WAF da Nexusguard, e estamos adicionando detecção extra enquanto os clientes realizam as atualizações. A solução definitiva continua sendo a atualização do PHP.

‍

Estamos monitorando a situação e revisaremos esta orientação caso os fatos mudem.
‍

Fontes

• Comunicado do projeto PHP sobre o CVE-2026-109618
• Comunicado do projeto PHP sobre o CVE-2026-109619
• Blog de Segurança da AWS sobre mitigações do PHP2Shell (21 de outubro de 2026)
• Boletim de Segurança da AWS 2026-143-AWS
  ‍

Lista de verificação de publicação

• Informa, educa, declara o impacto e indica o que deve ser feito
• Lista de verificação do comunicado concluída e consistente com este rascunho
• Sem receitas de exploração ou payloads além do que já é público
• Sem nomes de clientes, topologia não publicada, limites de responsabilidade ou tabelas de crédito de SLA
• Isenção de responsabilidade da plataforma mais recente incluída
• Escrito para um público geral de clientes, não apenas para leitores técnicos
• Pesquisa de Segurança/Ameaças: pendente
• Produto / Jurídico / classificação / Comunicações (Donny para esta fase de documentação): pendente