O PHP 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026, segundo a página oficial de versões suportadas do projeto PHP. A partir de 1º de janeiro de 2027, qualquer falha nova descoberta nessa versão fica sem correção oficial. Se o site, a loja virtual ou o sistema da sua empresa roda em PHP 8.2, o caminho é migrar para o PHP 8.3, 8.4 ou 8.5 antes dessa data, ou ter um plano de contenção para os primeiros meses de 2027.

O tamanho do problema não é pequeno. O PHP é a linguagem de servidor de 69,1% dos sites cuja tecnologia é conhecida, segundo a W3Techs, e o 8.2 aparece em 27% dos sites que usam PHP 8. Em outubro de 2026, a falha conhecida como PHP2Shell mostrou o que está em jogo: o PHP 8.2 recebeu correção a tempo. Depois de 31 de dezembro, uma falha parecida não seria corrigida.

Este artigo explica o calendário, mostra como descobrir a versão do PHP no WordPress, no Laravel e na hospedagem, lista os riscos e propõe um plano de migração em etapas, com os cuidados com plugins e dependências. O texto foi escrito para gestores, sem exigir conhecimento técnico.

O que acontece em 31 de dezembro de 2026

O projeto PHP segue uma política de suporte em duas fases. Cada versão recebe suporte completo por dois anos a partir do lançamento. Nesse período, defeitos e falhas de segurança reportados são corrigidos em versões de manutenção regulares.

Depois desses dois anos, a versão entra em uma segunda fase, também de dois anos, em que só recebe correções de falhas de segurança críticas. As correções saem conforme a necessidade: pode haver várias atualizações no período ou nenhuma, dependendo das falhas reportadas.

Ao fim dos quatro anos, a versão chega ao fim de vida (EOL, do inglês end of life). A página oficial do PHP diz que quem ainda usa uma versão nessa situação deve atualizar o quanto antes, porque pode ficar exposto a falhas de segurança sem correção.

O PHP 8.2 foi lançado em 8 de dezembro de 2022. O suporte completo terminou em 31 de dezembro de 2024. Desde então, ele está na fase de segurança, que termina em 31 de dezembro de 2026.

O ponto central para o gestor é simples. O site não sai do ar em 1º de janeiro. Ele continua funcionando, o que dá a impressão de que nada mudou. O risco aparece quando uma falha grave é descoberta e não existe correção oficial para aplicar.

Calendário de versões do PHP

A tabela abaixo reúne as datas oficiais publicadas pelo projeto PHP para as versões com suporte em novembro de 2026.

As versões anteriores já estão sem suporte. Pela página de versões encerradas do PHP, o 8.1 chegou ao fim de vida em 31 de dezembro de 2025, o 8.0 em 26 de novembro de 2023 e o 7.4 em 28 de novembro de 2022.

Uma leitura prática desse calendário: migrar do 8.2 para o 8.3 resolve o problema por apenas um ano. Em 31 de dezembro de 2027, o 8.3 também sai de cena. Para quem vai fazer o esforço de migração agora, o 8.4 dá fôlego até o fim de 2028, e o 8.5, até o fim de 2029.

Quantos sites ainda rodam PHP 8.2

A W3Techs, que monitora as tecnologias usadas por sites, aponta que 69,1% dos sites com linguagem de servidor conhecida usam PHP, em dados de 1º de novembro de 2026. Entre os sites em PHP, 66% estão no PHP 8, 26,3% no PHP 7 e 7,6% ainda no PHP 5.

Dentro do grupo que usa PHP 8, a distribuição em 2 de novembro de 2026 era esta:

Somando 8.0, 8.1 e 8.2, quase metade dos sites em PHP 8 (47,2%) estará em versão sem suporte a partir de janeiro de 2027. A conta usa os percentuais da W3Techs e não inclui os sites que ainda estão no PHP 7 ou no PHP 5, que já estão sem suporte há anos.

O caso PHP2Shell mostra o tamanho do risco

Em 21 de outubro de 2026, o Centro Canadense de Segurança Cibernética publicou o alerta AL26-026 sobre duas falhas críticas no PHP, registradas como CVE-2026-109618 e CVE-2026-109619. Os relatos abertos chamam o par de falhas de “php2shell”. Segundo o alerta, a exploração bem-sucedida pode permitir que um atacante sem login execute código no servidor.

