Se o sistema da sua empresa roda em PHP 8.1 ou anterior, Node.js 20 ou anterior, Angular 19 ou anterior, MySQL 8.0, Python 3.10, SQL Server 2016 ou Ubuntu 20.04 sem assinatura de suporte estendido, ele já está em tecnologia sem suporte oficial. Isso significa que novas falhas de segurança descobertas nessas versões não recebem correção do fabricante. Até o fim de 2027, entram na mesma situação o PHP 8.2 e o 8.3, o .NET 8, o PostgreSQL 14, o Windows Server 2016, o Node.js 22 e o Ubuntu 22.04. O caminho seguro é mapear as versões em uso, priorizar o que fica exposto à internet e planejar a atualização antes da data limite.

Este artigo reúne as datas oficiais de fim de suporte, publicadas pelos próprios mantenedores, explica o que muda quando uma tecnologia perde suporte e mostra as opções para quem descobre que está atrasado. O texto foi escrito para gestores, sem exigir conhecimento técnico.

O que significa “fim de suporte” em software

Toda linguagem, framework, banco de dados ou sistema operacional tem um ciclo de vida. Os mantenedores lançam uma versão, corrigem defeitos e falhas de segurança por um período e, depois, deixam de corrigir. A partir desse ponto, a versão continua funcionando, mas qualquer falha nova fica aberta para sempre.

Esse ciclo costuma ter três fases. Os nomes variam entre fabricantes, mas a lógica é parecida.

Os prazos também variam. O PostgreSQL, banco de dados de código aberto, mantém cada versão principal por 5 anos após o lançamento. O .NET, plataforma da Microsoft, dá 3 anos de suporte às versões LTS (de longo prazo) e 2 anos às versões STS (de prazo padrão). O Laravel, framework PHP muito usado no Brasil, corrige defeitos por 18 meses e falhas de segurança por 2 anos. O Ubuntu oferece 5 anos de manutenção de segurança padrão às versões LTS, e a assinatura Ubuntu Pro estende esse prazo para 10 anos.

O ponto central para o gestor é simples: o sistema não “quebra” na data de fim de suporte. Ele continua no ar, o que dá a falsa sensação de que nada mudou. O risco aparece quando uma falha grave é descoberta, e aí não há correção oficial para aplicar.

O calendário de fim de suporte de 2026 e 2027

A tabela abaixo reúne as datas oficiais de fim de suporte das tecnologias mais comuns em sistemas empresariais brasileiros. As datas foram consultadas nas páginas dos próprios mantenedores em outubro de 2026.

Algumas leituras importantes dessa tabela:

• O PHP tem quatro versões com suporte em outubro de 2026: 8.2, 8.3, 8.4 e 8.5. A 8.2 sai de cena em 31 de dezembro de 2026, e a 8.3 em 31 de dezembro de 2027. A 8.4 recebe correções de segurança até o fim de 2028, e a 8.5, até o fim de 2029.
• No Node.js, o projeto informa que as versões LTS recebem correções críticas por cerca de 30 meses e recomenda usar em produção apenas versões LTS ativas ou em manutenção. O Node.js 24 entrou em manutenção em 20 de outubro de 2026 e tem fim de vida previsto para 30 de abril de 2028.
• No Angular, cada versão principal costuma ter 24 meses de suporte: 12 meses ativos e 12 meses só com correções críticas e de segurança. As versões 2 a 19 já não têm suporte.
• No Windows Server 2012 R2, o suporte estendido terminou em outubro de 2023. Desde então, só quem comprou atualizações estendidas (ESU) recebia correções, e o terceiro e último ano desse programa terminou em outubro de 2026.

O que já está sem suporte hoje

Muitos sistemas empresariais foram construídos há cinco ou dez anos e nunca passaram por atualização de base. Nesses casos, o problema não é uma data futura: o suporte já acabou.

