O fim do suporte ao Express.js e as APIs que não podem simplesmente seguir em frente

Principais conclusões

• O Express 4 está em fase de manutenção desde abril de 2025, com o fim da vida útil (EOL) previsto para outubro de 2026.
• Apenas a versão mais recente de uma linha principal recebe correções; portanto, as versões secundárias 4.x fixadas não são contempladas.
• O Express 3 deixou de receber suporte em julho de 2015, e nada nele foi corrigido desde agosto daquele ano.
• O Express 5 requer o Node.js 18 ou uma versão posterior; por isso, a atualização de um framework muitas vezes se torna uma migração de ambiente de execução.

O Express conquistou sua reputação fazendo muito pouco. Roteamento minimalista, um pipeline de middleware e convenções na medida certa para evitar que as equipes discutissem sobre a estrutura de pastas. Essa moderação é exatamente o motivo pelo qual tantos serviços acabaram sendo implementados no Express sem que ninguém tivesse tomado uma decisão deliberada a respeito, e por que ninguém volta a analisar o código depois que tudo começa a funcionar.

É assim que uma API de pagamentos acaba rodando o Express 4.17.1 sem alterações por sete anos, até que um verificador de dependências a sinalize. Nada mudou no código. O que mudou foi tudo ao redor dele.

A contradição está em duas afirmações. O site do Express informa que a linha 4.x ainda conta com suporte. Seu verificador de dependências indica que o serviço está vulnerável. Ambas as afirmações estão corretas ao mesmo tempo, pois o suporte à linha 4.x não é a mesma coisa que o suporte a todas as versões históricas da linha 4.x.

Isso não é negligência. É longevidade. O DBIR 2026 da Verizon constatou que a exploração de vulnerabilidades é agora a forma mais comum de início de violações, representando 31% dos acessos iniciais — um aumento em relação aos 20% do ano anterior e, pela primeira vez nos 19 anos de história do relatório, à frente do uso indevido de credenciais. O tempo médio para a correção completa passou de 32 para 43 dias no mesmo período. Os sistemas vulneráveis tendem a ser aqueles que funcionam bem o suficiente para que ninguém sinta qualquer urgência em relação a eles.

O Express 4 chegou ao fim de sua vida útil?

Resposta curta: não. O Express 4 não está em fim de vida útil (EOL) até agosto de 2026, e a linha 4.x ainda está lançando novas versões. A resposta mais detalhada é que o prazo já começou a correr, e que a versão principal não indica se a versão fixada no seu arquivo de bloqueio está recebendo correções.

Durante a maior parte de sua existência, o Express não possuía nenhum cronograma de LTS. Isso mudou em março de 2025, quando o projeto publicou uma estratégia de LTS e, ao mesmo tempo, tornou a versão 5.1.0 a padrão no npm. As versões principais agora passam pelas fases CURRENT, ACTIVE e MAINTENANCE. O Express 4 entrou na fase MAINTENANCE em 1º de abril de 2025, o que significa que serão disponibilizados apenas patches de segurança e correções de bugs de alta prioridade, com o fim da vida útil (EOL) previsto para, no mínimo, 1º de outubro de 2026. O projeto se refere a essas metas como “objetivos” em vez de “compromissos” e destaca a v4 como um caso especial que pode ser prorrogado, mas a direção a seguir não deixa margem para dúvidas.

Enquanto isso, a página oficial de suporte ainda lista as versões 4.x e 5.x como “em andamento”, sem data de término, ao lado da versão mínima do Node.js e da data de início do suporte para cada versão principal. Os dois documentos apresentam informações contraditórias, o que constitui uma resposta embaraçosa para um auditor que pergunte quando seu framework deixará de receber suporte.

A regra que realmente importa é uma linha na parte superior dessa página de suporte. Apenas a versão mais recente de cada linha de lançamento principal recebe suporte. A página de atualizações de segurança, por sua vez, detalha quais vulnerabilidades foram corrigidas em cada lançamento, versão por versão. Quando lidas em conjunto, essas informações revelam algo que o número da versão por si só não indica: estar em uma linha de lançamento principal com suporte não é o mesmo que estar em uma versão com suporte.

Essa distinção é o que determina se uma constatação de auditoria é encerrada ou permanece em aberto. O fato de a versão 4.x ainda estar em uso não diz nada sobre a 4.17.1, pois as correções são aplicadas à versão mais recente da série 4.x, e não à versão secundária que foi fixada em 2019. Se você não conseguir indicar a versão exata no seu arquivo de bloqueio, ainda não sabe se o seu sistema é compatível. Descubra isso antes de discutir com o scanner.

