PHP2Shell: falhas críticas no PHP e como atualizar

O PHP recebeu em 21 de outubro de 2026 uma atualização emergencial para corrigir duas vulnerabilidades críticas: CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell. Elas podem permitir que um atacante execute código no servidor sem autenticação, dependendo do ambiente e das condições de exploração. Quem mantém um site, loja virtual, sistema ou aplicação PHP precisa confirmar a instalação das correções com o responsável pela hospedagem.

A ação imediata é corrigir o PHP em execução. Para quem usa uma versão fora de suporte, também é necessário atualizar a aplicação e planejar a migração. Adiar indefinidamente essa manutenção porque “o site ainda funciona” mantém o negócio dependente de um ambiente cujo ciclo oficial já terminou.

Informações verificadas em 22/10/2026. Este artigo orienta clientes e desenvolvedores; ele não confirma a situação de um servidor específico. Consulte os boletins vinculados para acompanhar novas revisões dos fornecedores.

O que fazer agora: roteiro para o cliente

1. Identifique o PHP do seu domínio. No WordPress, consulte Ferramentas > Saúde do site > Informações > Servidor.
2. Peça a confirmação das duas correções. Informe ao suporte os códigos CVE-2026-109618 e CVE-2026-109619.
3. Confirme o pacote instalado e os processos ativos. Disponibilidade de uma atualização no repositório não significa que ela já foi aplicada.
4. Acione quem mantém o site. Plugins, temas, bibliotecas e código próprio precisam acompanhar uma versão suportada do PHP.
5. Se não houver correção aplicável, trate a exposição como urgente. Combine com o administrador uma medida de isolamento até que exista uma solução validada.

Para abrir o chamado, você pode usar esta mensagem:

Meu domínio exemplo.com.br utiliza PHP. Podem confirmar se o ambiente recebeu as correções para CVE-2026-109618 e CVE-2026-109619? Preciso saber a versão e a revisão do pacote, o handler utilizado e se os processos já foram reiniciados ou substituídos para carregar a correção. Se meu PHP estiver fora do suporte oficial, quais são as opções de atualização?

O que é PHP e por que essa falha afeta um site

PHP é o programa que executa o código de muitas aplicações no servidor. Quando alguém abre uma página do WordPress, por exemplo, esse interpretador processa instruções, consulta o banco e ajuda a montar a resposta que o navegador receberá.

Imagine um restaurante: o site é o cardápio e as receitas; o PHP é parte do equipamento da cozinha que prepara os pedidos. Atualizar o cardápio não conserta um equipamento defeituoso. Da mesma forma, corrigir o PHP não atualiza automaticamente os ingredientes e as receitas da aplicação.

Essa comparação explica por que existem duas responsabilidades: manter o ambiente de execução corrigido e manter o software do site compatível e atualizado. As duas tarefas se complementam.

O que aconteceu nas vulnerabilidades PHP2Shell

Os dois identificadores CVE descrevem problemas diferentes na forma como o PHP administra memória e informações internas das requisições. Ambos receberam classificação crítica, com nota 9,2 na escala CVSS v4.0, conforme o comunicado oficial do projeto PHP.

CVE-2026-109618: falha durante o tratamento de falta de memória

Em determinadas situações, uma interrupção por falta de memória podia deixar estruturas internas parcialmente preparadas. Ao encerrar a requisição, o PHP podia tratar esses dados incompletos como válidos. Esse comportamento abre caminho para corrupção de memória e execução de código. A explicação técnica está no aviso oficial GHSA-w8hw-w9fx-j79w.

CVE-2026-109619: uso de informações de uma requisição anterior

Um processo que atende várias requisições podia conservar referências a uma região de memória já liberada. Uma requisição posterior podia acessar esse estado antigo antes de ele ser reinicializado. A falha pertence à classe use-after-free, que significa usar memória depois de sua liberação. Veja o aviso oficial GHSA-6wmf-4rv5-p3rp.

