lodash 4.17.21: O custo oculto de executar dependências legadas de JavaScript

Principais conclusões

• O lodash 4.17.21 não é mais o ponto final seguro que foi considerado por anos e agora apresenta três falhas confirmadas — CVE-2025-13465, CVE-2026-2950 e CVE-2026-4800 — resolvidas apenas na versão 4.17.23 e na linha 4.18.x.
• A parte mais difícil da correção é de natureza organizacional, e não técnica; portanto, mapear os locais reais de chamada, fortalecer a proteção na entrada e monitorar possíveis explorações são as medidas que permitem ganhar tempo quando uma atualização imediata não é viável.
• Correções retroativas, por meio de um serviço como o ELS for Libraries da TuxCare, permitem que as equipes garantam a segurança da versão 4.17.21, que já se mostrou confiável, enquanto planejam uma migração cuidadosa para a versão 4.18.x, em vez de se apressarem em uma migração arriscada.

Sua equipe está ciente das vulnerabilidades. O ticket está aberto há nove meses. Ninguém deu atenção a ele. Este artigo aborda o motivo disso — e o que fazer em vez de ficar esperando.

Existe um tipo específico de vulnerabilidade que não é corrigida. Não porque os engenheiros sejam descuidados, nem porque as equipes de segurança estejam adormecidas — mas porque a correção, embora tecnicamente possível, é operacionalmente assustadora. A versão 4.17.21 do lodash é o exemplo clássico desse padrão em projetos modernos de JavaScript e vem permanecendo em ambientes de produção em todo o setor há anos.

Este artigo não é uma análise detalhada do CVE. Você pode consultar essas informações por conta própria. Trata-se da lacuna entre saber que algo está errado e ser capaz de fazer algo a respeito — e das maneiras práticas pelas quais as equipes lidam com essa lacuna sem fingir que ela não existe.

Como o lodash 4.17.21 chegou até aqui e se manteve

O lodash se tornou um dos pacotes de JavaScript mais baixados da história porque resolveu um problema real: a biblioteca padrão do JavaScript era limitada, inconsistente entre os diferentes ambientes, e a compatibilidade com navegadores era um verdadeiro campo minado. Em seu auge, o lodash era usado em tudo, desde projetos paralelos de startups até plataformas corporativas da Fortune 500.

Então, o JavaScript moderno amadureceu. Os métodos nativos de array foram aprimorados. O ES6 e as versões posteriores incorporaram muitos dos padrões de utilitários que o lodash havia pioneiramente introduzido. Projetos mais recentes passaram a ser lançados sem ele. Mas os projetos existentes — especialmente as bases de código grandes, desenvolvidas ao longo de vários anos — não removeram o lodash de repente. Eles haviam acumulado milhares de chamadas. Refatorá-las era uma tarefa gigantesca, com resultados incertos.

A versão 4.17.21, lançada em fevereiro de 2021 para corrigir uma falha de injeção de comando de alta gravidade no _.template (CVE-2021-23337), juntamente com um problema de negação de serviço relacionado a expressões regulares (CVE-2020-28500), tornou-se a versão fixa de referência para grande parte do ecossistema. E assim permaneceu por quase cinco anos, sem novos lançamentos. Não porque a versão 4.17.21 seja permanentemente segura: uma nova equipe de governança divulgou, desde então, novas falhas que a afetam — poluição de protótipos em _.unset e _.omit (CVE-2025-13465 e CVE-2026-2950) e uma brecha de injeção de código em _.template (CVE-2026-4800). As correções agora estão disponíveis na linha lodash 4.18.x, mas atualizar ou remover o lodash por completo é dispendioso, e a análise de custo-benefício raramente aponta a favor de fazer isso agora.

O problema da dependência transitiva

Muitas equipes que utilizam o lodash 4.17.21 nem sequer o fazem diretamente. A vulnerabilidade está três camadas abaixo, dentro de uma dependência de uma dependência de um framework que elas instalaram há dois anos. Execute npm ls lodash em um projeto Node.js de tamanho médio e você frequentemente encontrará uma árvore ramificada de referências indiretas. O próprio código do aplicativo pode nem mesmo importar o lodash.

