PHP End of Life: por que seu site pode estar em risco mesmo funcionando normalmente

PHP End of Life (EOL) é o fim do período de suporte oficial de uma versão do PHP. A partir dessa data, o projeto deixa de disponibilizar correções de bugs e atualizações de segurança para aquela ramificação. O site pode continuar funcionando normalmente, mas o uso de software sem suporte aumenta o risco de vulnerabilidades não corrigidas oficialmente. O PHP 8.2 chega ao fim do suporte oficial em 31 de dezembro de 2026. Sites nessa versão devem planejar a migração para PHP 8.4 ou 8.5 antes desse prazo.

Quando a vulnerabilidade PHP2Shell foi divulgada em outubro de 2026, uma das perguntas mais frequentes que recebi foi esta: “Mas meu site está no PHP 7.4 há anos e nunca deu problema. Por que agora não tem patch?”

A resposta não tem nada a ver com essa vulnerabilidade específica. Tem a ver com um ciclo que o time do PHP segue há décadas e que a maioria dos donos de site nunca conheceu porque ninguém no processo de contratação da hospedagem explicou.

Esse ciclo se chama End of Life. E o próximo prazo importante vence em dezembro deste ano.

O que é PHP End of Life e por que importa para o seu site

Quando o PHP entra em End of Life, o projeto para de emitir qualquer atualização oficial para aquela versão. Isso inclui patches de segurança e correções de bugs. Alguns fornecedores de hospedagem e distribuições Linux oferecem backports de segurança por conta própria para versões antigas, mas isso depende de contrato, repositório e política específica de cada provedor. Sem proteção comprovada, um site em PHP EOL fica exposto a qualquer vulnerabilidade descoberta a partir daquela data.

O PHP segue um ciclo de suporte oficial dividido em duas etapas: dois anos de suporte ativo, com correções de bugs e segurança, seguidos de mais dois anos dedicados exclusivamente a atualizações críticas de segurança. Ao final desses quatro anos, a versão é declarada EOL e o suporte oficial encerra.

Antes de 2020, o ciclo era de três anos. O projeto PHP ampliou o período total para quatro anos a partir das versões mais recentes, o que dá mais tempo de planejamento para equipes técnicas e administradores de servidor.

O site continua no ar depois do EOL. Os visitantes chegam, os pedidos entram, o formulário de contato funciona. Mas, por baixo, qualquer pesquisador de segurança que encontre uma falha naquela versão sabe que ela não terá correção oficial. Esse é o risco concreto.

E a máquina concorda com isso cada vez que um scanner automatizado detecta a versão e a marca como alvo em listas que circulam entre ferramentas de varredura.

Calendário PHP 2026: quais versões ainda recebem suporte

Em outubro de 2026, apenas PHP 8.3, 8.4 e 8.5 recebem atualizações de segurança oficiais do projeto PHP. PHP 8.1 entrou em EOL em dezembro de 2025. PHP 8.2 entra em EOL em 31 de dezembro de 2026. PHP 8.3 tem suporte até dezembro de 2027. PHP 8.4 até dezembro de 2028. PHP 8.5 até dezembro de 2029.

Fontes: PHP Supported Versions e PHP Unsupported Branches.

O que isso significa agora: PHP 8.1 já está em EOL desde dezembro de 2025. PHP 8.2 encerra suporte em dois meses. Qualquer site nessas versões que não migre fica na mesma situação do PHP 7.4 quando a PHP2Shell foi divulgada: sem caminho de correção oficial para vulnerabilidades novas.

PHP 8.3, 8.4 e 8.5 são as únicas versões com suporte ativo neste momento. Para novos projetos e migrações, PHP 8.4 ou 8.5 são as escolhas mais longevas disponíveis hoje.

Por que seu site pode estar em versão antiga sem que ninguém tenha avisado

Quando comecei a trabalhar com manutenção de sites PHP, há 12 anos, o processo de contratação de hospedagem era simples: você escolhia o plano, criava a conta e instalava o WordPress. A versão do PHP que vinha por padrão era o que você usava, salvo instrução contrária.

O problema é que esse modelo ainda é o padrão hoje. A maioria das hospedagens instala o PHP disponível no momento da criação da conta. Depois, esse PHP envelhece junto com o site, e ninguém avisa quando ele entra em EOL.

Já encontrei sites em PHP 7.4 cujos donos achavam que estavam atualizados porque o WordPress mostrava “tudo verde”. A saúde do WordPress e a saúde do PHP são métricas separadas. Um WordPress atualizado rodando em PHP EOL é como um carro com todos os fluidos em dia e a estrutura do chassi comprometida.