A situação piorou em poucos dias. A atualização do alerta informa que as duas falhas passaram a ser exploradas na prática e que, em 26 de outubro de 2026, a agência americana CISA as incluiu no catálogo de vulnerabilidades exploradas ativamente.

As correções saíram para todas as versões com suporte:

O próprio alerta lembra que o PHP 8.1 e as versões anteriores não recebem mais atualizações do projeto. Quem estava no 8.1 ficou dependente de distribuições e fornecedores que publicam correções por conta própria, ou da migração às pressas.

Esse é o cenário que espera o PHP 8.2 a partir de janeiro de 2027. Em outubro de 2026, ele recebeu o 8.2.35. Se uma falha do mesmo tipo aparecer em fevereiro de 2027, não haverá 8.2.36.

O alerta também cita uma terceira falha, a CVE-2026-115560, ainda sem correção na data da atualização. Para ela, o projeto PHP recomendou desativar a opção session.upload_progress.enabled até sair a correção. Os detalhes de diagnóstico e correção estão no nosso artigo sobre a falha crítica PHP2Shell e como corrigir.

O contexto global reforça o alerta. O relatório de investigações de violações de dados da Verizon de 2025 aponta a exploração de vulnerabilidades como porta de entrada em 20% das violações analisadas, com alta de 34% em relação ao ano anterior. O mesmo relatório mostra que a participação de terceiros nas violações dobrou, para 30%.

Como descobrir a versão do PHP do seu site ou sistema

O primeiro passo é saber em que versão cada site e sistema roda. Muitas empresas têm mais de um ambiente: o site institucional, a loja virtual, o sistema interno e às vezes uma API de integração. Cada um pode estar em uma versão diferente.

No WordPress

No painel do WordPress, entre em Ferramentas, depois em Saúde do site. Na aba Informação, abra a seção Servidor. A linha “Versão do PHP” mostra a versão em uso. A própria tela de Saúde do site costuma exibir um aviso quando a versão está desatualizada.

A página oficial de requisitos do WordPress recomenda PHP 8.3 ou superior. Ela informa que o WordPress ainda funciona com PHP 7.4 em ambientes antigos, mas avisa que essas versões chegaram ao fim de vida e podem expor o site a vulnerabilidades.

No Laravel e em sistemas sob medida

Em sistemas Laravel, o desenvolvedor pode rodar php artisan about no servidor, que mostra a versão do PHP e do Laravel. O comando php -v também funciona em qualquer servidor com PHP.

Vale olhar o arquivo composer.json na raiz do projeto. A linha "php" dentro de "require" indica a faixa de versões que o sistema aceita, como "^8.2". Isso diz o mínimo exigido, não a versão instalada, por isso a verificação no servidor continua necessária.

Na hospedagem

Em hospedagens com cPanel, a versão costuma aparecer nas ferramentas “Selecionar versão do PHP” ou “MultiPHP Manager”. Em outros painéis, como o hPanel, há uma área de configuração de PHP. Em hospedagem compartilhada, a troca de versão é feita pelo próprio painel, mas isso não dispensa testar o site antes.

Um cuidado: evite publicar páginas de diagnóstico como phpinfo() no ar. Elas mostram detalhes do servidor que ajudam um atacante. Se usar para conferir a versão, apague o arquivo logo em seguida.

Quando o sistema é de um fornecedor

Se um fornecedor mantém o sistema, peça por escrito o inventário de versões: PHP, framework, banco de dados e sistema operacional, de cada ambiente. Pergunte também qual é o plano para 31 de dezembro de 2026. A resposta mostra se existe um processo de sustentação ou se o sistema está parado desde a entrega.

Os riscos de continuar no PHP 8.2 depois de 2026

Continuar no 8.2 em 2027 não é ilegal nem derruba o site. Os riscos são de outra natureza e crescem com o tempo.

