O problema da vulnerabilidade do Lodash mudou, e sua versão fixada não foi atualizada

Principais conclusões

• O Lodash estava inativo, mas não havia chegado ao fim de sua vida útil, e seu relançamento trouxe novas vulnerabilidades (CVEs) relacionadas a versões fixadas há muito tempo.
• Um único estate pode conter várias versões do Lodash, a maioria delas incorporada de forma transitiva.
• Encontrar uma instância vulnerável é fácil; provar qual caminho de código leva a ela é que dá trabalho.

Ninguém participa de uma reunião de planejamento e decide adotar o Lodash. Ele simplesmente aparece. Um desenvolvedor sênior inclui uma função auxiliar, uma ferramenta de compilação o lista como dependência, uma biblioteca de gráficos três níveis abaixo precisa _.merge, e, de repente, ela vem junto no pacote de todos os aplicativos que você lança. Uma infraestrutura discreta, não uma estrutura que alguém tenha escolhido.

Ele está presente em todos os lugares onde um arquivo JavaScript é executado. Código front-end, serviços back-end, ferramentas de compilação, interfaces de linha de comando (CLIs), scripts de automação e aquele pacote interno abandonado que uma equipe escreveu em 2019 e que ninguém mais abriu desde então. O relatório de 2024 da Sonatype estimou que só o npm registrou 4,5 trilhões de solicitações de pacotes naquele ano, e o Lodash é um dos pacotes mais utilizados nessa enxurrada.

Então veio a mudança que nem as notas de lançamento nem a maioria das retrospectivas registraram. A versão 4.17.21 foi lançada em fevereiro de 2021 e, durante anos, nada mais aconteceu. As equipes interpretaram o silêncio como estabilidade, fixaram a versão e seguiram em frente.

Essa interpretação estava errada. A ausência de alertas nunca foi indício de segurança. Isso dizia pouco sobre a exposição real, e isso ficou claro assim que o projeto retomado começou a dar conta do acúmulo de questões de segurança.

O Lodash ainda recebe atualizações?

Sim, mais uma vez, depois de um longo intervalo. O Lodash ficou praticamente inativo por anos e, em 2025, voltou a ser gerenciado ativamente. Os alertas que se seguiram em 2026 são o motivo pelo qual os pinos antigos começaram a acender.

O Lodash surgiu como um fork do Underscore em 2012, e seu criador passou pelas fundações Dojo e jQuery antes de o projeto chegar à OpenJS Foundation, onde agora está em transição para o estágio de maturidade “Feature-Complete”. É mais fácil acompanhar a história recente por meio de uma linha do tempo.

A reformulação veio acompanhada de uma infraestrutura operacional sólida: um plano de resposta a incidentes, um modelo de ameaças publicado, alertas de segurança no GitHub, varreduras com o CodeQL, o Renovate para atualizações de dependências, um quadro de resultados do OpenSSF e uma infraestrutura de integração contínua (CI) reconstruída.

Você sabia? O aviso 4.17.23 foi registrado por meio da Autoridade de Numeração CVE do OpenJS. Essa foi a primeira versão de segurança do Lodash em vários anos, e esse tipo de divulgação coordenada é a marca registrada de um processo de segurança em pleno funcionamento, e não de um processo inativo.

Aqui está o ponto importante para quem ainda usa código antigo. Essa gestão renovada garante que a linha de versões atual seja mantida e protegida. Isso não significa que alguém esteja adaptando novas correções para a versão 3.10.1.

O que um projeto reativado faz com uma versão fixada

O mecanismo é simples e implacável. Um novo aviso pode colocar um marcador inalterado dentro de um intervalo afetado recém-identificado, sem que ninguém altere seu código. Seu número de versão não mudou. O que mudou foi o perfil de risco conhecido.

Três revelações deixam isso bem claro.

Poluição causada por protótipos em _.unset e _.omit foi corrigida na versão 4.17.23. O CVE-2025-13465 abrange as versões 4.0.0 a 4.17.22; portanto, uma versão com cinco anos de idade, a 4.17.21, se enquadra perfeitamente nesse intervalo.

Uma falha que contornava essa correção foi registrada como CVE-2026-2950. O patch da versão 4.17.23 protegia segmentos de caminho em strings, mas não aqueles contidos em matrizes, de modo que o mesmo ataque de exclusão continuava possível. O Lodash 4.17.23 e versões anteriores foram afetadas, e a correção foi implementada na versão 4.18.0.