Esses problemas estão abaixo da lógica normal do site. A PHP Foundation descreve a gravidade e a investigação das falhas, incluindo demonstrações em ambientes reais. Isso justifica a prioridade da atualização, sem concluir que todo servidor vulnerável tenha sido invadido.

Quem precisa verificar o ambiente

O alerta abrange instalações PHP que atendem requisições web, incluindo PHP-FPM, Apache com mod_php, CGI, FrankenPHP e LiteSpeed. O comunicado destaca risco maior em mod_php, com demonstração de ataque antes da execução do código da aplicação. Usar outro handler não deve ser interpretado como dispensa da correção.

Faça um inventário que inclua:

• site principal, loja e páginas de campanha;
• subdomínios, instalações de teste e cópias antigas;
• painéis administrativos e sistemas internos acessíveis pela internet;
• APIs, integrações e aplicações instaladas em containers;
• produtos que tragam sua própria cópia do PHP.

Um domínio atualizado não comprova a situação dos demais. Em uma mesma conta de hospedagem, diferentes sites podem usar versões diferentes. Um ambiente de testes esquecido também merece atenção.

Quais versões do PHP corrigem essas falhas?

Para as distribuições oficiais do projeto PHP, os primeiros lançamentos corrigidos deste incidente são:

O registro de versões afetadas e corrigidas deve ser consultado junto com o fornecedor do pacote. Revisões posteriores podem incorporar essas correções e outras melhorias. Ter apenas “PHP 8” ou “PHP 8.4” selecionado no painel não identifica a revisão instalada.

Por que um pacote corrigido pode mostrar um número menor?

Alguns fornecedores aplicam a correção ao código de uma versão anterior e publicam uma nova revisão do pacote. Esse procedimento se chama backport. O número principal exibido pelo PHP pode continuar igual, enquanto o pacote completo muda.

A página de status oficial do CloudLinux apresenta esse caso: um pacote ea-php84 com base 8.4.26 pode conter o remendo na revisão específica do fornecedor. A avaliação precisa considerar origem, revisão e boletim, e não somente comparar o número mostrado no WordPress.

O que é EOL e quais versões antigas já perderam suporte

EOL significa fim de vida. Depois dessa data, uma linha deixa de receber a manutenção regular de segurança do projeto PHP. O site pode continuar abrindo, mas isso não significa que o interpretador permaneça acompanhado pelos mantenedores.

As datas constam na relação oficial de versões sem suporte. PHP 8.1 perdeu suporte mais recentemente que PHP 5.6 ou 7.4; o problema deve ser explicado com datas, sem tratar todas as versões antigas como se tivessem o mesmo histórico.

Para este incidente, o projeto disponibilizou excepcionalmente correções mínimas em código-fonte para 7.4, 8.0 e 8.1. Isso não reabre o ciclo de manutenção dessas linhas nem garante um pacote pronto para sua hospedagem. Fornecedores de suporte estendido podem entregar seus próprios remendos; a cobertura deve ser confirmada.

PHP 8.2 ainda tem suporte? Qual versão escolher?

Em 22/10/2026, PHP 8.2 ainda recebe correções de segurança, mas está perto do encerramento. As linhas suportadas têm os seguintes prazos:

Fonte: calendário de suporte do PHP. Para escolher o destino, verifique também compatibilidade do CMS, tema, extensões e integrações. Uma linha suportada precisa estar com suas revisões de segurança instaladas.

Como orientação de planejamento, um projeto que será modernizado agora deve avaliar 8.4 ou 8.5, desde que seus componentes estejam homologados. Adotar 8.2 apenas para sair de PHP 7 pode criar outra migração em poucas semanas. Corrija a instalação atual imediatamente e escolha o destino definitivo com testes.

Atualizar WordPress e plugins resolve a falha do PHP?