1. Falhas sem correção. Qualquer vulnerabilidade nova descoberta depois de 31 de dezembro de 2026 fica aberta. Em sistemas expostos à internet, como lojas e portais de clientes, isso aumenta a chance de invasão.
2. Dependências que abandonam a versão. Frameworks e bibliotecas acompanham o calendário do PHP. O Laravel 13, lançado em março de 2026, já exige PHP 8.3 ou superior. Quem fica no 8.2 também fica preso a versões antigas do framework.
3. Plugins e temas que deixam de funcionar. No WordPress, autores de plugins passam a testar e publicar apenas para versões novas. Com o tempo, atualizar um plugin pode exigir PHP mais novo.
4. Exigências de clientes, auditorias e seguros. Questionários de segurança de grandes clientes e de seguradoras costumam perguntar sobre software sem suporte. Uma resposta ruim pode atrasar contratos.
5. Responsabilidade com dados pessoais. A LGPD (Lei 13.709/2018) exige que as empresas adotem medidas de segurança para proteger os dados que tratam. Manter software sem suporte em um sistema com dados de clientes pode pesar contra a empresa em caso de incidente. Para a análise do caso concreto, valide com um advogado.
6. Migração mais cara no futuro. Quanto maior a distância entre a versão atual e a versão de destino, mais mudanças se acumulam. Pular do 8.2 para o 8.4 hoje é mais simples do que pular do 8.2 para uma versão ainda mais nova daqui a dois anos.

Plano de migração para PHP 8.3 ou 8.4 em etapas

A migração de versão do PHP é um projeto pequeno na maioria dos casos, mas não é um clique no painel. A sequência abaixo reduz o risco de quebrar o site ou o sistema em produção.

1. Faça o inventário. Liste todos os sites, sistemas e APIs em PHP, com a versão do PHP, do framework, do banco de dados e dos plugins. Marque quais ficam expostos à internet e quais tratam dados pessoais ou pagamentos.
2. Escolha a versão de destino. Para quem está no 8.2, o 8.4 é o destino mais equilibrado: tem correções de segurança até 31 de dezembro de 2028 e boa compatibilidade com frameworks e plugins. O 8.5 dá mais prazo, até 2029, mas pode exigir mais atualização de dependências.
3. Monte um ambiente de testes igual ao de produção. Copie o código, o banco de dados (com dados anonimizados quando houver informação pessoal) e as configurações. Instale a versão nova do PHP nesse ambiente.
4. Atualize as dependências. No Composer, o gerenciador de pacotes do PHP, o comando composer outdated mostra o que está desatualizado, e composer why-not php 8.4 mostra quais pacotes impedem a troca. No WordPress, atualize núcleo, plugins e temas primeiro no ambiente de testes.
5. Rode uma análise de compatibilidade. Ferramentas de análise estática, que leem o código sem executá-lo, apontam funções removidas e usos que geram avisos na versão nova. Corrija o que for apontado antes de testar o fluxo completo.
6. Teste os fluxos que dão dinheiro. Cadastro, login, carrinho, checkout, emissão de nota, integrações com ERP e gateways de pagamento. Testes automatizados aceleram muito essa etapa. Sem eles, monte um roteiro de testes manuais.
7. Ative os logs de aviso. Avisos de recurso obsoleto (deprecation) não quebram o sistema, mas indicam o que vai quebrar na próxima versão. Registre e corrija o que aparecer.
8. Planeje a virada e o retorno. Escolha uma janela de baixo movimento, faça backup completo e defina como voltar à versão anterior se algo falhar. Em hospedagem compartilhada, o retorno costuma ser trocar a versão no painel.
9. Monitore depois da troca. Acompanhe erros, tempo de resposta e fluxos de venda nos primeiros dias. Deixe alguém de plantão para corrigir rápido o que aparecer.

A escolha da versão de destino depende do prazo e do estado do sistema:

O que muda do PHP 8.2 para o 8.3 e o 8.4

Os guias oficiais de migração do PHP dividem as mudanças em novos recursos, mudanças incompatíveis, recursos obsoletos e extensões removidas. O guia do 8.3 avisa que a versão traz algumas incompatibilidades que devem ser testadas antes da troca em produção.

No PHP 8.4, alguns pontos aparecem com frequência em sistemas antigos:

• Parâmetros que aceitam nulo de forma implícita passaram a gerar aviso de obsolescência. Um código como function foo(T1 $a = null) precisa declarar o tipo como ?T1 ou T1|null.
• A constante E_STRICT ficou obsoleta, porque o nível de erro correspondente foi removido.
• Funções da extensão MySQLi como mysqli_ping(), mysqli_kill() e mysqli_refresh() ficaram obsoletas. Sistemas antigos que conectam ao MySQL podem usar essas funções.
• trigger_error() com E_USER_ERROR ficou obsoleto; o caminho indicado é lançar uma exceção ou encerrar a execução.
• Quatro extensões saíram do pacote padrão e foram para o repositório PECL: IMAP, OCI8, PDO_OCI e PSpell. Sistemas que leem e-mail por IMAP ou conectam a bancos Oracle precisam instalar essas extensões à parte.

Avisos de obsolescência não derrubam o sistema na versão atual. Eles indicam o que será removido no futuro. Por isso, a migração é a hora certa de limpar esses pontos, e não só de trocar o número da versão.

Cuidados com plugins, temas e dependências

Na maior parte dos casos, o problema da migração não está no código principal, e sim no que foi instalado ao redor dele.

WordPress

O manual oficial do WordPress publica a compatibilidade do núcleo com cada versão do PHP. O PHP 8.3 é compatível a partir do WordPress 6.4, o 8.4 a partir do 6.7 e o 8.5 a partir do 6.9. Ou seja, quem está com o WordPress desatualizado precisa atualizar o núcleo antes de trocar o PHP.

O próprio manual lembra que o WordPress raramente é usado sem tema e plugins. A compatibilidade do núcleo não garante a compatibilidade de cada plugin. Antes da troca, confira:

• a data da última atualização de cada plugin e tema;
• se o autor informa a versão de PHP testada;
• se há plugins abandonados, sem atualização há muito tempo, que precisam ser substituídos;
• se há temas ou plugins personalizados, feitos sob encomenda, que ninguém mantém.

Laravel e outros frameworks

O Laravel publica uma tabela de suporte por versão. A política é de 18 meses de correções de defeitos e 2 anos de correções de segurança.

A tabela mostra um efeito em cadeia. Um sistema em Laravel 10 ou 11 já está sem correções de segurança do framework, mesmo que o PHP ainda tenha suporte. Nesses casos, a migração do PHP vem junto com a atualização do Laravel, e o esforço é maior.

Bibliotecas e integrações

Bibliotecas de pagamento, emissão de nota fiscal, envio de e-mail e integração com ERP também têm exigências de versão. Uma biblioteca de gateway antiga pode não funcionar no PHP 8.4. Teste cada integração no ambiente de homologação, de preferência com as credenciais de teste de cada fornecedor.

E se não der tempo até 31 de dezembro?

Faltam poucas semanas para o fim do ano, e a agenda de muitas empresas está tomada por fechamento e Black Friday. Se a migração não couber antes de 31 de dezembro, há medidas de contenção para os primeiros meses de 2027.

• Priorize o que está exposto. Sites públicos, lojas e portais de clientes vêm primeiro. Sistemas internos, acessíveis só por rede privada ou VPN, podem vir depois.
• Verifique correções de terceiros. O alerta canadense lembra que algumas distribuições Linux e fornecedores de suporte estendido publicam correções para versões antigas. Confira com o seu provedor se isso vale para o seu ambiente.
• Aplique a última versão do 8.2. Garanta que o servidor está na última atualização publicada do 8.2 antes de 31 de dezembro, o que inclui a correção do PHP2Shell.
• Reforce as camadas de proteção. Um firewall de aplicação web (WAF) e o monitoramento de logs ajudam a bloquear e detectar tentativas de exploração, mas não substituem a correção.
• Marque a data da migração. A contenção serve só para ganhar tempo. Defina no calendário a janela de migração do primeiro trimestre de 2027.

Quanto custa e quanto tempo leva a migração

O custo depende do tamanho do sistema, da distância entre as versões e da existência de testes automatizados. A tabela abaixo traz faixas de referência para orientar o orçamento.

Estimativa de referência da Mind Group, calculada como horas estimadas × valor-hora de R$ 110 a R$ 190, conforme a senioridade do time. As faixas de horas são estimativas para orientar o orçamento; o valor final depende do diagnóstico de cada sistema.