Três situações que criam esse cenário:

Hospedagem compartilhada com PHP fixo: O painel permite trocar a versão, mas a versão padrão nunca muda automaticamente. O site pode ficar em PHP 8.1 indefinidamente enquanto o provedor não force a atualização.

Migração entre provedores: Ao mover o site para uma hospedagem diferente, a versão do PHP da nova conta é definida no processo de criação e frequentemente não corresponde à versão mais recente suportada.

Sites com plugins legados: A razão mais comum para não atualizar o PHP é o medo de quebrar algum plugin. O resultado é um site preso em versão EOL porque a atualização foi adiada indefinidamente.

Os riscos de usar PHP fora de suporte

Os riscos de rodar PHP EOL são principalmente de segurança: vulnerabilidades descobertas após o fim do suporte oficial não recebem patch do projeto PHP. Alguns fornecedores disponibilizam backports próprios, mas isso não é garantido e depende de verificação caso a caso. Riscos secundários incluem incompatibilidade crescente com bibliotecas e extensões que evoluem para versões mais recentes, e eventual não conformidade com exigências contratuais de segurança.

Vulnerabilidades sem patch oficial: Cada nova CVE publicada para a versão EOL é um problema que o projeto PHP não vai corrigir. Fornecedores de hospedagem gerenciada, distribuições Linux com suporte estendido ou contratos de suporte comercial podem disponibilizar backports por conta própria, como a Plesk fez durante a PHP2Shell. Mas isso não é garantido e varia por provedor. Para confirmar, pergunte diretamente ao seu provedor se ele oferece atualizações de segurança para versões EOL e qual é o repositório utilizado.

Incompatibilidade crescente: Bibliotecas, frameworks e extensões PHP migram para versões mais recentes ao longo do tempo. Um site em PHP EOL começa a acumular incompatibilidades com componentes que dependem de recursos das versões mais recentes.

Conformidade contratual: O PCI DSS estabelece requisitos de gerenciamento de vulnerabilidades e aplicação de atualizações de segurança. A LGPD não especifica uma versão mínima do PHP, mas exige medidas técnicas adequadas de proteção de dados. Se o site processa pagamentos ou dados pessoais, o uso de versão EOL pode entrar em conflito com esses requisitos dependendo do contrato com o processador de pagamentos e do auditor. Consulte o responsável técnico pelo compliance do seu ambiente para avaliar o impacto específico.

Como atualizar o PHP do WordPress sem quebrar o site

O principal bloqueio que vejo em clientes é o medo de que atualizar o PHP quebre o site. Esse medo é legítimo, especialmente em sites com plugins antigos ou temas customizados. Mas é um risco gerenciável, não uma razão para permanecer em EOL.

1. Levante os plugins e o tema em uso

Antes de qualquer atualização, documente todos os plugins ativos e o tema em uso. Verifique no repositório oficial do WordPress se cada plugin tem suporte declarado para PHP 8.3, 8.4 ou 8.5. O WordPress informa suporte completo ao PHP 8.5 nas versões 6.9 e 7.0, e ao PHP 8.4 a partir da versão 6.8. Fontes: Make WordPress Core e WordPress.org Requirements. Plugins sem atualização há mais de um ano em versões críticas são candidatos a substituição antes da migração.

2. Use um ambiente de staging

A maioria das hospedagens modernas oferece staging com um clique. Se a sua não oferece, crie uma cópia do site em um subdomínio temporário. Suba a versão do PHP nesse ambiente primeiro e rode o site completo: páginas, formulários, checkout, painéis de login.

3. Monitore os logs de erro

Depois de atualizar o PHP no staging, acesse os logs de erro do PHP. Funções depreciadas e comportamentos que mudaram entre versões aparecem aí, não necessariamente na tela. Corrija antes de aplicar em produção.

4. Aplique em produção em horário de baixo tráfego

Com o staging validado, aplique a mesma versão do PHP em produção no horário de menor tráfego. Mantenha a opção de reversão disponível no painel da hospedagem. Se algo quebrar em produção, revertendo temporariamente para a versão anterior você ganha tempo para investigar, mas lembre que a versão anterior pode ser EOL ou vulnerável. A reversão é uma medida de continuidade operacional, não de segurança. Ela deve ser acompanhada de um plano de correção imediato e, se necessário, de mitigações adicionais enquanto a migração é retomada.

5. Confirme a versão em execução