O PHP 7.4, por exemplo, perdeu suporte em 28 de novembro de 2022. Um sistema que ainda roda nessa versão está há quase quatro anos sem correções oficiais da linguagem. O PHP 5.6, ainda encontrado em sistemas antigos, perdeu suporte em 31 de dezembro de 2018.

O caso PHP2Shell: o que acontece quando a falha chega

Em outubro de 2026, o PHP passou por um episódio que ilustra bem o risco. O Centro Canadense de Segurança Cibernética publicou, em 21 de outubro de 2026, um alerta sobre duas falhas críticas no PHP, identificadas como CVE-2026-109618 e CVE-2026-109619 e apelidadas de “php2shell”. Segundo o alerta, a exploração bem-sucedida pode permitir que um atacante sem login execute código no servidor.

As correções saíram apenas para as versões com suporte: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O próprio alerta registra que o PHP 8.1 e as versões mais antigas não recebem mais atualizações do projeto PHP. Algumas distribuições e fornecedores de suporte estendido oferecem correções adaptadas, mas isso depende do contrato de cada empresa.

Na prática, o episódio dividiu as empresas em dois grupos. Quem estava em versão suportada precisou apenas aplicar a atualização e reiniciar os serviços. Quem estava em versão antiga passou a ter três opções, todas mais caras: migrar às pressas, isolar o sistema da internet ou contratar suporte de terceiros. O guia da Mind sobre a falha crítica PHP2Shell e como corrigir detalha o passo a passo técnico.

Em 23 de outubro de 2026, o mesmo alerta foi atualizado com uma terceira falha, a CVE-2026-115560, ainda sem correção na data da atualização. Para ela, a recomendação temporária do time de segurança do PHP é desativar o recurso de progresso de upload de sessão. O episódio mostra que uma correção nem sempre encerra o assunto, e que manter versões em dia reduz o tempo de reação.

Quanto da internet ainda roda versões antigas

Os números de uso ajudam a dimensionar o problema. Segundo o W3Techs, que monitora tecnologias de sites, o PHP é usado por 69,3% dos sites cuja linguagem de servidor é conhecida, em dados de 23 de outubro de 2026. Entre os sites em PHP, 26,9% usam a versão 7 e 7,7% usam a versão 5.

Como todas as versões 7 e 5 do PHP já estão fora de suporte, isso quer dizer que mais de um terço dos sites em PHP roda uma versão principal sem correções oficiais. E o número real é maior, porque parte dos 65,3% que usam PHP 8 está nas versões 8.0 e 8.1, também sem suporte.

Esses dados tratam de sites públicos, não de sistemas internos. Ainda assim, a lógica vale para sistemas empresariais: uma vez que o sistema entra em produção, a atualização da base tende a ficar para depois, até que uma falha grave obrigue a agir com pressa.

Como descobrir se o seu sistema está em tecnologia sem suporte

O levantamento pode ser feito pelo time de TI ou pelo fornecedor que mantém o sistema. O gestor não precisa executar os passos, mas deve pedir o resultado por escrito.

1. Liste todos os sistemas em produção, incluindo sites, portais, aplicativos, APIs e rotinas automáticas.
2. Para cada sistema, registre a linguagem e a versão (PHP, Node.js, Python, .NET), o framework (Laravel, Angular, React) e a versão de cada um.
3. Registre o banco de dados e a versão (MySQL, PostgreSQL, SQL Server).
4. Registre o sistema operacional dos servidores e a versão (Ubuntu, Windows Server).
5. Compare cada item com o calendário oficial do fabricante e marque o que já está sem suporte ou perde suporte em até 12 meses.
6. Identifique quais sistemas ficam expostos à internet e quais tratam dados pessoais ou financeiros.
7. Classifique a prioridade cruzando os dois critérios: sem suporte e exposto à internet vem primeiro.
8. Peça ao fornecedor uma estimativa de horas para atualizar cada item prioritário.