Empresas com contrato de sustentação costumam absorver parte desse trabalho nas horas mensais. Na Mind, a sustentação vai de 20 a 80 horas por mês, e a atualização de versões entra no planejamento do contrato. O artigo sobre sustentação de sistemas explica por que lançar e esquecer sai mais caro.

Para colocar a migração na conta do custo total do software ao longo dos anos, veja a metodologia de TCO de software empresarial. Se o sistema é antigo demais para uma simples troca de versão, o guia de modernização de sistemas legados ajuda a decidir entre atualizar e reconstruir.

Como a Mind Group pode ajudar

A Mind Group é uma software house brasileira, fundada em 2016, que desenvolve sistemas, aplicativos e soluções de inteligência artificial sob medida para empresas de todo o Brasil. Tem mais de 60 desenvolvedores próprios, mais de 500 produtos digitais lançados, nota 5,0 no Clutch com 17 avaliações verificadas de clientes, entrega o código-fonte ao cliente e mantém uma frente de cibersegurança dedicada à correção de vulnerabilidades e à resposta a incidentes.

Para o fim do suporte do PHP 8.2, a frente de cibersegurança da Mind faz o inventário de versões, aplica as correções de urgência, como as do PHP2Shell, e investiga sinais de comprometimento quando há suspeita de invasão. O time de desenvolvimento executa a migração para o PHP 8.4 ou 8.5 em ambiente de testes, com entregas a cada duas semanas e plano de retorno.

Para entender os riscos mais comuns em aplicações web, veja o guia de segurança no desenvolvimento de software e OWASP Top 10. O guia de cibersegurança para empresas no Brasil traz o quadro mais amplo. A página de desenvolvimento de sistemas explica como a Mind trabalha.

Atualizado em novembro de 2026.

Perguntas frequentes

Até quando o PHP 8.2 recebe correções de segurança?

Pela página oficial do projeto PHP, o 8.2 recebe correções de segurança até 31 de dezembro de 2026. O suporte completo, com correção de defeitos, já terminou em 31 de dezembro de 2024.

Meu site vai parar de funcionar em 1º de janeiro de 2027?

Não. O site continua funcionando normalmente. O que muda é que falhas de segurança descobertas a partir dessa data não recebem correção oficial, o que aumenta o risco de invasão com o passar do tempo.

Devo migrar para o PHP 8.3, 8.4 ou 8.5?

Para a maioria das empresas, o PHP 8.4 é o destino mais equilibrado, com segurança até 31 de dezembro de 2028. O 8.3 só vai até o fim de 2027 e exigiria nova migração em pouco tempo. O 8.5 dá prazo até 2029, mas pode exigir mais atualizações de dependências.

Como saber a versão do PHP no WordPress?

No painel, acesse Ferramentas, depois Saúde do site, aba Informação, seção Servidor. A linha “Versão do PHP” mostra a versão em uso. O WordPress recomenda PHP 8.3 ou superior.

A falha PHP2Shell afeta o PHP 8.2?

Sim. Segundo o alerta do Centro Canadense de Segurança Cibernética, o 8.2 é afetado nas versões anteriores à 8.2.35, que traz a correção. Quem está no 8.2 deve atualizar para essa versão imediatamente e planejar a migração antes do fim do suporte.

Quanto tempo leva a migração da versão do PHP?

Depende do sistema. Um site WordPress com poucos plugins pode levar de 8 a 24 horas de trabalho, enquanto um sistema sob medida com framework desatualizado pode passar de 80 horas, segundo estimativa de referência da Mind Group. O diagnóstico inicial define o prazo real.

Fontes: PHP: Supported Versions · PHP: Unsupported Branches · PHP: Migrating from PHP 8.2.x to PHP 8.3.x · PHP: Migrating from PHP 8.3.x to PHP 8.4.x · PHP 8.4: Deprecated Features · PHP 8.4: Removed Extensions · Canadian Centre for Cyber Security: alerta AL26-026 · W3Techs: uso de PHP em sites · W3Techs: versões do PHP 8 · WordPress: Requirements · WordPress Core Handbook: PHP Compatibility and WordPress Versions · Laravel: Release Notes e política de suporte · Verizon: 2025 Data Breach Investigations Report