Isso torna a questão da responsabilidade extremamente delicada. Quem é responsável por corrigir uma dependência transitiva que nenhum membro da equipe introduziu intencionalmente? O time de segurança afirma que a responsabilidade é da engenharia. A engenharia afirma que a responsabilidade é da equipe responsável pelo pacote upstream. Essa equipe afirma que, tecnicamente, não há como explorar a vulnerabilidade no contexto atual de implantação. O ticket permanece aberto.

A psicologia da vulnerabilidade conhecida

A literatura sobre segurança concentra-se fortemente na ameaça desconhecida — o “zero-day”, o novo vetor de ataque, o adversário que age mais rapidamente do que os defensores. Mas, na prática, uma parcela significativa dos incidentes do mundo real remonta a vulnerabilidades que já eram conhecidas, sinalizadas e conscientemente adiadas.

Os engenheiros descrevem essa mesma dinâmica repetidamente nas análises pós-incidente. Eles sabiam do problema, mas não conseguiram aprovação para alterar uma parte do código-fonte que vinha funcionando de forma estável há anos, e ninguém queria ser o responsável por causar uma falha.

Isso não é negligência. Trata-se de uma resposta racional aos incentivos organizacionais. O lançamento de novos recursos gera valor visível. Refatorar um gráfico de dependências para resolver uma vulnerabilidade que ainda não causou um incidente gera valor invisível e acarreta riscos concretos na forma de regressões, atrasos e culpa caso algo dê errado na produção.

O resultado é o que os profissionais de risco às vezes chamam de “tolerância ao risco por padrão”: não uma decisão deliberada de aceitar o risco, mas um acúmulo de adiamentos até que o risco se torne parte do ambiente. As equipes deixam de percebê-lo claramente porque ele sempre esteve lá. O scanner o sinaliza, o ticket é atualizado, o sprint termina e o lodash 4.17.21 permanece.

Biblioteca pequena, grande superfície de ataque

O Lodash parece ser algo simples. É uma biblioteca de utilitários. Ele não aborda autenticação, autorização nem comunicação de rede — os componentes que a maioria das pessoas associa a códigos sensíveis à segurança. Essa percepção contribui para o problema do adiamento.

Mas a superfície de ataque não tem a ver com função. Tem a ver com exposição. As funções do lodash são chamadas em toda a lógica da aplicação, muitas vezes com dados que atravessaram limites de confiança. As vulnerabilidades de “prototype pollution” — nas quais um invasor pode manipular a cadeia de herança de objetos do JavaScript fornecendo entradas maliciosas — podem afetar o comportamento da aplicação de maneiras que não são óbvias e dependem do contexto.

A _.merge() no interior de um utilitário de gerenciamento de configuração, processando JSON fornecido pelo usuário, não parece perigosa à primeira vista. Mas é exatamente o tipo de local de chamada que, dependendo da lógica da aplicação ao redor, pode contribuir para contornar o controle de acesso, adulteração do estado da aplicação ou até mesmo caminhos de execução de código. A aparente inofensividade da função é parte do motivo pelo qual ela é perigosa.

A possibilidade de exploração depende fortemente do contexto. Um aplicativo que nunca passa dados controlados pelo usuário para os métodos afetados não está, na prática, exposto. Mas quantas equipes mapearam todos os pontos de chamada em uma base de código extensa e podem afirmar isso com segurança? Na maioria das organizações, a resposta honesta é: poucas.

Limitações da vida real que dificultam isso

A resposta óbvia — atualizar o lodash ou removê-lo — está correta em teoria, mas é difícil na prática. Mais especificamente, ela se depara com três problemas estruturais que se repetem em organizações de todos os tamanhos.

Ciclos de lançamento e requisitos de estabilidade

Muitos ambientes de produção operam com processos de controle de mudanças que exigem testes extensivos, aprovação de várias partes interessadas e um tempo mínimo de maturação antes da implantação. Uma atualização de dependências que provoque um comportamento inesperado em um conjunto de testes de integração pode atrasar o cronograma de lançamento em semanas. Em ambientes regulamentados — serviços financeiros, saúde, infraestrutura crítica — a barreira é ainda maior. As melhorias de segurança passam pelo mesmo processo que qualquer outra mudança, competindo por atenção e aprovação com recursos que geram valor comercial mensurável.