A correção dessas duas CVEs está no PHP. O alerta oficial do WordPress esclarece que o problema não é exclusivo do CMS e que uma atualização do WordPress não é a correção deste incidente.

Isso não diminui a importância de manter o site atualizado. Um tema abandonado pode impedir a migração do interpretador. Um plugin com uma falha própria continua vulnerável mesmo depois que o PHP é corrigido. Veja como as camadas se relacionam:

Exemplo: WordPress atualizado, PHP antigo

Uma empresa atualizou todos os plugins, mas mantém PHP 7.4 porque um trecho personalizado apresenta erro na migração. O painel do CMS pode parecer em dia, enquanto a aplicação continua dependente de uma linha em EOL. A tarefa é corrigir esse trecho, confirmar os remendos emergenciais e concluir a migração.

Exemplo: PHP corrigido, aplicação abandonada

Outra empresa instala o pacote corrigido do PHP, mas continua usando um módulo comercial sem atualizações. O incidente do interpretador pode estar tratado, enquanto o módulo ainda exige avaliação própria. Registre separadamente o que foi corrigido e o que depende do desenvolvedor.

Como descobrir o PHP que o site realmente utiliza

No WordPress

Abra Ferramentas > Saúde do site > Informações > Servidor e registre a versão PHP. Esse caminho também é indicado no alerta oficial do CMS. A versão ajuda no inventário; a confirmação de backport exige informações do administrador.

No cPanel

Consulte a versão vinculada ao domínio no MultiPHP Manager. Se o serviço utiliza PHP Selector do CloudLinux, confirme qual seletor controla aquele site. A documentação do MultiPHP Manager descreve a seleção por domínio e a herança da versão padrão.

Repita a consulta para cada domínio relevante. Antes de mudar a seleção, confirme a revisão corrigida disponível e a compatibilidade do site.

No terminal, para o responsável técnico

php -v
php --ini

Essas consultas mostram o executável usado no terminal e seus arquivos de configuração. Ele pode ser diferente do PHP do site, do cron ou da fila. Uma saída do terminal não deve ser usada sozinha como prova de correção de todos os domínios. Evite deixar uma página pública de phpinfo() para consulta permanente.

O que conferir em VPS com cPanel e CloudLinux

O boletim específico do cPanel distingue correções de EasyApache e do próprio painel. Entre as referências de EasyApache mantidas pelo cPanel estão 7.4.33-19, 8.0.30-12 e 8.1.34-5 para as linhas legadas. Essas revisões não devem ser transferidas automaticamente para pacotes de outro fornecedor.

Para ambientes RPM que usam esses pacotes, o administrador pode consultar, adaptando o nome à versão realmente instalada:

rpm -q ea-php84-php-cli
rpm -q --changelog ea-php84-php-cli

São consultas de inventário. O resultado precisa ser comparado ao boletim e aos demais componentes instalados, como FPM. A ausência de um identificador no histórico, isoladamente, também pode exigir investigação do fornecedor.

O cPanel mantém um PHP interno para interfaces como o webmail. As notas de versão do painel registram uma atualização própria desse componente. Atualizar somente o PHP dos sites pode deixar essa segunda camada pendente.

No CloudLinux, a página de acompanhamento do incidente detalha alt-php, ea-php e PHP nativo. Confirme o repositório utilizado, a revisão instalada e a troca dos processos ativos. Ter a correção disponível não demonstra que ela esteja carregada no servidor.

CloudLinux e suporte estendido permitem manter PHP antigo?

Podem fornecer uma ponte de compatibilidade quando há cobertura contratada e o fornecedor entrega o remendo específico. O comunicado do CloudLinux distingue pacotes corrigidos e proteções temporárias. A presença de CloudLinux, por si só, não comprova que o domínio usa a versão remendada.

Para o planejamento do cliente, registre três decisões: quem confirma os pacotes, quem adapta a aplicação e qual é a data de migração. Um fornecedor de PHP estendido não passa a manter automaticamente o plugin ou o sistema de gestão que depende daquela versão.

Se o sistema é indispensável e a migração exige desenvolvimento, trate o ambiente legado como uma etapa administrada. Se ninguém mantém o código, avalie atualização comercial, substituição ou desativação das funções obsoletas.

WAF, antivírus e página de manutenção são suficientes?

WAF e ferramentas de segurança podem reduzir exposição a padrões conhecidos e ajudar no monitoramento. Elas devem complementar a atualização. O fornecedor do Imunify360 descreve limites das regras temporárias no comunicado de proteção.

Um plugin que mostra “site em manutenção” pode continuar executando PHP para responder às visitas. Portanto, não equivale a retirar o interpretador vulnerável da exposição. Quando necessário, o bloqueio deve ser implementado na camada correta pelo administrador.

O NCSC recomenda ação imediata e considerar a retirada do sistema da internet quando a remediação não for possível a tempo. A decisão deve considerar o serviço e a capacidade de isolamento, sem criar uma falsa garantia com uma simples mensagem na tela.

O boletim PHP também descreve mitigações de configuração com limitações. Algumas afetam controle de memória e tratamento de requisições. Elas precisam de avaliação especializada: não copie ajustes isolados para produção nem os trate como substitutos do pacote corrigido.

Como atualizar uma aplicação PHP sem perder o controle

Trabalhe em duas frentes: correção emergencial do ambiente e compatibilidade da aplicação. O planejamento da migração não deve servir para adiar um remendo disponível para a versão atual.

1. Liste as funções que não podem falhar

Para uma loja, inclua login, carrinho, cálculo de frete, pagamento e confirmação do pedido. Para um site institucional, inclua formulário, envio de e-mail, busca e painel. Acrescente tarefas cron e integrações. Essa lista será o roteiro de homologação.

2. Preserve uma cópia restaurável

Inclua arquivos, banco e configurações necessárias. Guarde a cópia em local restrito e confira a restauração em ambiente separado. Um backup permite recuperar dados, mas não corrige uma versão vulnerável. Para dimensionar o armazenamento, consulte quanto espaço reservar para backups em VPS cPanel.

3. Teste a compatibilidade fora da produção

Use uma cópia protegida, sem envios reais de pagamento ou notificações. Registre a versão do PHP, extensões e componentes. O guia de staging WordPress ajuda a organizar esse ambiente.

4. Atualize componentes e corrija o código incompatível

No WordPress, revise núcleo, plugins, tema pai, tema filho e personalizações. Em aplicações próprias, confira framework, bibliotecas e integrações. O guia do WordPress para atualização de PHP orienta preparar backup e verificar compatibilidade dos componentes.

O fato de uma versão nova do WordPress funcionar com determinado PHP não garante que todo plugin faça o mesmo. Peça ao desenvolvedor um diagnóstico do erro concreto e um prazo para a correção.

5. Revise dependências em projetos com Composer

Na cópia de testes, o responsável técnico pode consultar:

composer audit
composer outdated --direct
composer check-platform-reqs

Segundo a documentação do Composer, esses recursos ajudam a identificar avisos de dependências, versões disponíveis e requisitos da plataforma instalada. Eles não certificam a correção do interpretador nem a segurança de código próprio. Um resultado sem alertas de biblioteca não substitui a conferência das CVEs do PHP.

6. Valide, publique a mudança e acompanhe

Execute o roteiro funcional, leia os logs e compare o resultado com a versão anterior. Na mudança de produção, confirme que o PHP corrigido está ativo para os domínios e para os trabalhos em segundo plano. Acompanhe erros e transações após a alteração.

Se houver incompatibilidade, o plano de reversão precisa prever um ambiente corrigido ou isolamento temporário. Voltar simplesmente a um interpretador vulnerável e encerrar o chamado deixa a causa de segurança aberta.

Como perceber uma possível invasão

