Neste artigo
- Direto ao ponto
- Como a falha do PHP pode alcançar seu WordPress
- LiteSpeed, Apache e Nginx executam o PHP de formas diferentes
- A versão do PHP precisa ser a utilizada pelo domínio
- Desativar o progresso de upload é uma medida parcial
- O que solicitar ao suporte da hospedagem
- Como conferir o WordPress depois da atualização
Você pode manter o WordPress atualizado, conferir os plugins e ainda precisar de uma correção no PHP da hospedagem. O PHP é o programa que executa o código do seu site no servidor. Ele tem versão própria e recebe atualizações separadas das que você aplica pelo painel do WordPress. Por isso, uma manutenção concluída no painel pode deixar essa parte do servidor sem a correção.
As duas vulnerabilidades divulgadas pelo projeto PHP em outubro de 2026 exigem essa conferência. Elas permitem execução remota de código sem autenticação nas condições descritas pelos avisos técnicos. Para o seu WordPress, a investigação começa pelo PHP utilizado pelo domínio e pela forma como a hospedagem executa esse programa. Saber que o site usa LiteSpeed, Apache ou Nginx ainda deixa parte dessa informação por conferir. Comunicado oficial do PHP.
Direto ao ponto
As correções foram publicadas nas versões PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Você precisa confirmar que o PHP do seu domínio recebeu a correção, inclusive quando o provedor a distribui dentro de um pacote próprio. O comunicado inclui LiteSpeed, Apache com mod_php e PHP-FPM entre os ambientes expostos. A atualização do WordPress ou de um plugin, isoladamente, não substitui a atualização desse PHP. Versões e orientação de atualização.
Como a falha do PHP pode alcançar seu WordPress
O servidor precisa preparar uma requisição para que o WordPress consiga trabalhar com ela. Parte desse processamento acontece dentro do PHP, antes de o código do site começar a executar. Um arquivo enviado, por exemplo, exige que o PHP interprete o corpo da requisição. Essa preparação também pode consumir memória e acionar recursos configurados na hospedagem.
Na CVE-2026-109618, uma interrupção por falta de memória pode deixar estruturas internas incompletas. O PHP tenta utilizá-las durante o encerramento da requisição e pode executar código controlado pelo atacante. O aviso documenta esse caminho no Apache com mod_php quando o código da aplicação ainda não começou a executar. Nessa situação, a conferência de login feita pelo WordPress chega depois do processamento vulnerável. Descrição técnica da CVE-2026-109618.
A CVE-2026-109619 envolve referências à memória que permanecem num processo PHP depois de uma requisição terminar. Quando esse mesmo processo atende outra requisição, pode acessar a memória já liberada. O resultado depende das condições de inicialização e dos recursos envolvidos, por isso o diagnóstico precisa considerar a configuração utilizada pelo seu site. Descrição técnica da CVE-2026-109619.
Um desses recursos acompanha o progresso de uploads e pode trabalhar durante a preparação inicial da requisição, quando os scripts ainda não começaram a executar. Sua ativação depende da configuração do PHP e das características da requisição recebida. A ausência de uma barra de progresso nas páginas do seu WordPress, portanto, não comprova que o recurso esteja desativado na hospedagem. Essa configuração precisa ser conferida no PHP que atende o domínio. Funcionamento do progresso de upload.
LiteSpeed, Apache e Nginx executam o PHP de formas diferentes
O nome do servidor web informa apenas parte do caminho percorrido pela requisição. O Apache pode carregar o PHP como módulo ou encaminhar o processamento para um serviço separado. O Nginx pode encaminhar requisições ao PHP-FPM por FastCGI. Já o LiteSpeed utiliza o LSPHP em configurações com LSAPI, a interface de comunicação com o PHP. Essas diferenças determinam quais processos precisam receber a atualização. Integração FastCGI do Apache, FastCGI no Nginx e LSPHP no LiteSpeed.
Para conversar com o suporte, você pode usar a comparação abaixo. Ela relaciona o ambiente ao componente que precisa ser conferido, sem transformar o nome do servidor numa conclusão sobre o estado do seu site.
| Ambiente do WordPress | Onde o PHP executa | O que confirmar com a hospedagem |
|---|---|---|
| Apache com mod_php | Dentro dos processos do Apache | Atualização do módulo PHP e substituição dos processos que carregavam a versão anterior. |
| Apache com PHP-FPM | Em processos PHP separados do Apache | Pacote corrigido e reinício dos processos do serviço PHP-FPM utilizado pelo domínio. |
| Nginx com PHP-FPM | No PHP-FPM que recebe as requisições encaminhadas pelo Nginx | Versão corrigida no destino FastCGI e substituição de todos os processos antigos. |
| LiteSpeed ou OpenLiteSpeed com LSPHP | Nos processos LSPHP associados ao site | Atualização do LSPHP selecionado para o domínio e reinício dos processos PHP correspondentes. |
Apache com mod_php exige atenção ao módulo carregado
O Apache com mod_php aparece nos avisos oficiais com exploração demonstrada. Nesse modelo, atualizar outro executável PHP instalado no servidor pode deixar intacto o módulo utilizado pelo site. A conferência precisa identificar o pacote do módulo e os processos do Apache que o carregam. O aviso sobre a falha de memória explica por que o encerramento da requisição permite alcançar o estado inválido nesse ambiente.
Uma resposta do suporte dizendo apenas “o Apache está atualizado” deixa pendente a revisão do PHP. Ao abrir o chamado, informe o domínio e solicite a identificação do módulo utilizado por ele. Essa informação permite relacionar a correção ao componente que realmente executa seu WordPress.
Nginx e Apache com PHP-FPM precisam da correção no FPM
O PHP-FPM administra os processos que executam o código PHP recebido do servidor web. O aviso da CVE-2026-109618 descreve uma diferença no tratamento de falhas durante a inicialização, mas também reconhece exposição em outros momentos do processamento. Na CVE-2026-109619, há caminhos condicionais ligados ao estado preservado entre requisições, portanto o uso do PHP-FPM exige a correção correspondente. Aviso sobre memória e aviso sobre estado interno.
No seu domínio, o Nginx pode apontar para um serviço PHP-FPM específico. Outro site hospedado na mesma máquina pode usar uma versão diferente. Reiniciar o Nginx não substitui esses processos PHP separados, assim como atualizar o PHP de outro domínio não confirma a correção do seu. Eu começaria essa conferência pelo serviço associado ao site, para relacionar a resposta da hospedagem à instalação que você utiliza.
LiteSpeed precisa incluir os processos LSPHP na manutenção
O LSPHP também pode manter processos ativos entre requisições. A documentação do LiteSpeed explica que o modo separado, chamado detached mode, permite que esses processos continuem executando independentemente do servidor web. Por isso, reiniciar somente o LiteSpeed pode deixar o PHP anterior em uso. A manutenção precisa contemplar os processos LSPHP do domínio. Controle dos processos LSPHP e reinício do PHP no cPanel com LiteSpeed.
O plugin LiteSpeed Cache instalado no WordPress tem outra função. Sua atualização não comprova que o provedor substituiu o interpretador PHP. Para conferir esta correção, solicite a revisão do LSPHP e a confirmação do reinício dos processos. Em uma instalação com OpenLiteSpeed, confira igualmente qual executável LSPHP está associado ao site.
A versão do PHP precisa ser a utilizada pelo domínio
Você encontra informações do servidor no painel do WordPress, em Ferramentas, Saúde do site, Informações, Servidor. Essa área apresenta a versão do PHP e a interface utilizada para executá-lo. Ela oferece um ponto de partida para o chamado à hospedagem, especialmente quando você administra vários domínios com configurações distintas. Documentação da tela Saúde do site.
Compare a série instalada com as revisões corrigidas divulgadas em 21 de outubro de 2026. A tabela apresenta a primeira versão corrigida de cada série suportada naquele comunicado. Uma revisão posterior da mesma série também deve incorporar a correção.
| Série do PHP | Primeira revisão corrigida |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
A tabela segue o anúncio das correções do PHP, que também orienta a consulta aos fornecedores dos pacotes. Distribuições podem aplicar correções a pacotes com numeração própria, por isso você precisa do aviso que associa a revisão instalada às duas CVEs. Uma informação genérica como “PHP 8.3” omite a revisão necessária para essa conferência.
PHP 8.1 e anteriores estão fora do suporte regular do projeto. Foram disponibilizadas correções excepcionais em código-fonte para 7.4, 8.0 e 8.1, mas isso não restabelece a manutenção dessas séries. Uma hospedagem que oferece correções próprias precisa identificar o pacote entregue e o alcance do suporte. Situação das séries antigas no comunicado oficial.
O resultado de php -v no terminal pode corresponder a outro executável. O mesmo cuidado vale para a configuração: o arquivo utilizado pelo terminal pode ser diferente daquele carregado pelo serviço web. Para essa verificação, eu relacionaria a informação do WordPress ao pacote informado pelo suporte. O manual de configuração do PHP descreve como o carregamento varia conforme a interface de execução.
Desativar o progresso de upload é uma medida parcial
A configuração session.upload_progress.enabled = Off reduz os caminhos conhecidos associados às sessões. Ela precisa valer durante a preparação inicial da requisição e exige o reinício dos processos PHP. Alterá-la dentro de um plugin ou no wp-config.php chega tarde para essa finalidade. O aviso também descarta o arquivo .user.ini do PHP-FPM como solução para esse momento do processamento. Mitigações da CVE-2026-109619.
Você ainda precisa da atualização que corrige as duas vulnerabilidades. O recurso de progresso é apenas um dos caminhos descritos, então uma resposta do provedor informando sua desativação precisa vir acompanhada do plano para instalar o pacote corrigido. A existência de uma mitigação aplicada não equivale à conclusão da manutenção.
Plugins de segurança executados dentro do WordPress também têm limites diante de uma falha alcançada durante a inicialização do PHP. Filtros no servidor ou num serviço intermediário podem recusar certas requisições, mas sua cobertura depende dos padrões de ataque identificados por esses filtros. A conferência da correção deve continuar no PHP do domínio, mesmo quando a hospedagem informa que adicionou filtros temporários.
O que solicitar ao suporte da hospedagem
Envie o domínio afetado e os identificadores CVE-2026-109618 e CVE-2026-109619. Acrescente a versão exibida no WordPress para que o suporte localize a instalação. Um chamado específico evita que a resposta se limite à atualização do WordPress ou à existência de um serviço de segurança no plano.
Você pode solicitar estas confirmações no mesmo atendimento:
- PHP do domínio: versão completa, pacote instalado e interface utilizada, como mod_php, PHP-FPM ou LSAPI.
- Correção aplicada: identificação da release corrigida ou do aviso do fornecedor que documenta a correção incorporada ao pacote.
- Processos substituídos: confirmação de que o PHP anterior não continua atendendo o domínio, incluindo processos separados do LiteSpeed.
- Prazo de manutenção: previsão para aplicar a correção quando ainda houver apenas uma medida temporária.
A responsabilidade por essa intervenção depende do serviço contratado. Numa hospedagem gerenciada, o provedor pode administrar os pacotes e processos do PHP. Numa máquina administrada por você, essa tarefa precisa entrar na sua manutenção. O artigo sobre como escolher uma hospedagem explica por que a cobertura do suporte precisa acompanhar o que você consegue manter.
Para acompanhar correções futuras, consulte o changelog da Promovaweb e os avisos originais dos fornecedores. O anúncio de uma release informa que a correção foi disponibilizada. A resposta do suporte precisa mostrar quando o PHP corrigido começou a atender seu domínio.
Como conferir o WordPress depois da atualização
Com a manutenção concluída, volte às informações do servidor no WordPress e compare a versão com a resposta do provedor. Em hospedagens com vários servidores atendendo o mesmo domínio, solicite a conferência de todas as instâncias. Uma única consulta ao painel pode mostrar apenas o servidor que respondeu àquela requisição.
Teste também as funções utilizadas no seu site. Faça login e envie uma imagem à biblioteca de mídia para observar se o processamento termina normalmente. Num site com formulário de contato, confirme o envio e o recebimento da mensagem. Uma loja exige ainda a conferência do fluxo de compra no ambiente apropriado para testes, incluindo as integrações utilizadas no pagamento.
Esses testes verificam o funcionamento após a manutenção e complementam a comprovação da versão corrigida. O resultado não permite descartar uma exploração anterior. Arquivos alterados sem explicação ou contas administrativas desconhecidas exigem uma investigação própria, mesmo depois da atualização do PHP.
A diferença entre instalar um pacote e conferir o serviço ativo também aparece na correção do OpenSSH no Debian. Os procedimentos são diferentes, mas a necessidade de verificar o processo atualizado se repete. É nessa conferência que eu encerraria a manutenção do PHP, junto dos testes do WordPress e do registro fornecido pela hospedagem.
Para estudar a administração dos serviços utilizados pelo seu site, a Formação DevOps da Promovaweb aborda servidores e manutenção de infraestrutura. Para uma investigação acompanhada no seu ambiente, o Desenvolvimento Colaborativo da Dev Side Studio oferece orientação técnica ao vivo. Leve a versão do PHP, a identificação do serviço utilizado pelo domínio e a resposta recebida da hospedagem.