Esse inventário também é útil para outras decisões, como cálculo de custo total de propriedade. A metodologia de TCO de software mostra como incluir atualizações periódicas no custo de manter um sistema.

As opções para quem está em versão sem suporte

Não existe uma resposta única. A escolha depende do tamanho do sistema, da quantidade de código que depende da versão antiga e de quanto tempo ele ainda vai ficar em uso.

O suporte estendido pago é real em vários casos. A Microsoft oferece três anos de atualizações de segurança estendidas para o SQL Server 2016, de julho de 2026 a julho de 2029. O Ubuntu Pro estende a manutenção de segurança das versões LTS para 10 anos, e um complemento adicional chega a 15 anos. Essas opções compram tempo, mas não eliminam a necessidade de migrar.

Para sistemas muito antigos, a atualização de versão costuma vir junto com uma modernização mais ampla. O guia sobre modernização de sistemas legados discute quando migrar aos poucos e quando reconstruir.

Quanto custa sair de uma tecnologia sem suporte

O custo depende de quanto o código depende de recursos que mudaram entre as versões e de quanto teste automatizado o sistema já tem. Sistemas com testes são atualizados com mais segurança e menos horas. Sistemas sem testes exigem verificação manual de cada fluxo.

A tabela abaixo traz faixas de referência que a Mind Group usa para orientar conversas iniciais sobre atualização de base tecnológica.

Metodologia: estimativas de referência da Mind Group em 2026, calculadas como horas estimadas multiplicadas pelo valor-hora de R$ 110 a R$ 190, conforme a senioridade do time. A faixa de modernização corresponde à faixa de sistema web sob medida usada pela Mind, e a de sustentação, à faixa mensal praticada. As demais faixas de horas são estimativas para orientar a conversa; o valor final depende do diagnóstico do código e do escopo aprovado.

Exemplo hipotético: uma empresa tem um portal em PHP 7.4 com Laravel antigo, exposto à internet, que recebe pedidos de clientes. Sem atualização, cada nova falha grave na linguagem fica sem correção oficial. Com a faixa de 150 a 500 horas, o investimento estimado fica entre R$ 16,5 mil e R$ 95 mil, conforme o estado do código. Em comparação, o custo de um incidente envolve parada de vendas, investigação, possível comunicação à ANPD e desgaste com clientes.

Para estimativas mais detalhadas, o artigo sobre como estimar projetos de software com precisão explica como transformar um diagnóstico em faixa de horas.

Um plano de 90 dias para sair do risco

Para quem descobriu agora que tem sistemas em tecnologia sem suporte, um plano curto ajuda a organizar as prioridades sem paralisar a operação.

1. Semanas 1 e 2: fazer o inventário de versões de todos os sistemas e servidores.
2. Semanas 2 e 3: classificar cada item por risco, considerando suporte, exposição à internet e dados tratados.
3. Semana 3: aplicar medidas imediatas nos itens críticos, como atualização de correção, firewall de aplicação, restrição de acesso e revisão de credenciais.
4. Semanas 4 a 6: obter estimativas de atualização e decidir entre atualizar, pagar suporte estendido, isolar ou modernizar.
5. Semanas 6 a 12: executar as atualizações prioritárias em ambiente de testes e, depois, em produção, com plano de retorno caso algo falhe.
6. A partir do mês 4: incluir a revisão de versões no contrato de sustentação, com checagem pelo menos semestral do calendário dos fabricantes.

O passo 6 é o que evita a repetição do problema. Quando a revisão de versões faz parte da rotina, cada atualização é pequena e previsível, em vez de um projeto grande feito sob pressão.

Por que isso é também uma questão de LGPD e de contrato

Sistemas que tratam dados pessoais estão sujeitos à Lei Geral de Proteção de Dados. A lei exige que os agentes de tratamento adotem medidas de segurança técnicas e administrativas aptas a proteger os dados. Manter um sistema exposto à internet em versão sem correções de segurança pode ser difícil de justificar diante dessa exigência, especialmente depois de uma falha pública como a de outubro de 2026. A avaliação jurídica de cada caso deve ser feita com um advogado.

Do lado contratual, vale verificar o que o contrato de sustentação diz sobre atualizações de base. Muitos contratos cobrem apenas correção de defeitos e pequenas melhorias, sem prever a atualização periódica de linguagem, framework e servidor. Incluir essa obrigação, com frequência e responsabilidades definidas, reduz a chance de o sistema envelhecer sem que ninguém perceba.

Para um panorama mais amplo dos riscos e das defesas, o guia de cibersegurança para empresas em 2026 e o artigo sobre segurança no desenvolvimento e OWASP Top 10 complementam este calendário.

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.

A frente de cibersegurança atua justamente em situações como a do PHP2Shell: aplica correções, verifica sinais de invasão e ajuda a definir o que fazer com sistemas em versões antigas. Para sistemas que precisam de atualização de base ou modernização, o time de desenvolvimento faz o diagnóstico, estima as horas e executa a migração com entregas a cada duas semanas.

Se a sua empresa quer saber em que situação estão os seus sistemas, o primeiro passo é o inventário de versões. A página de desenvolvimento de sistemas traz mais informações sobre como a Mind trabalha.

Atualizado em outubro de 2026.

Perguntas frequentes

O que acontece se eu continuar usando uma versão sem suporte?

O sistema continua funcionando, mas falhas de segurança descobertas depois da data de fim de suporte não recebem correção oficial. Isso aumenta o risco de invasão, principalmente em sistemas expostos à internet. Também pode dificultar a contratação de seguro cibernético e a defesa em caso de incidente.

Até quando o PHP 8.2 e o PHP 8.3 têm suporte?

Pela página oficial do PHP, o 8.2 recebe correções de segurança até 31 de dezembro de 2026, e o 8.3, até 31 de dezembro de 2027. O 8.4 vai até 31 de dezembro de 2028 e o 8.5, até 31 de dezembro de 2029.

Qual versão do Node.js devo usar em produção?

O projeto Node.js recomenda usar em produção apenas versões LTS ativas ou em manutenção. Em outubro de 2026, isso inclui o Node.js 22 e o 24, e o 26 entra em fase LTS no fim do mês. O Node.js 20 perdeu suporte em 30 de abril de 2026.

Pagar suporte estendido resolve o problema?

Resolve por um tempo. Programas como o ESU da Microsoft ou o Ubuntu Pro continuam entregando correções de segurança por alguns anos. A migração continua necessária, só que com mais prazo para planejar.

Atualizar a versão pode quebrar o sistema?

Pode, porque versões novas removem ou alteram recursos antigos. Por isso a atualização deve ser feita primeiro em ambiente de testes, com verificação dos fluxos principais e plano de retorno. Sistemas com testes automatizados passam por esse processo com mais segurança.

Com que frequência devo revisar as versões dos meus sistemas?

Uma revisão semestral do calendário dos fabricantes é um bom ponto de partida. Ela permite planejar atualizações com pelo menos seis meses de antecedência. O ideal é que essa revisão esteja prevista no contrato de sustentação.

Fontes: PHP: Supported Versions · PHP: Unsupported Branches · Node.js: Previous Releases · Node.js Release Working Group: cronograma · Angular: Versioning and releases · Microsoft: Windows Server 2016 lifecycle · Microsoft: Windows Server 2012 R2 lifecycle · Microsoft: SQL Server 2016 lifecycle · .NET support policy · Ubuntu release cycle · Laravel: Release Notes e política de suporte · Python Developer’s Guide: Status of Python versions · PostgreSQL: Versioning Policy · Oracle MySQL Blog: End-of-Life of HeatWave MySQL 8.0 · Canadian Centre for Cyber Security: alerta AL26-026 sobre PHP · W3Techs: uso de PHP em sites · Lei nº 13.709/2018 (LGPD), Planalto