Injeção de código em _.template por meio dos nomes-chave das importações, CVE-2026-4800, decorre de uma correção incompleta para o CVE-2021-23337 anterior. O patch original validava a variável `option`, mas não os nomes das chaves de importação, e ambos os caminhos levam ao mesmo Function() falha. Ela afeta as versões 4.0.0 a 4.17.23 e foi corrigida na linha 4.18.

A seleção da versão aqui não é automática. A versão 4.18.0 apresentou uma regressão na compilação modular, e o npm agora a marca como obsoleta com um aviso que diz: “Versão com falha. Use [email protected] em vez disso.” Isso leva as pessoas diretamente de volta a uma versão afetada por todas as três CVEs mencionadas acima. A 4.18.1 é a versão que você realmente deseja. Algumas das funções únicas lodash.* os pacotes também foram regenerados na nova linha. lodash.unset agora está na versão 4.18.0, enquanto outros, como lodash.merge permanecem congeladas na versão 4.6.2 de 2019; portanto, projetos mais antigos que incluem essas compilações precisam verificar cada uma delas individualmente.

Atenção: um resultado verde na verificação do “lodash 4.17.21” de 2024 não permanece verde — os alertas publicados em 2026 se aplicam retroativamente a essa versão específica, e nada no seu arquivo de bloqueio indicará isso até que você faça uma nova verificação.

Imagine um console de administração do Angular da época de 2018 com o lodash 3.10.1 no pacote e lodash.merge atraído por duas bibliotecas de gráficos abandonadas. Não há nada de errado no relatório do scanner, nem nada nele que exija ação. É nessa lacuna entre o que é preciso e o que é útil que o verdadeiro trabalho começa.

A poluição de protótipos mudou a forma como as equipes encaram as bibliotecas de utilitários

Um auxiliar de string puro que transforma o texto em maiúsculas não ultrapassa o mesmo limite de segurança. Uma função que mescla objetos ou atribui um valor a um caminho, sim, e essa diferença é o que importa. A mesclagem de objetos e a atribuição de valores a caminhos escrevem em estruturas nas quais seu código confia posteriormente, o que representa um risco _.capitalize nunca chega nem perto.

O modo de falha não é nada incomum. Insira uma chave criada propositalmente, como __proto__ ou constructor.prototype em um “merge” ou “path setter” vulnerável, e você pode acessar os protótipos compartilhados dos quais os objetos comuns herdam, começando por Object.prototype. No caso mais leve, ocorre uma negação de serviço quando o código a jusante fica travado devido a um objeto corrompido. No caso mais grave, com o destino adequado, como um mecanismo de modelos ou um Function() Na chamada, a poluição de protótipos se torna um ponto de entrada para a execução de código. Uma ressalva em relação a esses alertas específicos do Lodash: o _.unset e _.omit Essas falhas permitem a exclusão de propriedades de protótipos compartilhados, em vez de sobrescrevê-las; portanto, o impacto real é a quebra do sistema e a negação de serviço, e não a clássica cadeia de poluição levando à execução remota de código (RCE).

A precisão é importante, no entanto. Nem toda chamada a uma função afetada é passível de exploração. O fator decisivo é se um invasor pode influenciar o objeto mesclado ou o caminho da chave. Se ambos forem totalmente controlados pelo desenvolvedor e não puderem ser acessados por entradas não confiáveis, o risco de exposição é baixo. Se qualquer um deles puder ser influenciado pelo corpo de uma solicitação, por uma string de consulta ou por um arquivo analisado, trate o caminho como potencialmente explorável até que você tenha descartado essa possibilidade. Essa distinção é o que diferencia um plano de correção de uma simples lista de CVEs que indica que tudo está em risco.

O gráfico de dependências é o verdadeiro projeto de correção

Encontrar uma cópia vulnerável do Lodash pode ser uma questão de uma única verificação. Decidir o que fazer a respeito, porém, leva muito mais tempo. O relatório “Snyk State of Open Source Security” de 2022 constatou que, em média, um aplicativo em desenvolvimento apresenta 49 vulnerabilidades distribuídas por 69 dependências, e bibliotecas utilitárias como o Lodash são exatamente o tipo de dependência que se encontra em várias camadas de profundidade.