Risco de regressão em bases de código já estabelecidas

Embora o lodash 4.x tenha mantido sua API estável por anos, remover o lodash ou substituí-lo por métodos nativos exige a auditoria de todos os pontos de chamada, e mesmo a migração para a linha 4.18.x recém-lançada pode introduzir mudanças sutis no comportamento. 

Para uma base de código que acumulou chamadas ao Lodash ao longo de cinco anos ou mais, essa não é uma tarefa para um fim de semana. A cobertura de testes costuma ser desigual — as partes mais antigas e com maior uso do Lodash na base de código são frequentemente as menos bem testadas, justamente porque são anteriores às práticas modernas de teste da organização.

Lacunas em termos de responsabilidade e organização

Em arquiteturas de microsserviços e grandes organizações de engenharia, as bases de código têm responsáveis — mas a responsabilidade às vezes é ambígua no caso de serviços legados que são anteriores às estruturas atuais das equipes. Um serviço que foi desenvolvido por uma equipe que, desde então, passou por uma reorganização pode não ter um responsável claro. A equipe de segurança sinalizará a vulnerabilidade. A equipe de operações indicará o serviço no relatório. Ninguém terá autoridade nem o contexto necessário para fazer a alteração. Isso é mais comum do que a maioria das organizações está disposta a admitir.

PERSPECTIVA ESTRUTURAL

A vulnerabilidade não é o problema mais difícil. O problema mais difícil é de natureza organizacional: identificar quem é o responsável, apresentar argumentos para a priorização, garantir tempo em um sprint e absorver o risco de regressão. A complexidade técnica costuma ser a menor parte do desafio.

O que as equipes realmente fazem e o que funciona

Dadas essas restrições, organizações de engenharia sofisticadas não se limitam a ignorar o lodash 4.17.21 e torcer para que tudo dê certo. Elas aplicam uma série de estratégias de redução de risco que reconhecem que a atualização não pode ocorrer imediatamente, ao mesmo tempo em que reduzem a exposição ao risco nesse ínterim. Nenhuma delas é perfeita. Todas são melhores do que nada.

Isolamento e mapeamento da exposição

O primeiro passo é uma avaliação honesta. Nem toda aplicação que inclui o lodash em sua árvore de dependências está igualmente exposta a riscos. As equipes que dedicam tempo ao mapeamento dos locais reais de chamada — especificamente os métodos associados ao risco conhecido da versão 4.17.21, como _.template, _.unset e _.omit — podem gerar uma classificação de risco realista. Um serviço que utilize o lodash apenas para _.isEqual e _.cloneDeep em estruturas de dados internas é categoricamente diferente de um que compila _.template a partir de uma entrada controlada pelo usuário.

Esse trabalho de mapeamento é valioso mesmo que não resulte imediatamente em uma solução. Ele transforma a ansiedade geral e difusa em relação ao Lodash em uma lista priorizada de riscos reais, o que torna o planejamento das medidas corretivas mais viável.

Validação de entradas e fortalecimento na camada de proteção

As vulnerabilidades do tipo “prototype pollution” e “injeção de comando” geralmente exigem entradas controladas pelo invasor para atingir a função vulnerável. Fortalecer a validação de entradas nos limites da aplicação — aplicando validação de esquema ao JSON recebido, rejeitando entradas com padrões de chaves suspeitos, como __proto__ ou construtor, sanitizando strings antes que elas entrem nas funções de modelo – reduz a explorabilidade sem afetar a dependência subjacente.

Trata-se de um controle compensatório, não de uma correção. A vulnerabilidade permanece. No entanto, limitar as vias pelas quais as entradas do invasor podem chegar ao código vulnerável é uma medida provisória justificável, e é o tipo de alteração que muitas vezes pode ser feita sem acionar um ciclo completo de lançamento.

Monitoramento e detecção