Crie um arquivo temporário phpinfo.php com <?php phpinfo(); no diretório público, acesse pelo navegador e anote a versão exibida. Delete o arquivo imediatamente. Esse método confirma o PHP que efetivamente serve as requisições web, que pode ser diferente do resultado de php -v no terminal em ambientes com múltiplas versões instaladas.

PHP EOL prejudica o SEO?

A versão do PHP não é um fator direto de ranqueamento no Google. O impacto no SEO é indireto: um site comprometido por vulnerabilidade em PHP EOL pode ter spam injetado em páginas indexadas, receber flags de segurança no Google Search Console e sofrer erros de servidor durante ataques ativos. Esses efeitos impactam rastreamento, indexação e CTR. A recuperação da visibilidade orgânica após um comprometimento varia significativamente dependendo da extensão do problema e do tempo até a limpeza.

Doze anos trabalhando com SEO técnico me ensinaram que a maioria dos clientes que busca socorro depois de uma queda de tráfego orgânico não teve problema de conteúdo. Teve problema de infraestrutura.

Um site comprometido por uma falha em PHP EOL pode ter conteúdo de spam injetado silenciosamente em páginas indexadas. O Google detecta esse padrão e pode aplicar penalidades, exibir avisos de segurança antes da abertura da página e remover páginas do índice. O proprietário do site frequentemente descobre pela queda de tráfego, não pelo alerta.

O trabalho de reverter envolve: limpar o comprometimento, verificar alertas no Google Search Console em Segurança e Ações Manuais, solicitar revisão quando aplicável e acompanhar a recuperação progressiva da indexação. Nada disso é instantâneo, e o tempo de recuperação varia de site para site conforme a extensão do problema.

Manter o PHP atualizado é parte da infraestrutura que garante que o conteúdo seja rastreado, indexado e mantido estável. Não é uma garantia de melhor posicionamento, mas é uma das condições para que o posicionamento não seja comprometido.

E a máquina concorda com isso cada vez que rastreia um site com comportamento instável e começa a reduzir a frequência de rastreamento.

Perguntas frequentes sobre PHP End of Life

Meu site está em PHP 7.4 há anos e funciona bem. Isso é suficiente?

Funcionar não é o mesmo que estar seguro. PHP 7.4 está em EOL desde novembro de 2022. Qualquer CVE publicada para essa versão depois dessa data não tem patch oficial. Você não vê o problema porque exploração de servidor raramente quebra a funcionalidade imediatamente. O problema aparece meses depois, quando o Google flagra conteúdo malicioso injetado ou quando dados de clientes são comprometidos.

Minha hospedagem atualiza o PHP automaticamente quando ele entra em EOL?

A maioria não atualiza a versão principal automaticamente. Atualizações de segurança dentro da mesma versão, como de 8.3.34 para 8.3.36, podem ser aplicadas pelo provedor. Mas a migração de PHP 8.2 para PHP 8.4 geralmente exige ação manual no painel ou solicitação ao suporte. Confirme a política do seu provedor antes de assumir que ele cuida disso.

Para qual versão devo migrar agora?

Para projetos WordPress atualizados, PHP 8.4 e PHP 8.5 são as opções com maior longevidade disponíveis hoje. PHP 8.4 tem suporte oficial até dezembro de 2028. PHP 8.5, lançado em novembro de 2025, tem suporte até dezembro de 2029. PHP 8.3 também permanece suportado até dezembro de 2027 e é uma opção válida se a compatibilidade dos plugins ainda não foi validada para 8.4 ou 8.5. Antes de migrar, confirme que seus plugins e tema suportam a versão escolhida e teste em staging.

Se eu migrar para PHP 8.4 agora, preciso repetir esse processo em breve?

PHP 8.4 tem suporte de segurança até dezembro de 2028. Você tem dois anos sem precisar se preocupar com EOL de PHP nessa versão. PHP 8.5 estende esse prazo até dezembro de 2029.

PHP 8.1 ainda recebe patches?

Não. PHP 8.1 entrou em EOL em dezembro de 2025. O projeto PHP não emite mais nenhuma atualização para essa versão. Alguns fornecedores podem ter oferecido backports durante um período transitório, mas não há garantia de cobertura contínua. Sites em PHP 8.1 devem migrar para uma versão suportada.

Quanto tempo leva uma migração de PHP com segurança?

Para um site WordPress padrão com staging disponível, entre duas e quatro horas de trabalho técnico. Para sites com plugins customizados, código legado ou sem staging, o processo pode levar um dia inteiro contando levantamento, testes, análise de logs e validação. O tempo é diretamente proporcional à quantidade de dívida técnica acumulada.