PHP: entenda as falhas de segurança e como atualizar o servidor
Um guia sem complicação para entender o problema, revisar a atualização no AlmaLinux 9 com cPanel e conferir se os sites continuam funcionando.
As vozes dependem do navegador e do dispositivo; algumas precisam de internet. Blocos de código não são narrados.
Em 21 de outubro de 2026, o projeto PHP publicou correções para duas vulnerabilidades críticas. Se você administra um site em PHP, vale abrir espaço na agenda para uma atualização. Antes de sair colando comandos, porém, vamos entender o problema e organizar a manutenção sem transformar a pressa em outro incidente.
Quem precisa prestar atenção?
O alerta do PHP abrange instalações que atendem requisições web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. As correções oficiais estão em 8.2.35, 8.3.36, 8.4.27 e 8.5.12, ou posteriores da respectiva série. As duas falhas podem permitir execução remota sem autenticação. Alerta oficial do PHP.
Isso inclui o PHP por trás de WordPress, Laravel, lojas virtuais e sistemas próprios. Atualizar somente plugins ou o framework não substitui corrigir o interpretador. Por outro lado, ter Apache ou Nginx instalado, sem executar PHP, não coloca o serviço no escopo dessas duas falhas.
“Execução remota” significa conseguir fazer o processo executar código escolhido pelo atacante. O impacto depende das permissões e do isolamento do ambiente; não significa, automaticamente, acesso root.
As duas vulnerabilidades, sem complicar
CVE-2026-109618: quando a memória se esgota, a inicialização pode parar num estado inválido. A correção torna esse caminho seguro. Há exploração demonstrada em mod_php antes do código do site; PHP-FPM é suscetível, mas aquele exploit completo não foi demonstrado nele. Detalhes técnicos.
CVE-2026-109619: um processo reaproveitado pode guardar referências à memória de uma requisição anterior e usá-las depois de liberadas. A correção limpa esse estado. A exploração depende de condições da aplicação/configuração; os caminhos documentados incluem mod_php e sessões em PHP-FPM. Detalhes técnicos.
Como atualizar no AlmaLinux 9 com cPanel
O roteiro abaixo é para AlmaLinux 9 com cPanel/WHM e EasyApache 4. Execute como root ou com os privilégios administrativos apropriados. Não copie esses comandos para Ubuntu, instalações sem cPanel ou servidores que usam outro fornecedor de PHP.
1. Prepare o terreno
Confira se existe backup recente dos arquivos, bancos e configurações, com um caminho conhecido de restauração. Reserve uma janela de manutenção e tenha acesso ao console do provedor caso a conexão SSH caia.
No MultiPHP Manager, identifique a versão atribuída a cada domínio e o uso de PHP-FPM. Liste também tarefas agendadas, filas e aplicações que tenham configuração própria. O resultado de php -v no terminal não comprova qual PHP atende todos os sites.
Evite misturar essa correção emergencial com uma troca de série, como sair de 8.2 para 8.5. Primeiro aplique o patch disponível; planeje e teste migrações separadamente.
2. Confira o pacote corrigido
O EasyApache 4 registrou as correções e backports para ea-php74, ea-php80 e ea-php81. Backport é a correção aplicada à série antiga, sem trocar seu número principal. Isso não garante suporte a todo PHP obsoleto nem dispensa conferir o pacote oferecido pelo seu repositório. Changelog do cPanel.
Anote as versões e revisões (builds) dos pacotes instalados e compare com o boletim do fornecedor. Se a correção não aparecer, investigue repositórios, exclusões e disponibilidade com o suporte. “Nada a fazer” não é confirmação de proteção.
3. Veja a transação antes de instalar
O filtro ea-php* não cobre alt-php, containers ou binários PHP instalados à parte; atualize-os pelo fornecedor correspondente.
Atualize os metadados e peça ao DNF para mostrar a proposta, recusando a execução automaticamente, conforme as opções do DNF:
dnf --refresh upgrade 'ea-php*' --assumeno
Confira os pacotes, dependências, versões e possíveis remoções. O * está entre aspas para ser interpretado pelo DNF, não pelo shell. Se aparecer conflito, remoção inesperada ou troca de fornecedor, pare e investigue. Não use opções para forçar a transação às cegas.
Com a proposta conferida, execute:
dnf --refresh upgrade 'ea-php*'
Leia o resumo novamente e confirme somente se estiver correto. O comando não leva -y justamente para manter essa revisão. Aguarde a conclusão e verifique se houve erros; o encerramento esperado costuma mostrar Complete!.
4. Garanta que o PHP novo está em uso
Pacote instalado no disco não basta se processos antigos continuarem rodando. O cPanel pode reiniciar serviços automaticamente, mas confira o resultado. Para procurar serviços desatualizados sem reiniciá-los:
/usr/local/cpanel/scripts/find_outdated_services --never-restart
Esse comando é diagnóstico, não uma ordem para reiniciar tudo. Documentação do script.
Identifique os processos PHP e serviços envolvidos. Se ainda houver workers antigos, recarregue ou reinicie somente os serviços necessários pelo procedimento adequado ao seu ambiente, considerando a interrupção. Não presuma que uma lista vazia substitui verificar a versão realmente usada pela aplicação.
Confira os pacotes corrigidos, o PHP de cada site e os serviços ativos. Teste login, páginas importantes, formulários, tarefas cron e filas. Observe os logs após a manutenção. Uma atualização apenas do PHP não exige automaticamente reiniciar o servidor inteiro; outras atualizações podem ter requisitos próprios.
E nos outros ambientes?
- Linux sem cPanel: use os pacotes e o procedimento do fornecedor da sua instalação. Confirme no boletim se há correção ou backport; comparar apenas o número principal pode enganar.
- Containers: obtenha uma imagem PHP corrigida, reconstrua quando necessário e faça novo deploy. Verifique também as réplicas ainda em execução.
- Hospedagem compartilhada: peça ao provedor a confirmação da correção e da versão efetivamente usada pelo domínio.
- PHP fora de suporte: procure uma correção explicitamente mantida pelo fornecedor e planeje a migração. Não suponha que qualquer versão antiga recebeu patch.
Por fim, WAF e regras de firewall são camadas extras, não substitutos da atualização. Aplicar o patch também não prova que nunca houve invasão. Se surgirem sinais suspeitos, preserve logs e investigue além da manutenção.
Resumo prático: confira o ambiente, tenha backup, revise a atualização e valide os sites e processos depois. Segurança melhora quando a atualização termina com verificação, não apenas com o terminal fechado.
Fontes consultadas em 21 de outubro de 2026.