Ferramentas de autoproteção de aplicativos em tempo de execução (RASP) e firewalls de aplicativos web podem ser configuradas para detectar e bloquear padrões de tentativas de contaminação de protótipos. O registro em log e a geração de alertas sobre padrões suspeitos de chaves de objetos em solicitações recebidas proporcionam visibilidade para saber se a vulnerabilidade está sendo ativamente testada, mesmo que ainda não seja possível corrigi-la.

A detecção não elimina o risco, mas altera o perfil de risco. Uma vulnerabilidade conhecida que está sob monitoramento ativo é substancialmente menos perigosa do que a mesma vulnerabilidade em um sistema que não gera alertas. No mínimo, a detecção contribui para uma resposta mais rápida a incidentes, caso ocorra uma exploração.

Oferecer apoio de forma seletiva

Para organizações que gerenciam múltiplas aplicações com dependências de sistemas legados, uma abordagem cada vez mais prática é tratar a extensão do suporte como uma ferramenta explícita de gestão de riscos. Em vez de forçar uma atualização frágil dentro de um cronograma que gera seus próprios riscos, as equipes podem utilizar serviços como o ELS for Libraries da TuxCare para receber correções de segurança retroativas para versões específicas de bibliotecas, mantendo a estabilidade da configuração comprovadamente estável e, ao mesmo tempo, aplicando patches às vulnerabilidades mais importantes.

Essa não é uma solução permanente e não deve ser apresentada como tal. O objetivo é criar uma margem de manobra: tempo para planejar e executar uma migração adequada sem ficar desprotegido nesse ínterim. Para equipes que operam sob um rigoroso controle de mudanças ou que gerenciam serviços com dependências pouco compreendidas, essa abordagem alinha a melhoria da segurança à realidade operacional, em vez de exigir uma atualização para a qual a organização ainda não está preparada.

Migração incremental em vez de reescritas radicais

Embora a remoção total do Lodash seja o objetivo final, abordagens incrementais reduzem o risco da própria migração. Substituir os utilitários do Lodash método por método, começando pelos pontos de chamada de maior risco e avançando gradualmente, evita a reescrita radical que costuma dar errado. As equipes acompanham o progresso por meio de auditorias de dependências, descontinuam o uso do Lodash serviço por serviço e tratam cada uso removido como uma redução mensurável do risco, em vez de uma tarefa em uma lista de pendências indiferenciada.

A Contabilidade Honesta

A verdade incômoda sobre o lodash 4.17.21 não é o fato de ele estar em produção. É que ele permanecerá em produção por muito tempo na maioria das organizações, independentemente do que os scanners de segurança indiquem ou do que os alertas de segurança afirmem. A capacidade de engenharia é limitada. A tolerância ao risco é um fenômeno organizacional real. A análise entre “atualizar agora” e “gerenciar com cuidado enquanto planejamos uma migração de fato” continuará, em muitos contextos, a favorecer a segunda opção.

A resposta a essa realidade não é a resignação. Trata-se de uma gestão honesta dos riscos: saber quais pontos de chamada estão expostos, fortalecer as barreiras de proteção, monitorar possíveis explorações e — nos casos em que o prazo para atualização for realmente longo — utilizar as ferramentas disponíveis para reduzir a janela de vulnerabilidade, sem fingir que o problema subjacente está resolvido.

A maturidade em segurança não significa ter zero vulnerabilidades conhecidas. Significa ter visibilidade dos riscos, tratar os adiamentos como decisões deliberadas, em vez de um acúmulo invisível, e sanar as lacunas de forma sistemática. O lodash 4.17.21 é um caso de teste adequado para avaliar se uma organização é capaz de fazer isso de forma honesta.

O ticket está aberto há nove meses. É hora de decidir o que você realmente vai fazer com ele.

Resumo

Nome do artigo

Vulnerabilidades do Lodash 4.17.21: Gestão de riscos

Descrição

As equipes estão cientes dos riscos do Lodash 4.17.21 – mas as atualizações nem sempre são simples. Saiba como gerenciar os riscos relacionados a dependências legadas

Autor

Tim Walker

Nome da editora

TuxCare

Logotipo da editora