O trabalho em si é bastante concreto. Comece identificando a dependência principal que introduz cada versão do Lodash e, em seguida, determine se a deduplicação é realmente segura ou se dois usuários realmente precisam de versões principais diferentes. Decida se as substituições ou resoluções são sustentáveis ou se são apenas dívida adiada. Teste separadamente as cópias incluídas no pacote e as do lado do servidor, pois elas são resolvidas de forma independente. Em seguida, procure por compilações codificadas diretamente ou copiadas manualmente que o npm não consegue detectar de forma alguma.

O Lodash é fornecido sem nenhuma dependência de tempo de execução própria, portanto, a árvore abaixo dele está vazia. O problema é o contrário. O Lodash funciona como uma folha em milhares de outras árvores, e é aí que as cópias se multiplicam. Para as versões compatíveis, o TuxCare ELS pode substituir cópias vulneráveis — diretas e transitivas — por compilações corrigidas, e esse é o objetivo do exercício quando um scanner sinaliza seis versões diferentes em um único repositório.

Na prática: as equipes podem “atualizar o Lodash”, encerrar o ticket e, mesmo assim, falhar na próxima verificação. Elas atualizaram a dependência de nível superior e deixaram intocadas três cópias transitivas na versão 4.17.15, pois uma atualização direta não reescreve o que um pacote filho fixou.

A remoção merece uma observação sincera. O encadeamento opcional, a sintaxe de expansão e os métodos modernos de Array tornaram desnecessários muitos auxiliares do Lodash. A semântica de mesclagem profunda, cloneDeep casos extremos, debounce comportamento e o fp Os módulos são outra história.

O que nos leva à decisão. Se o Lodash estiver presente em apenas algumas chamadas simples, removê-lo costuma ser a opção mais simples. Se _.merge ou _.cloneDeep Se envolver lógica financeira ou de relatórios, trate a remoção como uma mudança de comportamento com seu próprio plano de testes, pois esse tipo de mudança pode passar pela integração contínua (CI) e, em seguida, comprometer um relatório de fim de mês.

Quatro caminhos de remediação

Não existe uma solução única, e fingir o contrário é o que faz com que a correção fique estagnada. Quatro caminhos abrangem as opções realistas, e a maioria das empresas recorre a mais de um.

É nesse último caminho que uma correção do fornecedor ganha seu espaço. O TuxCare ELS for Libraries abrange as versões 1.3.1, 2.4.2, 3.2.0, 3.10.1, 4.5.0, 4.17.4, 4.17.5, 4.17.11, 4.17.15, 4.17.19, 4.17.21 e 4.18.1; assim, a versão da qual você não pode migrar ainda recebe a proteção de segurança proporcionada pela correção do desenvolvedor original.

O mecanismo não tem nada de sofisticado, e é justamente essa a ideia. Você adiciona um alias do npm na sua raiz package.json ao lado de overrides Assim, as cópias transitivas passam a corresponder à compilação corrigida, ou você executa o TuxCare Patcher em um repositório que contém várias dependências cobertas. Essa é a resposta direta para o problema das cópias transitivas.

Dica de quem conhece: Declarar overrides na raiz package.json, pois o npm ignora as substituições declaradas dentro das dependências instaladas. Defina-as para a versão corrigida com alias, de modo que o npm resolva as ocorrências correspondentes do nome do pacote vulnerável, direcionando-as para a versão substituta mantida em toda a árvore de dependências.

Como a TuxCare protege as versões mais antigas do Lodash

Aplicar uma correção retroativamente a uma biblioteca de utilitários com uma década de idade não é uma simples questão de copiar e colar, e tratá-la dessa forma é o que leva à quebra justamente dos casos extremos dos quais as aplicações dependem. O processo ocorre em quatro etapas.

Primeiro, analise se cada nova divulgação realmente atinge uma versão abrangida, em vez de presumir que um intervalo de versões publicadas descreva a vulnerabilidade em todos os aplicativos. Segundo, adapte a intenção de segurança sem introduzir mudanças comportamentais não relacionadas. Essa moderação é mais importante aqui do que em quase qualquer outro lugar, pois os aplicativos dependem do comportamento do Lodash em casos extremos, que uma refatoração bem-intencionada poderia alterar discretamente.

