Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- O suporte estendido do PHP incorpora patches de segurança para versões do PHP que já ultrapassaram o fim de vida útil (EOL), permitindo que você mantenha as aplicações em produção seguras sem a necessidade de uma migração forçada.
- O suporte estendido não altera a versão do PHP nem o comportamento do seu aplicativo. Ele corrige falhas de segurança conhecidas enquanto a migração ocorre de acordo com o seu cronograma.
- A partir de agosto de 2026, o PHP 8.1 e todas as versões anteriores estarão fora de suporte (EOL) e não receberão mais patches da comunidade. O PHP 8.2, 8.3, 8.4 e 8.5 ainda têm suporte, mas cada um deles tem uma data de validade definida.
- Utilizar versões do PHP em fim de vida útil (EOL) sem suporte estendido implica em vulnerabilidades CVE sem correção, maior risco de auditoria e conformidade e uma superfície de ataque cada vez maior.
Se você utiliza PHP em ambiente de produção, o fim do ciclo de vida coloca você em uma situação familiar e desagradável: atualizar um aplicativo que não recebe atualizações há anos ou continuar usando um ambiente de execução que não recebe mais correções de segurança. Nenhuma das opções é ideal.
O suporte estendido ao PHP é a terceira opção.
Este artigo aborda o que o suporte estendido realmente inclui (e o que não inclui), os riscos relacionados à conformidade e aos CVEs decorrentes de não adotá-lo, quais versões do PHP precisam dele no momento, como avaliar essa opção em relação à atualização e quais são os provedores que vale a pena conhecer em 2026.
O que é o Suporte Estendido do PHP?
O suporte estendido ao PHP é um serviço oferecido pelo fornecedor que continua a disponibilizar patches de segurança para uma versão do PHP após o próprio projeto PHP ter encerrado suas atividades. Quando uma versão do PHP chega ao fim de sua vida útil, o projeto PHP encerra seu ciclo de vida: não há mais correções de vulnerabilidades (CVE), nem patches, nem nada.
O suporte estendido reabre essa possibilidade. Um fornecedor monitora as vulnerabilidades recém-divulgadas e aplica as correções ao ambiente de execução em fim de vida útil (EOL), de modo que seu aplicativo continue funcionando em um ambiente corrigido enquanto você planeja a migração de acordo com seu próprio cronograma, e não com o de terceiros.
Como funciona o ciclo de vida das versões do PHP
Os lançamentos do PHP agora seguem um ciclo de vida de quatro anos: dois anos de suporte ativo, seguidos de dois anos de suporte à segurança. Esse período foi estabelecido a partir de uma mudança no ciclo de lançamento do PHP, ocorrida em março de 2024, e se aplica ao PHP 8.1 e versões posteriores. Versões mais antigas, como o PHP 7.4 e o 8.0, mantiveram o ciclo de vida anterior de três anos, composto por dois anos de suporte ativo e um ano de suporte à segurança.
| Fase do ciclo de vida | Duração | O que você recebe |
| Apoio ativo | Primeiros 2 anos | Correções de bugs, melhorias de desempenho, patches de segurança |
| Suporte à segurança | Próximos 2 anos | Apenas correções críticas de segurança |
| Fim da vida | Após 4 anos | Nada. Nenhuma mancha de nenhum tipo. |
Veja a seguir a posição de cada versão do PHP:
| Versão do PHP | Lançado | Fim da vida | Situação (agosto de 2026) |
| 7.4 | Novembro de 2019 | 28 de novembro de 2022 | EOL – sem patches da comunidade |
| 8.0 | Novembro de 2020 | 26 de novembro de 2023 | EOL – sem patches da comunidade |
| 8.1 | Novembro de 2021 | 31 de dezembro de 2025 | EOL – sem patches da comunidade |
| 8.2 | Dezembro de 2022 | 31 de dezembro de 2026 | Apenas segurança (fim da vida útil [EOL] no final de 2026) |
| 8.3 | Novembro de 2023 | 31 de dezembro de 2027 | Somente segurança |
| 8.4 | Novembro de 2024 | 31 de dezembro de 2028 | Suporte ativo até 31 de dezembro de 2026; a partir de então, apenas suporte de segurança |
| 8.5 | Novembro de 2025 | 31 de dezembro de 2029 | Apoio ativo |
Você sabia?: O projeto PHP agora alinha todos os prazos de fim de vida útil (EOL) para 31 de dezembro do ano em questão. O PHP 8.1 foi a primeira versão a se beneficiar do ciclo estendido, com seu EOL adiado de novembro de 2024 para 31 de dezembro de 2025.
O que o Suporte Estendido do PHP realmente oferece
O suporte estendido é propositalmente restrito. Sua função é manter segura uma versão do PHP que chegou ao fim da vida útil (EOL), e não modernizá-la, refatorá-la ou adicionar recursos. Ele fornece os patches de segurança que a comunidade deixou de disponibilizar, de forma que você possa implantá-los sem causar falhas na aplicação que depende exatamente desse ambiente de execução.
Uma visão realista: O suporte estendido não é um passe livre para nunca fazer atualizações. Ele lhe dá tempo para migrar sem pressa. Encare-o como uma pista de decolagem, não como um destino.
Correções de segurança retroativas
O serviço principal é o backporting. Quando uma nova vulnerabilidade CVE é identificada em um ramo do PHP ainda com suporte, o provedor analisa se a versão em fim de vida (EOL) é afetada e, em seguida, aplica a correção ao seu ambiente de execução antigo sem alterar seu comportamento. Você continua no PHP 7.4 ou 8.1, mas a vulnerabilidade é corrigida.
Testes de compatibilidade e implantação sem interrupções
Um patch retroativo ainda precisa preservar a estabilidade do aplicativo. Um bom suporte estendido ao PHP inclui testes de regressão em relação à versão EOL, para que a correção não introduza alterações no comportamento. Dependendo do provedor e da plataforma, os patches são fornecidos como pacotes nativos — RPM ou DEB no Linux — que são instalados por meio do gerenciador de pacotes existente, com instaladores equivalentes para o Windows.
Versão e escopo do sistema operacional
Cada provedor oferece suporte a um conjunto específico de versões do PHP em um conjunto específico de sistemas operacionais. Por exemplo, o Endless Lifecycle Support (ELS) da TuxCare para PHP abrange do PHP 5.2 ao 8.4, aplicando patches de segurança do ELS a cada ramificação assim que ela atinge o fim da vida útil (EOL) – atualmente, da versão 5.2 à 8.1 – no Windows e nas principais distribuições Linux, incluindo AlmaLinux, CentOS, Ubuntu, Debian e Oracle Linux. Se você estiver preso a um ambiente de execução em EOL que não permite uma migração sem complicações, esse tipo de correção apoiada pelo fornecedor é uma das poucas maneiras de sanar as vulnerabilidades CVE sem precisar reformular imediatamente o aplicativo para um ambiente de execução mais recente.
Observação: A atualização do PHP 5.x para o PHP 8.x pode exigir alterações substanciais no código, especialmente para aplicativos que dependem de recursos da linguagem removidos, APIs obsoletas ou frameworks desatualizados.
Riscos de segurança e conformidade decorrentes da execução do PHP em fim de vida útil (EOL) sem suporte estendido
O site carrega, o processo de finalização da compra funciona, os registros parecem estar em ordem. Mas o risco vai aumentando silenciosamente à medida que novas vulnerabilidades (CVEs) são identificadas na sua versão e nunca são corrigidas. “Ainda funciona” é a armadilha.
Um ambiente de execução EOL que funciona bem hoje é também aquele que apresenta a lista mais longa de vulnerabilidades não corrigidas e documentadas publicamente — exatamente o que os invasores procuram.
CVE-s sem correção e exploração ativa
Quando uma versão chega ao fim da vida útil (EOL), as vulnerabilidades recém-divulgadas que a afetam permanecem sem correção por parte do projeto PHP por tempo indeterminado. Os invasores podem identificar quais versões deixaram de receber correções, e os exploits públicos continuam funcionando contra sistemas que nunca receberam um patch retroativo.
O Relatório DBIR 2026 da Verizon revelou que a exploração de vulnerabilidades é agora o principal vetor de acesso inicial para violações, representando 31% dos casos, um aumento em relação aos 20% registrados no relatório do ano anterior. É a primeira vez, nos 19 anos de história do relatório, que a exploração de vulnerabilidades ocupa o primeiro lugar, à frente do uso indevido de credenciais e do phishing. Os CVEs reais do PHP comprovam isso: veja a análise sobre uma vulnerabilidade do PHP 7 após o fim do suporte (EOL) do PHP 7 (CVE-2023-0568), e a CVE-2024-4577, uma falha de injeção de argumento CGI com classificação CVSS 9,8 que entrou no catálogo de Vulnerabilidades Exploradas Conhecidas da CISA e afetou fortemente as implantações do PHP no Windows. O padrão mais amplo é abordado nesta visão geral das vulnerabilidades do PHP. Sem um código-fonte retroportado, a atualização costuma ser a única maneira confiável de eliminar a falha subjacente.
Incumprimento das normas
As estruturas de segurança e conformidade geralmente exigem que as organizações identifiquem vulnerabilidades, gerenciem riscos e apliquem atualizações de segurança dentro de um prazo definido. O PCI DSS estabelece requisitos explícitos para a aplicação de patches e o gerenciamento de vulnerabilidades, enquanto a HIPAA, SOC 2e FedRAMP chegam à mesma conclusão por meio da análise de riscos e da avaliação de controles. Executar um software que não recebe mais correções do desenvolvedor torna mais difícil cumprir essas obrigações, a menos que você tenha uma fonte documentada de patches retroativos e provas que comprovem isso.
De acordo com Relatório da IBM sobre o Custo de uma Violação de Dados de 2026, o custo médio global de uma violação aumentou 12% em relação ao ano anterior, atingindo o valor recorde de US$ 4,99 milhões. O suporte estendido pode fornecer os registros de patches e os cronogramas de correção que comprovam uma avaliação de vulnerabilidades e um processo de aplicação de patches. Ambientes regulamentados trazem obrigações adicionais além disso – conformidade com a FIPS para módulos criptográficos validados, por exemplo –, mas, especificamente no que diz respeito à aplicação de patches, é muito mais fácil apresentar um histórico impecável quando os patches realmente existem.
Cadeia de suprimentos e exposição a dependências
O PHP raramente funciona sozinho. Seu aplicativo utiliza pacotes do Composer, extensões e um sistema operacional subjacente, e uma vulnerabilidade em qualquer camada se torna um problema para você. Um ambiente de execução do PHP em fim de vida útil (EOL) geralmente coexiste com um sistema operacional em fim de vida e dependências desatualizadas, multiplicando a superfície de ataque.
Quais versões do PHP exigem suporte estendido atualmente?
Se você estiver usando o PHP 8.1 ou uma versão anterior e não puder atualizar imediatamente, precisará de uma fonte confiável de patches de segurança retroativos. A partir de 2026, essas versões não receberão mais nenhum patch de segurança da comunidade; portanto, as vulnerabilidades recém-divulgadas que as afetem não serão corrigidas pelo projeto PHP.
O PHP 7.4 é o caso mais urgente. Essa versão atingiu o fim da vida útil (EOL) em novembro de 2022, portanto, já se passaram quase quatro anos sem patches da comunidade. Ela ainda está em execução em um grande número de ambientes de produção, pois a migração pode envolver um trabalho substancial relacionado a dependências, compatibilidade e testes. A mesma situação se aplica ao PHP 8.0, que chegou ao fim da vida útil (EOL) no final de 2023, e o PHP 8.1 entrou nessa lista no final de 2025.
O PHP 8.2 e o 8.3 estão no modo “somente segurança”, ainda recebendo correções, mas com um prazo contado. O PHP 8.2 chega ao fim de vida útil (EOL) em 31 de dezembro de 2026, e o PHP 8.3 segue um ano depois. Anote a data de EOL do PHP 8.2 em seu calendário: após 31 de dezembro de 2026, o projeto PHP não lançará mais patches de segurança para essa versão. Para uma análise completa dos riscos e das suas opções, consulte o guia de EOL do PHP 8.2 aborda o assunto em detalhes.
O PHP 8.4 e o 8.5 são as duas versões que contam com suporte ativo atualmente, e a versão 8.4 passará a ter apenas suporte de segurança no final de 2026. O suporte estendido é destinado a equipes que não conseguem migrar das versões 7.4, 8.0 ou 8.1 dentro do prazo exigido por seus auditores ou equipes de risco.
Suporte estendido ao PHP x atualização: como escolher
A atualização é a solução correta a longo prazo. O suporte estendido é a solução correta a curto prazo quando atualizar agora seria imprudente. A decisão depende da quantidade de trabalho de migração necessária para chegar a uma versão com suporte e do nível de risco que você está assumindo nesse meio tempo.
Um aplicativo bem mantido pode migrar do PHP 8.1 para uma versão atualmente suportada com um trabalho limitado em relação a dependências e recursos obsoletos, embora o esforço dependa de suas estruturas, extensões e cobertura de testes. Migrar um aplicativo legado da versão 7.4, com 200 mil linhas de código inalteradas e dependências abandonadas, para o PHP 8.4 é um projeto, não algo que se faz em uma tarde. O custo de subestimar essa lacuna é real.
Da linha de frente: Uma atualização única não resolve os riscos do ciclo de vida de forma permanente. As equipes que migraram da versão 7.4 para a 8.0 há anos, consideraram o trabalho concluído e nunca planejaram o próximo passo, agora se encontram em outro ramo com fim de vida útil (EOL). “Já fizemos uma atualização” é como você acaba enfrentando o fim de vida útil duas vezes.
Use isso para decidir:
| Cenário | Abordagem recomendada |
| Na versão 8.1, dependências modernas, base de código compacta | Atualize agora para uma versão com suporte ativo, de preferência o PHP 8.4 ou 8.5 |
| Na versão 7.4 ou 8.0, um grande aplicativo legado, sem cobertura de testes | Suporte estendido e, em seguida, migração em fases |
| Prazo rígido para a auditoria, migração ainda não concluída | Suporte estendido para garantir a conformidade durante a migração |
| Aplicativo de terceiros que o fornecedor não atualizou | Suporte estendido até que o fornecedor lance uma correção |
Os 3 principais provedores de suporte estendido para PHP
Alguns fornecedores aplicam correções de segurança retroativas ao PHP em fim de vida útil (EOL). Eles diferem quanto às versões abrangidas, à forma como os patches são fornecidos e à documentação de conformidade que disponibilizam. Aqui estão três opções que vale a pena comparar. As listas de cobertura abaixo refletem as informações publicadas por cada fornecedor em agosto de 2026; confirme o escopo atual com o fornecedor antes de comprar.
TuxCare
Suporte de ciclo de vida ilimitado da TuxCare para PHP abrange as versões do PHP 5.2 a 8.4 a partir de um único repositório, com patches de segurança ELS aplicados a cada ramificação à medida que ela atinge o fim do ciclo de vida (EOL) – atualmente, da versão 5.2 à 8.1, com as versões 8.2, 8.3 e 8.4 a serem incluídas à medida que suas datas de EOL chegarem. Os pacotes são compilados pelo fornecedor e recebem correções de segurança para Windows e as principais distribuições Linux; passam por testes de regressão antes do lançamento e são instalados por meio do seu gerenciador de pacotes existente, sem exigir a troca do ambiente de execução ou a recompilação do seu aplicativo.
Para equipes que gerenciam vários sites PHP por meio do cPanel, o PHP ELS da TuxCare se integra ao PHP Selector em ambientes cPanel compatíveis, permitindo que você defina as versões do PHP site a site a partir da interface administrativa, sem precisar recorrer à linha de comando.
Zend da Perforce
A Zend oferece suporte comercial ao PHP há anos e disponibiliza ambientes de execução com suporte de longo prazo para versões em fim de vida útil (EOL), com o respaldo de um fornecedor com longa trajetória no ecossistema do PHP. A cobertura é direcionada: atualmente, a Zend inclui o PHP 7.2, 7.3, 7.4 e 8.1 em sua oferta PHP LTS. É uma opção confiável para equipes que já adotaram as ferramentas da Zend ou o Laminas.
HeroDevs
A HeroDevs oferece suporte de longo prazo para PHP por meio de uma parceria com a Zend by Perforce, combinando os ambientes de execução do ZendPHP com sua própria assinatura “Never-Ending Support”, acordos de nível de serviço (SLAs) e documentação de conformidade. A cobertura abrange as versões PHP 7.2, 7.3, 7.4, 8.0, 8.1 e 8.2, fornecidas como pacotes nativos nas principais distribuições Linux e no Windows.
Aplique as correções de fim de vida útil (EOL) do PHP, evite riscos de segurança e mantenha a conformidade
O PHP em fim de vida útil (EOL) não avisa com antecedência. Ele continua atendendo ao tráfego até que um invasor explore uma vulnerabilidade documentada publicamente que nunca foi corrigida no seu branch. O suporte estendido ao PHP preenche essa lacuna: você permanece no ambiente de execução do qual sua aplicação depende, as vulnerabilidades cobertas recebem correções retroativas e você migra quando for seguro, em vez de quando for forçado a fazê-lo.
Se você estiver usando o PHP 7.4, 8.0 ou 8.1 e uma atualização imediata não for viável, proteja o ambiente de execução existente com patches retrocompatíveis enquanto planeja a migração. O Endless Lifecycle Support (ELS) da TuxCare atualmente abrange todas as versões com fim de vida útil (EOL), da 5.2 à 8.1, e tem o compromisso de estender essa mesma cobertura às versões 8.2, 8.3 e 8.4 à medida que cada uma delas atingir sua data de fim de vida útil.
Perguntas frequentes
Não. O suporte estendido incorpora retroativamente patches de segurança à sua versão atual. Seu PHP permanece com o mesmo número de versão e mantém o mesmo comportamento esperado, enquanto as vulnerabilidades cobertas recebem correções incorporadas retroativamente. O aplicativo que depende desse ambiente de execução pode continuar funcionando sem a necessidade de atualização de versão.
O “Suporte Estendido ao PHP Nível 1” é uma designação de cobrança do provedor de hospedagem, e não um nível padrão de suporte ao PHP. Nos planos de Hospedagem na Web (cPanel) e Hospedagem na Web Plus da GoDaddy, o Suporte Estendido ao PHP é um complemento pago — oferecido por meio de uma parceria com a CloudLinux — que fornece patches de segurança para sites que ainda executam uma versão do PHP fora de suporte (EOL), e aparece como um item de cobrança na renovação. Consulte a documentação do seu provedor de hospedagem para saber o escopo exato e os preços do seu plano.
Sim. O PHP 7.4 chegou ao fim do ciclo de vida em novembro de 2022, mas fornecedores como a TuxCare continuam oferecendo patches de segurança por meio do suporte estendido ao ciclo de vida. Como a versão 7.4 está fora do ciclo de vida desde 2022, ela continua sendo um dos casos de uso mais importantes do suporte estendido para organizações que ainda não concluíram suas migrações.
Os prazos de entrega de patches variam de acordo com o provedor, assim como o escopo. Verifique três aspectos antes de assinar: um limite de gravidade publicado (a maioria dos provedores se compromete a corrigir CVEs de gravidade alta e crítica, normalmente com pontuação CVSS 7.0 ou superior, e lida com problemas de gravidade média caso a caso), uma meta de tempo de resposta declarada para vulnerabilidades de gravidade alta e um rastreador público de CVEs para que você mesmo possa verificar o status de cada CVE, em vez de confiar cegamente no SLA.
Isso pode ajudar. Os auditores querem comprovar que seu software está atualizado e que existe um processo de aplicação de patches repetível, e o suporte estendido fornece tanto os patches quanto os registros. Por si só, isso não garante a conformidade com o PCI DSS, a conformidade com o SOC 2 nem o sucesso da auditoria — isso depende de todo o seu ambiente de controle.
Isso depende da sua situação inicial. No caso de um grande aplicativo legado com dependências abandonadas, o suporte estendido costuma ser muito mais econômico no curto prazo do que uma migração de emergência. Já para um aplicativo pequeno que está uma ou duas versões atrasado, a atualização direta costuma ser a opção mais vantajosa em termos de custo.