A cápsula do tempo do middleware

O Express, por si só, é pequeno. O que torna um serviço antigo baseado no Express frágil são todos os componentes acoplados a ele – analisadores de corpo de mensagem, armazenamentos de sessão, estratégias de autenticação, mecanismos de modelos e middleware personalizado, escritos há anos por pessoas que já não estão mais na empresa e que não documentaram nada disso.

A simples atualização do Express cria uma falsa sensação de que o problema foi resolvido. Mesmo após atualizar a estrutura e ver o aviso de nível superior ser removido, um pacote transitivo vulnerável ainda pode estar presente um nível abaixo, sem ter sido alterado.

O Express 4 declara cerca de 30 dependências diretas, incluindo qs, body-parser, send, serve-static, path-to-regexp, proxy-addr, e forwarded, com uma árvore de dependências mais ampla por trás delas. Ninguém escolheu essas bibliotecas. Elas vêm junto com o Express, e uma vulnerabilidade em qualquer uma delas se torna uma vulnerabilidade em seu aplicativo sempre que o caminho de código afetado for acessível. Quatro CVEs de 2024 mostram como isso ocorre.

O problema é que a versão 4.19.2 foi a que corrigiu o redirecionamento aberto, mas ainda é anterior a todas as versões lançadas depois dela. Um aplicativo que ainda esteja na versão 4.19.2 já está livre da vulnerabilidade CVE-2024-29041, mas ainda apresenta a vulnerabilidade XSS e as duas vulnerabilidades ReDoS relacionadas a expressões regulares de caminho, pois essas correções foram implementadas em versões posteriores da linha 4.x. Vale ressaltar também que a correção da vulnerabilidade de redirecionamento aberto exigiu três tentativas: uma correção inicial na versão 4.19.0, uma regressão corrigida na 4.19.1 e a contornagem devidamente tratada na 4.19.2; portanto, qualquer versão anterior à 4.19.2 não está totalmente corrigida para essa vulnerabilidade.

Aviso: Antes de fazer a triagem, execute npm ls path-to-regexp qs send com a árvore de dependências que seu aplicativo realmente distribui e compare as versões resolvidas com seu arquivo de bloqueio. Uma cópia fixada transitivamente, incorporada por alguma outra dependência, pode deixá-lo vulnerável mesmo quando o próprio Express estiver atualizado.

Vale a pena ter em mente uma ressalva. “Afetado” não significa “explorado”. O fato de uma descoberta ser considerada um incidente ou apenas um item na lista depende de sua aplicação realmente expor o caminho de código vulnerável a entradas controladas por invasores.

Essa lacuna é justamente o que as atualizações de segurança oferecidas pelos fornecedores para software de código aberto visam preencher. A cobertura da TuxCare para o Express abrange os componentes suportados que vêm junto com uma versão coberta, em vez do nível superior express apenas esse pacote, que é a diferença entre corrigir uma falha e adiá-la. Uma pesquisa realizada por Endor Labs estima que cerca de 95% das vulnerabilidades de código aberto estejam em dependências transitivas, e não naquelas escolhidas diretamente pelos desenvolvedores, e que uma implantação legada raramente tenha a opção de simplesmente migrar para o ramo em que a correção foi implementada. A TuxCare’s Rastreador de CVE mostra o status do patch por versão, para que você possa ver de que lado dessa linha você está.

O Express 5 vem acompanhado do Node.js

O que acaba ficando de fora quando a “atualização para o Express 5” é incluída no orçamento é que o Express 5 requer o Node.js 18 ou uma versão posterior. Uma atualização do framework acaba se transformando em uma migração do ambiente de execução, acompanhada da atualização do framework.

O Express 5 também alterou comportamentos nos quais aplicativos mais antigos dependiam de forma implícita. Promessas rejeitadas e erros gerados por manipuladores assíncronos agora são encaminhados automaticamente para o middleware de tratamento de erros. Um conjunto de assinaturas obsoletas foi removido, incluindo res.send(body, status) e a string mágica “back” em res.redirect. A correspondência de rotas foi transferida para a versão 8 do `path-to-regexp`, que removeu as expressões regulares de subexpressões das cadeias de caracteres de caminho como medida de mitigação contra ReDoS; portanto, as rotas que dependem desses padrões precisam ser reescritas.