Em terceiro lugar, realize testes de regressão tanto nas funções comuns quanto nos caminhos específicos afetados, para que uma correção de “poluição de protótipos” não altere o que _.merge retorna um objeto aninhado válido. Em quarto lugar, assine todos os pacotes criados e publique os documentos SBOM e VEX junto com cada lançamento, para que seus auditores tenham uma proveniência verificável, em vez de apenas uma promessa.

Trata-se de um trabalho de manutenção, não de inovação no upstream, e essa distinção é deliberada. A TuxCare é especializada em manter o código de produção seguro e estável depois que as prioridades do upstream são deixadas de lado, com correções previsíveis e que priorizam a compatibilidade para sistemas que devem permanecer em operação por anos.

Quem pagou pela reestruturação do Lodash e por que o modelo é importante

O Lodash é o exemplo mais claro de um padrão que merece ser destacado. O financiamento da Sovereign Tech Agency, administrado com o apoio da OpenJS Foundation, custeou os trabalhos de governança e segurança de uma biblioteca da qual dependem milhões de sistemas, e vale a pena ler o artigo da OpenJS na íntegra.

O que esse financiamento não garante é a manutenção indefinida da versão 3.10.1. Ele fortaleceu o projeto atual; não obrigou os voluntários a fazer o backport de correções para uma versão de 2015, e fingir o contrário é o que leva os mantenedores ao esgotamento.

O Programa de Sustentabilidade do Ecossistema preenche essa lacuna comercialmente, com uma parcela da receita sendo revertida para os projetos participantes. A TuxCare é membro Gold da OpenJS Foundation e uma das fornecedoras do programa, listada ao lado da HeroDevs e da NodeSource na página de fim de vida útil do Node.js.

Vale a pena deixar isso bem claro, pois isso garante a transparência de todos. Um patch de fornecedor para a versão 4.17.21 é um patch de fornecedor, não uma versão do upstream, e boas ferramentas tornam essa origem explícita, em vez de ocultá-la. E quando uma cópia não pode ser atualizada de forma alguma, o ELS para Lodash fornece as correções por meio do npm para a versão que você está realmente executando, pelo tempo que for necessário mantê-la em execução.

Perguntas frequentes

O Lodash chegou ao fim de sua vida útil?

Não. Ele ficou inativo por anos, mas agora está sendo mantido ativamente novamente no âmbito do OpenJS, com uma reformulação da governança que conta com financiamento e uma versão atual na linha 4.18.

A versão 4.17.21 ainda é segura?

Não se refere às vulnerabilidades divulgadas desde o relançamento. Ela se enquadra no escopo afetado por três alertas: CVE-2025-13465 e CVE-2026-2950 (contaminação de protótipos em _.unset e _.omit, incluindo uma solução alternativa à primeira correção) e CVE-2026-4800 (_.template (injeção de código). A atualização para a versão 4.18.1 corrige todas as três vulnerabilidades, assim como uma compilação mantida que inclui correções para cada uma delas.

Devo estar na versão 4.18.1?

Para projetos mantidos ativamente, sim. A versão 4.18.1 é a versão atual e corrige a regressão na compilação modular que estava presente na versão 4.18.0. Se uma versão antiga específica estiver integrada ao seu gráfico, uma alternativa é uma versão corrigida e mantida por meio do Suporte de Ciclo de Vida Infinito da TuxCare.

Será que ainda preciso mesmo do Lodash?

Muitas vezes, não. A sintaxe nativa substituiu muitos dos auxiliares simples, e structuredClone abrange casos comuns de clonagem profunda, embora descarte protótipos de classes e metadados de propriedades, e gere uma exceção ao encontrar valores que não pode clonar, incluindo funções. A fusão profunda, debounce, e o fp O módulo ainda não tem uma alternativa concisa de uma linha.

Antes de encerrar o ticket

“Atualizar o Lodash” não constitui um plano de correção até que todas as cópias acessíveis tenham sido identificadas. É possível acompanhar os alertas atuais relativos a todas as versões abrangidas no rastreador de CVEs da TuxCare.

Resumo

Nome do artigo

Por que o Lodash 4.17.21 não é mais a opção segura | TuxCare ELS

Descrição

O Lodash permaneceu na versão 4.17.21 por cinco anos e, depois, foram lançados novos CVEs. Veja onde as versões antigas estão e como a TuxCare as corrige.

Autor

Tim Walker

Nome da editora

TuxCare

Logotipo da editora