Depois da PHP2Shell, muitas empresas descobriram que estavam em uma versão do PHP sem correção, ou que nem sabiam qual versão rodava nos seus servidores. Atualizar o PHP é a única saída, mas feito às pressas, o upgrade pode derrubar o site, quebrar o checkout da loja ou deixar um sistema interno fora do ar.
Este guia explica como fazer o upgrade com segurança: a diferença entre os dois tipos de atualização, os riscos de cada um, o passo a passo nos ambientes mais comuns e como voltar atrás se algo der errado.
Não sabe se o seu site está exposto? Comece pela verificação gratuita da NE.
Primeiro: qual upgrade você precisa fazer?
"Atualizar o PHP" pode significar duas coisas bem diferentes, com riscos bem diferentes:
Atualização de correção (dentro do mesmo ramo): por exemplo, do 8.3.20 para o 8.3.36. Traz só correções de falhas e de segurança, sem mudar o comportamento da linguagem. O risco é baixo, e é esse tipo de atualização que fecha falhas como a PHP2Shell.Migração de ramo: por exemplo, do 8.1 para o 8.3, ou do 7.4 para o 8.4. A linguagem muda: funções são removidas, avisos viram erros e extensões saem do pacote padrão. O risco é real e exige teste antes.Se você está em um ramo com suporte, a prioridade é a atualização de correção, que pode ser feita hoje. Se está no PHP 8.1 ou anterior, não existe mais correção: a migração de ramo é obrigatória, e precisa ser planejada.
Quais versões ainda têm suporte
Cada ramo do PHP recebe dois anos de suporte completo e mais dois anos só de correções de segurança. Em outubro de 2026, a situação é esta:
PHP 8.5: suporte completo até 31/12/2027 e correções de segurança até 31/12/2029.PHP 8.4: suporte completo até 31/12/2026 e correções de segurança até 31/12/2028.PHP 8.3: só correções de segurança, até 31/12/2027.PHP 8.2: só correções de segurança, até 31/12/2026. Quem está no 8.2 tem dois meses para planejar a saída.PHP 8.1 ou anterior: sem suporte. Nenhuma falha nova será corrigida.Para uma migração feita agora, o destino mais indicado é o 8.4 ou o 8.5, que garantem pelo menos dois anos de correções sem precisar migrar de novo.
Um ponto importante: Debian, Ubuntu LTS, Red Hat e derivados mantêm o PHP do próprio pacote com correções de segurança durante a vida da distribuição, mesmo depois do fim do suporte oficial do projeto. Se o seu PHP vem da distribuição e ela ainda tem suporte, atualizar o pacote já resolve as falhas, sem migração de ramo.
Os riscos de migrar de ramo
O que costuma quebrar em uma migração:
Funções removidas e avisos que viram erro: o PHP 8 transformou em erro fatal muita coisa que antes era só aviso. Código antigo que "funcionava" com avisos escondidos pode simplesmente parar.Mudanças de comportamento silenciosas: no PHP 8, comparar número com texto mudou (0 == "abc" passou a ser falso). O código não dá erro, mas o resultado muda, e isso é mais perigoso do que um erro.Avisos de descontinuação: o 8.1 passou a avisar quando se passa null para funções nativas que não aceitam null; o 8.2 descontinuou propriedades dinâmicas; o 8.4 descontinuou parâmetros que aceitam null de forma implícita. Hoje são avisos, mas viram erro no PHP 9, e podem encher o log a ponto de lotar o disco.Extensões que saíram do pacote: no PHP 8.4, a extensão IMAP (usada para ler e-mails) saiu do PHP padrão e passou a ser instalada à parte. Sistemas que dependem dela param de funcionar se ninguém perceber.Bibliotecas e plugins: o Composer recusa instalar dependências que não declaram suporte à nova versão, e plugins de WordPress, temas e módulos de Magento ou Joomla abandonados pelo autor podem quebrar o site inteiro.Configuração que não migra sozinha: cada versão do PHP tem o próprio php.ini e os próprios pools do PHP-FPM. Limites de memória, tamanho de upload, fuso horário e ajustes de sessão feitos na versão antiga não passam para a nova.Duas versões rodando ao mesmo tempo: o site pode estar no PHP novo enquanto as rotinas agendadas (cron) e os scripts de linha de comando continuam no antigo, ou o contrário. O problema aparece dias depois, quando um relatório noturno falha.Os cuidados antes de começar
Faça o inventário: liste os servidores, sites, APIs, painéis e ambientes de homologação com PHP, a versão de cada um e quem é o responsável. Os esquecidos costumam ser os mais vulneráveis.Tenha backup testado: snapshot da máquina, cópia do banco de dados e dos arquivos. Backup que nunca foi restaurado não é backup.Teste em homologação: monte uma cópia do ambiente com a nova versão, ligue todos os avisos (error_reporting = E_ALL) e navegue pelos fluxos que dão dinheiro: login, cadastro, carrinho, pagamento, emissão de nota, integrações.Analise o código antes de rodar: ferramentas como PHPStan e Rector apontam e corrigem automaticamente boa parte das incompatibilidades. Em projetos com Composer, composer why-not php 8.4 mostra quais bibliotecas impedem a migração.Confira plugins e extensões: liste as extensões em uso com php -m na versão atual e garanta que todas existem na nova. No WordPress, a tela "Saúde do site" mostra a versão do PHP, e cada plugin informa até qual versão foi testado.Combine a janela e o plano de volta: escolha um horário de menor movimento, avise quem precisa saber e escreva antes como desfazer a mudança.Como fazer o upgrade nos ambientes mais comuns
Debian e Ubuntu
Para a atualização de correção, basta atualizar os pacotes e reiniciar o PHP-FPM:
apt update && apt upgradesystemctl restart php8.3-fpm (troque 8.3 pela sua versão)Para migrar de ramo, a forma mais segura é instalar a versão nova ao lado da antiga, sem remover nada. Versões que a distribuição não oferece vêm do repositório de Ondřej Surý, mantenedor dos pacotes de PHP do Debian (packages.sury.org, ou o PPA ondrej/php no Ubuntu).
Instale o PHP novo e as mesmas extensões da versão atual, por exemplo apt install php8.4-fpm php8.4-mysql php8.4-curl php8.4-mbstring php8.4-xml php8.4-zip php8.4-gd php8.4-intl.Leve para /etc/php/8.4/ os ajustes que vocês fizeram no php.ini e no pool do FPM. Copie só os ajustes, não o arquivo inteiro, porque o arquivo da versão antiga pode ter opções que não existem mais.Troque um site de cada vez, apontando o Nginx ou o Apache para o novo socket (/run/php/php8.4-fpm.sock).Ajuste a linha de comando com update-alternatives --set php /usr/bin/php8.4, para que o cron e os scripts usem a mesma versão do site.Só desinstale a versão antiga depois de alguns dias sem problemas.Red Hat, AlmaLinux e Rocky Linux
O PHP vem em "módulos" do repositório AppStream. Para trocar de ramo, use dnf module reset php, depois dnf module enable php:8.3 (com o ramo desejado) e, por fim, dnf update. Ramos mais novos do que os oferecidos pela distribuição vêm do repositório Remi. Depois, reinicie o php-fpm e o servidor web.
Hospedagem com cPanel ou Plesk
Os dois painéis permitem escolher a versão do PHP por site: no cPanel, pelo "MultiPHP Manager"; no Plesk, nas configurações de PHP de cada domínio. Troque primeiro um site de teste ou de menor movimento. Se a hospedagem não oferece uma versão com suporte, é hora de trocar de hospedagem.
Docker
A versão está na imagem base (por exemplo, FROM php:8.4-fpm). Troque a tag, reconstrua a imagem, instale as extensões necessárias e suba em homologação antes de produção. Lembre de reconstruir as imagens com frequência: um container antigo continua com o PHP vulnerável mesmo que o servidor esteja atualizado.
Depois do upgrade
Reinicie todos os processos: PHP-FPM, Apache e workers de fila. Enquanto não reiniciar, o código antigo continua na memória.Confirme a versão de verdade: php -v mostra a linha de comando, mas o site pode usar outra. Confira também o PHP-FPM e, se possível, uma página interna com a versão em uso (nunca deixe essa página pública).Esconda a versão: deixe expose_php = Off no php.ini, para não anunciar a versão do PHP para quem procura alvos.Acompanhe os logs nas primeiras horas e dias: erros do PHP, erros 500 no servidor web e rotinas agendadas.Teste os fluxos críticos de novo em produção: login, compra, formulários, integrações e e-mails.Se algo der errado
Com a versão antiga instalada ao lado, voltar é simples: aponte o site de volta para o socket antigo e recarregue o servidor web. Em painel de hospedagem, é só escolher a versão anterior. Em Docker, suba a imagem anterior.
Use a volta para ganhar tempo, não para ficar. Se o motivo foi falha de segurança, voltar significa ficar exposto de novo. Nesse caso, mantenha pelo menos a última versão de correção do ramo antigo enquanto o problema é resolvido.
Como a NE ajuda
Atualizar o PHP é rápido quando se sabe o que vai quebrar antes de quebrar. A NE cuida do processo de ponta a ponta:
Inventário de todos os servidores e sites com PHP, inclusive os esquecidos.Análise de compatibilidade do código, das bibliotecas e dos plugins antes da migração.Upgrade com janela combinada, versões lado a lado e plano de volta testado.Monitoramento contínuo com o SOC 24/7 da NE, para identificar falhas e ataques depois da mudança.Faça a verificação gratuita do seu site e, se precisar de ajuda, fale com a nossa equipe de Professional Services.
Fontes
Versões do PHP com suporte (php.net)Guias oficiais de migração entre versões (php.net)PHP2Shell: o que fazer agora com as falhas críticas do PHP