Imagine um serviço interno de reclamações que ainda esteja padronizado em uma imagem de contêiner da era do Node 14. A atualização do Express de 4 para 5 é a parte fácil. O difícil é migrar essa imagem para uma versão do Node.js atualmente suportada, que já atenda aos requisitos mínimos do Express 5, sem causar incompatibilidade com os módulos nativos compilados com a ABI mais antiga.

O próprio guia de migração da Express deixa claro que um aplicativo da v4 pode não funcionar sem alterações na v5, e essa abordagem é útil. Isso faz com que o problema seja, antes de tudo, uma questão de tempo de execução e testes, e só depois um problema da estrutura.

Conselho de especialista: Antes de atualizar o Express, execute seu conjunto de testes atual na versão do Node.js que você realmente pretende implantar. Algo tão simples quanto nvm use <target> && npm test revelará falhas nos módulos nativos e na ABI que não têm nada a ver com o Express.

Três caminhos viáveis e quanto custa cada um deles

Não há uma resposta universal para isso; existe apenas aquela que se adapta ao seu gráfico de dependências, à sua cobertura de teste e ao seu ambiente de execução. Três abordagens abrangem a maioria das situações.

Mudar para o Express 5

Essa é a opção quando a árvore de dependências está organizada e os testes de integração são confiáveis. Atualize o ambiente de execução, atualize o Express, analise o tratamento de erros assíncronos e os padrões de roteamento, e veja a CI passar para o verde. A mudança de framework pode facilmente ser a parte mais simples do trabalho.

Continue usando a versão 4.x e acompanhe o lançamento mais recente

É uma opção viável para aplicativos que se limitam ao roteamento convencional e ao middleware mais comum, embora o prazo esteja se esgotando. Acompanhe a versão mais recente da série 4.x, atualmente a 4.22.2, e trate isso como rotina, e não como algo pontual. Além disso, não é gratuito. Em 1º de dezembro de 2025, o Express lançou uma alteração no analisador de consultas em ambas as linhas em produção, referente ao que havia sido registrado como CVE-2024-51999. O CVE foi então rejeitado por não se tratar de uma vulnerabilidade, e as versões 4.22.1 e 5.2.1 reverteram a alteração na mesma noite, cerca de quatro horas após o lançamento das versões originais. Mesmo assim, o problema não foi resolvido, já que a versão 4.22.2, em maio de 2026, teve que restaurar o comportamento de análise de matrizes para chaves de consulta repetidas. Manter-se atualizado significa lidar com isso. Permanecer em uma versão principal com suporte só ajuda enquanto você acompanha a linha de desenvolvimento; no momento em que você fica estagnado em uma versão 4.x mais antiga, volta à mesma situação de qualquer sistema fixado na versão 4.17.1.

Suporte prolongado enquanto a migração é agendada

Isso deixa os casos que os dois primeiros não abrangem – um ambiente de execução do Node.js travado, um middleware de autenticação personalizado ou uma migração que realmente se estende por vários trimestres. Uma API regulamentada com uma camada de autenticação sob medida e um ambiente de execução fixado pode facilmente exigir mais do que um ou dois sprints, e apressar o processo só porque um scanner ficou vermelho é o que leva a interrupções no serviço. O TuxCare ELS abrange versões específicas do Express, incluindo 3.4.8, 3.21.2, 4.17.1, 4.18.1, 4.18.2, 4.18.3 e 4.19.2, distribuídas como scoped @els-js pacotes por meio de um repositório autenticado da TuxCare.

A versão resumida. Um gráfico claro e testes nos quais você confia apontam para o Express 5. O roteamento convencional e o middleware padrão indicam que é melhor acompanhar a versão mais recente da série 4.x e permanecer nela. Um ambiente de execução congelado ou uma migração que se estende por vários trimestres indicam um suporte prolongado que é planejado, em vez de indefinido, o que é ainda mais importante agora que a série 4.x tem uma data prevista para o fim da vida útil (EOL).

Como a TuxCare oferece suporte ao Express fora do período de suporte

O suporte estendido a uma biblioteca não é um trabalho glamoroso, e esse é justamente o ponto. Ele começa com o monitoramento de vulnerabilidades em toda a versão do Express abrangida e nos componentes suportados que vêm junto com ela. A primeira pergunta ao surgir qualquer nova divulgação é se ela realmente afeta essa versão ou se diz respeito apenas a caminhos de código introduzidos posteriormente.

