Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Lodash 4.17.21 ya no es el punto final seguro que se ha considerado durante años, y ahora presenta tres vulnerabilidades confirmadas —CVE-2025-13465, CVE-2026-2950 y CVE-2026-4800— que solo se han resuelto en la versión 4.17.23 y en la serie 4.18.x.
- La parte más complicada de la corrección es de carácter organizativo, más que técnico, por lo que localizar los puntos de llamada reales, reforzar la seguridad de las entradas en los límites y supervisar si se producen abusos son las medidas que permiten ganar tiempo cuando no es viable realizar una actualización inmediata.
- Las correcciones retroaplicadas a través de un servicio como el ELS for Libraries de TuxCare permiten a los equipos garantizar la seguridad de la versión 4.17.21, de la que se sabe que funciona correctamente, mientras planifican una migración planificada a la versión 4.18.x, en lugar de precipitarse a realizar una migración arriesgada.
Tu equipo conoce las vulnerabilidades. El ticket lleva abierto nueve meses. Nadie lo ha revisado. Aquí te explicamos por qué y qué hacer en lugar de quedarte esperando.
Hay un tipo concreto de vulnerabilidad que no se soluciona. No porque los ingenieros sean descuidados, ni porque los equipos de seguridad estén dormidos, sino porque la solución es técnicamente posible, pero operativamente aterradora. La versión 4.17.21 de lodash es el ejemplo por excelencia de este patrón en los proyectos modernos de JavaScript, y lleva años presente en entornos de producción de todo el sector.
Este artículo no es un desglose de los CVE. Esos datos ya se pueden consultar en otras fuentes. Se trata de la brecha que existe entre saber que algo va mal y ser capaz de hacer algo al respecto, así como de las formas prácticas en que los equipos superan esa brecha sin fingir que no existe.
Cómo llegó y se quedó Lodash 4.17.21
Lodash se convirtió en uno de los paquetes de JavaScript más descargados de la historia porque resolvía un problema real: la biblioteca estándar de JavaScript era escasa, presentaba inconsistencias entre distintos entornos y la compatibilidad con los navegadores era un auténtico campo minado. En su momento álgido, Lodash se utilizaba en todo tipo de proyectos, desde iniciativas paralelas de startups hasta plataformas empresariales de empresas de la lista Fortune 500.
Posteriormente, el JavaScript moderno maduró. Los métodos nativos de las matrices mejoraron. ES6 y las versiones posteriores incorporaron muchos de los patrones de utilidad que Lodash había sido pionero en introducir. Los proyectos más recientes comenzaron a lanzarse sin él. Pero los proyectos existentes —especialmente los de gran envergadura, con bases de código desarrolladas a lo largo de varios años— no eliminaron de repente Lodash. Habían acumulado miles de llamadas a sus funciones. Reestructurarlas suponía una tarea titánica con resultados inciertos.
La versión 4.17.21, lanzada en febrero de 2021 para corregir una vulnerabilidad de alta gravedad relacionada con la inyección de comandos en _.template (CVE-2021-23337), junto con un problema de denegación de servicio relacionado con expresiones regulares (CVE-2020-28500), se convirtió en la versión fijada de referencia para gran parte del ecosistema. Y ahí se mantuvo durante casi cinco años, sin que se publicaran nuevas versiones. No es que la versión 4.17.21 sea segura de forma permanente: desde entonces, un nuevo equipo de gestión ha revelado nuevas vulnerabilidades que sí la afectan —contaminación de prototipos en _.unset y _.omit (CVE-2025-13465 y CVE-2026-2950) y una elusión de la inyección de código en _.template (CVE-2026-4800). Las correcciones ya están disponibles en la línea lodash 4.18.x, pero actualizar o eliminar lodash por completo supone un gran esfuerzo, y el análisis de coste-beneficio rara vez se decanta a favor de hacerlo ahora mismo.
El problema de la dependencia transitiva
Muchos equipos que utilizan Lodash 4.17.21 ni siquiera lo hacen de forma directa. La vulnerabilidad se encuentra tres niveles más abajo, dentro de una dependencia de una dependencia de un marco de trabajo que instalaron hace dos años. Ejecuta npm ls lodash en un proyecto de Node.js de tamaño medio y, a menudo, encontrarás un árbol ramificado de referencias indirectas. Es posible que el código de la aplicación en sí ni siquiera importe nunca lodash.
Esto hace que la cuestión de la responsabilidad resulte muy incómoda. ¿Quién es responsable de solucionar una dependencia transitiva que ningún miembro del equipo ha introducido intencionadamente? El departamento de seguridad afirma que es responsabilidad del departamento de ingeniería. El departamento de ingeniería sostiene que es responsabilidad del equipo encargado del paquete de origen. Ese equipo afirma que, técnicamente, no es explotable en el contexto de implementación actual. El ticket permanece abierto.
La psicología de la vulnerabilidad conocida
La literatura sobre seguridad se centra en gran medida en la amenaza desconocida: las vulnerabilidades de día cero, los nuevos vectores de ataque y los adversarios que actúan con mayor rapidez que los defensores. Sin embargo, en la práctica, una parte significativa de los incidentes que se producen en el mundo real se remontan a vulnerabilidades que ya se conocían, se habían señalado y se habían pospuesto de forma deliberada.
Los ingenieros describen una y otra vez la misma dinámica en los análisis posteriores a los incidentes. Eran conscientes del problema, pero no conseguían la autorización para modificar una parte del código que llevaba años funcionando sin problemas, y nadie quería ser el responsable de estropearlo.
Esto no es negligencia. Se trata de una respuesta racional a los incentivos de la organización. Lanzar nuevas funcionalidades genera un valor visible. Reestructurar un gráfico de dependencias para resolver una vulnerabilidad que aún no ha provocado ningún incidente genera un valor invisible y conlleva un riesgo concreto de sufrir regresiones, retrasos y culpas si algo falla en producción.
El resultado es lo que los profesionales del riesgo denominan a veces «tolerancia al riesgo por defecto»: no se trata de una decisión deliberada de aceptar el riesgo, sino de una acumulación de aplazamientos hasta que el riesgo pasa a ser algo habitual. Los equipos dejan de percibirlo con claridad porque siempre ha estado ahí. El escáner lo señala, se actualiza el ticket, termina el sprint y Lodash 4.17.21 sigue ahí.
Biblioteca pequeña, superficie de ataque amplia
Lodash da la impresión de ser una biblioteca pequeña. Se trata de una biblioteca de utilidades. No aborda la autenticación, la autorización ni la comunicación en red, es decir, los componentes que la mayoría de la gente asocia con el código sensible en materia de seguridad. Esta percepción contribuye al problema del aplazamiento.
Pero la superficie de ataque no tiene que ver con la función, sino con la exposición. Las funciones de lodash se invocan a lo largo de toda la lógica de la aplicación, a menudo con datos que han traspasado los límites de confianza. Las vulnerabilidades de «contaminación de prototipos» —en las que un atacante puede manipular la cadena de herencia de objetos de JavaScript proporcionando entradas manipuladas— pueden afectar al comportamiento de la aplicación de formas que no son evidentes y que dependen del contexto.
A _.merge() en lo más profundo de una utilidad de gestión de la configuración, que procesa JSON proporcionado por el usuario, no parece peligrosa a primera vista. Pero es precisamente el tipo de punto de llamada que, dependiendo de la lógica de la aplicación que lo rodea, puede contribuir a eludir los controles de acceso, a la manipulación del estado de la aplicación o incluso a rutas de ejecución de código. La aparente inocuidad de la función es parte del motivo por el que resulta peligrosa.
| Vulnerabilidad | Métodos afectados | Vulnerabilidad / impacto | Severidad |
| Inyección de código (CVE-2026-4800) | _.plantilla (opciones.importaciones) | Ejecución remota de código arbitrario durante la compilación de plantillas; corrección incompleta de CVE-2021-23337 | Alta (8,1) |
| Contaminación de prototipos (CVE-2026-2950) | _.unset, _.omit | Elimina métodos de los prototipos globales mediante rutas envueltas en matrices; elude la corrección de CVE-2025-13465 | Medio (5,3) |
| Contaminación del prototipo (CVE-2025-13465) | _.unset, _.omit | Elimina métodos de los prototipos globales mediante rutas de cadena manipuladas; puede provocar una denegación de servicio | Medio (5,3) |
La posibilidad de explotación depende en gran medida del contexto. Una aplicación que nunca pasa datos controlados por el usuario a los métodos afectados no está, en la práctica, expuesta. Pero, ¿cuántos equipos han identificado todos los puntos de llamada en una base de código extensa y pueden afirmar eso con seguridad? En la mayoría de las organizaciones, la respuesta sincera es: no muchos.
Las limitaciones del mundo real que lo hacen difícil
La respuesta obvia —actualizar Lodash o eliminarlo— es correcta en teoría, pero difícil de llevar a la práctica. En concreto, se topa con tres problemas estructurales que se repiten en organizaciones de cualquier tamaño.
Ciclos de lanzamiento y requisitos de estabilidad
Muchos entornos de producción funcionan con procesos de control de cambios que requieren pruebas exhaustivas, la aprobación de múltiples partes interesadas y un tiempo mínimo de maduración antes de la implementación. Un cambio en las dependencias que provoque un comportamiento inesperado en un conjunto de pruebas de integración puede retrasar el calendario de lanzamiento varias semanas. En entornos regulados —servicios financieros, sanidad, infraestructuras críticas— la barrera es aún mayor. Las mejoras de seguridad pasan por el mismo proceso que cualquier otro cambio, compitiendo por la atención y la aprobación con funcionalidades que generan un valor empresarial cuantificable.
Riesgo de regresión en códigos fuente ya consolidados
Aunque la versión 4.x de Lodash se mantuvo estable en cuanto a su API durante años, eliminar Lodash o sustituirlo por métodos nativos requiere revisar cada punto de llamada, e incluso pasar a la nueva versión 4.18.x puede introducir cambios sutiles en el comportamiento.
En el caso de un código fuente que ha acumulado llamadas a Lodash a lo largo de cinco o más años, esto no es una tarea que se pueda realizar en un fin de semana. La cobertura de pruebas suele ser desigual: las partes más antiguas y con mayor uso de Lodash del código fuente son, con frecuencia, las menos probadas, precisamente porque son anteriores a las prácticas modernas de pruebas de la organización.
Lagunas en materia de responsabilidad y organización
En las arquitecturas de microservicios y en las grandes organizaciones de ingeniería, los códigos fuente tienen responsables; sin embargo, la responsabilidad resulta a veces ambigua en el caso de los servicios heredados que son anteriores a las estructuras actuales de los equipos. Un servicio creado por un equipo que se ha reorganizado desde entonces puede carecer de un responsable claro. El departamento de seguridad señalará la vulnerabilidad. El departamento de operaciones anotará el servicio en el informe. Nadie tendrá la autoridad ni el contexto necesarios para realizar el cambio. Esto es más habitual de lo que la mayoría de las organizaciones están dispuestas a reconocer.
PERSPECTIVA ESTRUCTURAL
La vulnerabilidad no es el problema más difícil. El problema más difícil es de carácter organizativo: identificar quién es el responsable, justificar la necesidad de darle prioridad, reservar tiempo en un sprint y asumir el riesgo de regresión. La complejidad técnica suele ser la parte menos importante del reto.
Qué hacen realmente los equipos y qué es lo que funciona
Dadas estas limitaciones, las organizaciones de ingeniería más avanzadas no se limitan a ignorar Lodash 4.17.21 y esperar que todo salga bien. Aplican una serie de estrategias de reducción de riesgos que tienen en cuenta que la actualización no puede realizarse de forma inmediata, al tiempo que reducen la exposición al riesgo mientras tanto. Ninguna de ellas es perfecta, pero todas son mejores que nada.
Aislamiento y cartografía de la exposición
El primer paso es realizar una evaluación honesta. No todas las aplicaciones que incluyen Lodash en su árbol de dependencias están expuestas al mismo riesgo. Los equipos que dedican tiempo a identificar los puntos de llamada reales —en concreto, los métodos vinculados al riesgo conocido de la versión 4.17.21, como _.template, _.unset y _.omit — pueden generar una clasificación realista de los riesgos. Un servicio que utilice lodash únicamente para _.isEqual y _.cloneDeep en estructuras de datos internas es radicalmente diferente de uno que compila _.template a partir de una entrada controlada por el usuario.
Este trabajo de análisis resulta valioso aunque no dé lugar de forma inmediata a una solución. Convierte la ansiedad generalizada y difusa que genera Lodash en una lista priorizada de riesgos reales, lo que facilita la planificación de las medidas correctivas.
Validación de entradas y refuerzo de la seguridad en los límites
Las vulnerabilidades de tipo «Prototype pollution» e «inyección de comandos» suelen requerir una entrada controlada por el atacante para llegar a la función vulnerable. Es importante reforzar la validación de entradas en los límites de la aplicación: aplicar la validación de esquemas al JSON entrante y rechazar entradas con patrones de claves sospechosos como __proto__ o constructor, y depurando las cadenas de caracteres antes de que entren en las funciones de plantilla— reduce la posibilidad de explotación sin alterar la dependencia subyacente.
Se trata de una medida correctiva, no de una solución definitiva. La vulnerabilidad sigue existiendo. Sin embargo, limitar las vías por las que los datos introducidos por un atacante pueden llegar al código vulnerable es una medida provisional defendible, y es el tipo de cambio que a menudo se puede llevar a cabo sin necesidad de iniciar un ciclo de lanzamiento completo.
Seguimiento y detección
Las herramientas de autoprotección de aplicaciones en tiempo de ejecución (RASP) y los cortafuegos de aplicaciones web pueden configurarse para detectar y bloquear patrones de intentos de «contaminación de prototipos». El registro y las alertas sobre patrones sospechosos en las claves de los objetos de las solicitudes entrantes permiten saber si se está explorando activamente la vulnerabilidad, incluso si aún no es posible aplicar un parche.
La detección no elimina el riesgo, pero modifica el perfil de riesgo. Una vulnerabilidad conocida que se supervisa de forma activa es considerablemente menos peligrosa que la misma vulnerabilidad en un sistema que no genera alertas. Como mínimo, la detección permite una respuesta más rápida ante incidentes en caso de que se produzca un ataque.
Prestar apoyo de forma selectiva
Para las organizaciones que gestionan múltiples aplicaciones con dependencias heredadas, un enfoque cada vez más práctico consiste en considerar la ampliación del soporte técnico como una herramienta explícita de gestión de riesgos. En lugar de forzar una actualización inestable dentro de un plazo que genera sus propios riesgos, los equipos pueden utilizar servicios como ELS for Libraries de TuxCare para recibir correcciones de seguridad retrocompatibles para versiones específicas de bibliotecas, lo que permite mantener la estabilidad de la configuración que se sabe que funciona correctamente, al tiempo que se aplican parches a las vulnerabilidades más importantes.
No se trata de una solución permanente, y no debe presentarse como tal. El objetivo es ganar un respiro: tiempo para planificar y llevar a cabo una migración adecuada sin quedarnos desprotegidos mientras tanto. Para los equipos que operan bajo un estricto control de cambios, o que gestionan servicios con dependencias poco claras, este enfoque concilia la mejora de la seguridad con la realidad operativa, en lugar de exigir una actualización que la organización no está preparada para asumir.
Migración incremental frente a reescrituras radicales
Aunque el objetivo final sea la eliminación total de Lodash, los enfoques incrementales reducen el riesgo de la propia migración. Sustituir las utilidades de Lodash método por método, empezando por los puntos de llamada de mayor riesgo y avanzando hacia los demás, evita la reescritura radical que suele fracasar. Los equipos realizan un seguimiento del progreso mediante auditorías de dependencias, retiran el uso de Lodash servicio por servicio y consideran cada uso eliminado como una reducción medible del riesgo, en lugar de como una tarea más en una lista de tareas pendientes indiferenciada.
La contabilidad honesta
La incómoda verdad sobre Lodash 4.17.21 no es que esté en producción. Es que seguirá en producción durante mucho tiempo en la mayoría de las organizaciones, independientemente de lo que indiquen los escáneres de seguridad o de lo que digan los avisos de seguridad. La capacidad de ingeniería es limitada. La tolerancia al riesgo es un fenómeno organizativo real. La disyuntiva entre «actualizar ahora» y «gestionarlo con cuidado mientras planificamos una migración real» seguirá favoreciendo, en muchos contextos, la segunda opción.
La respuesta a esta realidad no es la resignación. Se trata de una gestión honesta de los riesgos: saber qué puntos de llamada están expuestos, reforzar las barreras de seguridad, vigilar si se producen abusos y —cuando el plazo de actualización sea realmente largo— utilizar las herramientas disponibles para reducir la ventana de vulnerabilidad sin fingir que el problema subyacente está resuelto.
La madurez en materia de seguridad no consiste en no tener ninguna vulnerabilidad conocida. Se trata de tener visibilidad sobre los riesgos, considerar los aplazamientos como decisiones deliberadas en lugar de como una acumulación invisible, y subsanar las deficiencias de forma sistemática. Lodash 4.17.21 es un caso de prueba adecuado para comprobar si una organización es capaz de hacerlo con honestidad.
El ticket lleva abierto nueve meses. Ya es hora de que decidas qué vas a hacer con él.