Investigue usuários administrativos desconhecidos, arquivos inesperados, redirecionamentos não autorizados, alteração de tarefas agendadas e envio anormal de mensagens. Esses sinais exigem análise; não demonstram, sozinhos, que a causa seja PHP2Shell.

Conforme o guia oficial para sites WordPress comprometidos, documente sintomas e horários, preserve evidências e procure o responsável técnico. A correção do PHP bloqueia os caminhos corrigidos, mas não remove automaticamente arquivos maliciosos já gravados.

Quando houver comprometimento confirmado, combine contenção, limpeza ou reconstrução confiável, revisão de acessos e troca de credenciais a partir de um ambiente seguro. Recuperar uma cópia antiga sem corrigir a porta de entrada permite uma nova ocorrência.

Como essa manutenção se relaciona com SEO

Manter PHP atualizado não oferece uma posição garantida no Google. A relação prática passa pela continuidade do site: páginas indisponíveis, conteúdo alterado por invasores, redirecionamentos abusivos e falhas no checkout prejudicam visitantes e a confiança no serviço.

Para quem investe em conteúdo e aquisição de clientes, acompanhar o ciclo de suporte deve fazer parte do calendário operacional. Registre a versão por domínio, o responsável pela aplicação e a próxima data de revisão. Assim, uma emergência deixa de encontrar um site cujo único plano é continuar no mesmo PHP indefinidamente.

Perguntas frequentes

Meu site está abrindo normalmente. Preciso agir?

Sim. Funcionamento normal não prova que o PHP recebeu o remendo. Confirme o estado do pacote e dos processos com o suporte.

A falha é exclusiva do WordPress?

Não. Ela está no PHP e pode afetar outras aplicações. Atualizações do CMS continuam importantes, mas não instalam, por si só, a correção do interpretador.

PHP 8.4 ou 8.5 já são seguros por serem recentes?

A linha precisa da revisão corrigida ou de um backport comprovado. Confira a tabela deste artigo e o boletim correspondente ao pacote utilizado.

PHP 7.4 com remendo voltou a ter suporte oficial?

Não. A correção de um incidente específico não reinicia o ciclo da linha. Mantenha um plano para atualizar o código e migrar.

Preciso reinstalar meu site só porque ele usa PHP?

O alerta, sozinho, não comprova invasão. A prioridade é corrigir o ambiente e avaliar evidências. Uma reconstrução deve decorrer de diagnóstico, não apenas do anúncio da vulnerabilidade.

Quem deve atualizar: cliente ou hospedagem?

Depende do serviço contratado. O administrador trata os pacotes e serviços do servidor; o desenvolvedor trata compatibilidade e código. O cliente precisa coordenar e obter confirmação das duas frentes.

Posso manter uma aplicação incompatível enquanto ela é adaptada?

Somente após avaliar correção disponível, exposição e cobertura do fornecedor. Combine uma solução temporária validada e um prazo de migração, com isolamento quando necessário.

Checklist para encerrar a atualização

• Domínios e instalações PHP foram inventariados.
• As duas CVEs foram conferidas no boletim do fornecedor.
• Pacotes corrigidos estão instalados e os processos carregam a correção.
• WordPress, plugins, temas ou dependências foram revisados.
• Login, formulários, pagamentos e tarefas agendadas foram testados.
• Backups e recuperação foram verificados.
• Ambientes em EOL têm responsável e prazo de migração.

Clientes WebinHost: ao abrir um chamado sobre este incidente, informe domínio, serviço e versão identificada. Solicite a confirmação das correções e envolva o desenvolvedor quando houver incompatibilidade. Essa orientação não representa uma declaração de que todos os servidores ou aplicações de clientes já foram atualizados.

A manutenção termina quando o ambiente corrigido está em uso e a aplicação foi validada. Para sistemas antigos, o próximo compromisso é concreto: remover a dependência de versões sem suporte antes que outra emergência determine o prazo.