Quando é necessário um patch, a abordagem é o backporting disciplinado. Adote a alteração relevante para a segurança da correção do upstream, descarte a refatoração não relacionada que veio junto com ela e evite incluir uma atualização de framework que ninguém havia planejado. O resultado passa por testes de regressão em relação ao comportamento legado antes de ser lançado como um pacote mantido, com dados de SBOM e VEX publicados junto com ele. Essas evidências legíveis por máquina são o que permitem que uma equipe de segurança documente uma descoberta adequadamente, em vez de adiá-la para o próximo trimestre. Trata-se de especialização, e não de uma substituição do upstream, o que significa manutenção de longo prazo de ramificações que o projeto já deixou para trás, com testes de compatibilidade antes de qualquer lançamento.

As equipes de conformidade sempre perguntam sobre os prazos, então aqui estão as metas publicadas. Vulnerabilidades altas e críticas, ou seja, com pontuação CVSS 7.0 ou superior, têm uma meta de tempo de resposta de 14 dias a partir da divulgação pública; vulnerabilidades médias, de 60 dias; e vulnerabilidades baixas, de 90 dias. As versões abrangidas e as etapas de instalação estão disponíveis na documentação do TuxCare ELS for Express, com uma visão mais ampla na seção de suporte ao fim da vida útil (EOL) da biblioteca.

O papel da sustentabilidade no OpenJS

O Express é um Projeto Impact da Fundação OpenJS, e isso é importante porque a Fundação oferece uma estrutura oficial para o suporte comercial a versões arquivadas, em fim de vida útil e mais antigas dos projetos. O Programa de Sustentabilidade do Ecossistema OpenJS foi lançado em maio de 2024 para conectar provedores comerciais a essas versões, sendo que os parceiros repassam uma parcela da receita empresarial aos projetos participantes.

A TuxCare está listada como parceira do ESP ao lado da HeroDevs e da NodeSource, e o programa exige que os parceiros sejam membros Gold ou Platinum da Fundação. A página de fim de vida útil do Node.js cita esses mesmos três provedores, o que é um forte indício de que se trata de um modelo consolidado, e não de uma improvisação.

Vale a pena deixar claras duas restrições. O programa não é exclusivo e está aberto a qualquer provedor que atenda aos requisitos; além disso, ele não impede que os mantenedores publiquem correções públicas para qualquer versão, incluindo aquelas cobertas por um parceiro do ESP. Também é importante saber que a própria página de suporte do projeto Express lista atualmente a HeroDevs como sua opção comercial; portanto, a cobertura para a sua versão específica deve ser confirmada diretamente com o provedor que você estiver avaliando.

Análise da realidade: uma correção retroativa do fornecedor pode sanar as vulnerabilidades abordadas na versão 4.17.1, mas isso não torna a versão 4.17.1 uma versão com suporte do upstream. Se um requisito de conformidade especificar explicitamente o suporte do upstream, a correção do fornecedor responde a uma questão diferente, e vale a pena saber qual é a questão que está sendo feita.

Como avaliar um aplicativo antigo do Express

Antes de escolher um caminho, verifique qual é a sua situação atual. Comece pela versão exata do Express que consta no seu arquivo de bloqueio, em vez do intervalo indicado em package.json. Percorra as dependências diretas e transitivas com npm ls e compare-os com os alertas conhecidos. Faça um inventário do middleware personalizado e de qualquer comportamento não documentado do qual o aplicativo dependa. Determine qual versão do Node.js o aplicativo executa e se esse ambiente de execução ainda recebe suporte, pois isso determina se o Express 5 está, de fato, entre as opções. Em seguida, avalie tudo isso com base na exposição e na importância para os negócios, de modo que a API de pagamentos receba prioridade em relação a um painel interno de baixo tráfego.

Há um aspecto que é fácil deixar passar despercebido. O Express também pode ser incluído de forma transitiva por meio de SDKs, pacotes de middleware e outras dependências; assim, versões que ninguém optou por instalar ainda aparecem no gráfico. Uma avaliação que ignore o status do ciclo de vida e as dependências indiretas resulta em uma lista, em vez de um panorama geral.

Faça a atualização de acordo com um cronograma arquitetônico, e não porque uma divulgação tenha forçado o prazo. O Suporte de Ciclo de Vida Ilimitado existe para proporcionar essa margem de manobra, mantendo a versão em execução atualizada com os patches enquanto a migração ocorre de acordo com um cronograma que você possa testar e controlar.

Resumo

Nome do artigo

Fim da vida útil do Express.js e suporte para versões em fim de vida útil | TuxCare ELS

Descrição

O Express 4 EOL está previsto para outubro de 2026, e apenas sua versão mais recente receberá correções. Compare as opções e o TuxCare ELS.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora