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 estaba inactivo, pero no había llegado al final de su ciclo de vida, y su reactivación trajo consigo nuevas vulnerabilidades CVE en versiones fijadas desde hacía tiempo.
- Un único estado puede contener varias versiones de Lodash, la mayoría de ellas incorporadas de forma transitiva.
- Encontrar una copia vulnerable es fácil; lo realmente complicado es demostrar qué ruta de código llega hasta ella.
Nadie se sienta en una reunión de planificación y decide adoptar Lodash. Simplemente aparece. Un desarrollador con experiencia incorpora una función auxiliar, una herramienta de compilación la incluye como dependencia, una biblioteca de gráficos tres niveles más abajo necesita _.merge, y de repente se incluye en el paquete de todas las aplicaciones que lanzas. Una infraestructura discreta, no un marco de trabajo elegido por nadie.
Se extiende por todas partes donde se ejecuta un archivo JavaScript: código front-end, servicios back-end, herramientas de compilación, interfaces de línea de comandos (CLI), scripts de automatización y ese paquete interno abandonado que un equipo escribió en 2019 y que nadie ha vuelto a abrir desde entonces. El informe de Sonatype de 2024 estimaba que solo npm recibió 4,5 billones de solicitudes de paquetes durante ese año, y Lodash es uno de los paquetes más utilizados en esa avalancha.
Entonces llegó un giro que ni las notas de la versión ni la mayoría de las retrospectivas reflejaron. La versión 4.17.21 se lanzó en febrero de 2021 y, durante años, no hubo ninguna actualización. Los equipos interpretaron ese silencio como un signo de estabilidad, fijaron la versión y siguieron adelante.
Esa interpretación era errónea. La ausencia de avisos nunca fue indicio de seguridad. Apenas decía nada sobre la exposición real, y eso quedó claro en cuanto el proyecto reactivado empezó a ponerse al día con sus retrasos en materia de seguridad.
¿Se sigue manteniendo Lodash?
Sí, otra vez, tras un largo parón. Lodash estuvo prácticamente inactivo durante años y, en 2025, volvió a estar bajo una gestión activa. Los avisos que se publicaron a continuación, en 2026, son la razón por la que empezaron a activarse los antiguos «pins».
Lodash comenzó como una bifurcación de Underscore en 2012, y su creador pasó por las fundaciones Dojo y jQuery antes de que el proyecto recalara en la OpenJS Foundation, donde actualmente se encuentra en proceso de transición hacia la fase de madurez «Feature-Complete». La historia reciente resulta más fácil de seguir en forma de línea temporal.
| Fecha | ¿Qué pasó? |
|---|---|
| Febrero de 2021 | 4.17.21 incorpora correcciones para la inyección de comandos en _.template y un problema de ReDoS, y después años de tranquilidad |
| 2025 | OpenJS anuncia la financiación de Sovereign Tech Agency, una reorganización de su estructura de gobierno y un nuevo Comité Directivo Técnico |
| Enero de 2026 | 4.17.23 corrige un problema de contaminación en el prototipo de _.unset y _.omit (CVE-2025-13465), que afecta a las versiones 4.0.0 a 4.17.22 |
| Marzo de 2026 | La versión 4.18.0 corrige un _.template inyección de código a través de claves de importación (CVE-2026-4800) y una forma de eludir la actualización de enero _.unset y _.omit corrección (CVE-2026-2950) |
| Abril de 2026 | La versión 4.18.1 pasa a ser la versión actual, y corrige una regresión en la compilación modular que se produjo en la versión 4.18.0. |
El relanzamiento vino acompañado de una infraestructura operativa sólida: un plan de respuesta ante incidentes, un modelo de amenazas publicado, avisos de seguridad en GitHub, análisis con CodeQL, Renovate para la actualización de dependencias, un cuadro de mando de OpenSSF y una infraestructura de integración continua (CI) rediseñada.
¿Sabías que...? El aviso 4.17.23 se registró a través de la Autoridad de Numeración CVE de OpenJS. Fue la primera versión de seguridad de Lodash en varios años, y ese tipo de divulgación coordinada es el sello distintivo de un proceso de seguridad que funciona, en lugar de uno inactivo.
Esta es la parte importante para cualquiera que utilice código antiguo. Esa gestión renovada garantiza el mantenimiento y la seguridad de la línea de versiones actual. Esto no significa que nadie esté adaptando nuevas correcciones a la versión 3.10.1.
Qué efecto tiene un proyecto reactivado sobre una versión fijada
El mecanismo es sencillo e implacable. Un nuevo aviso puede situar un pin sin modificar dentro de un rango afectado recién identificado, sin que nadie haya modificado tu código. Tu número de versión no ha cambiado. Lo que sí ha cambiado es su perfil de riesgo conocido.
Hay tres datos que dejan esto muy claro.
Contaminación por prototipos en _.unset y _.omit Se corrigió en la versión 4.17.23. El CVE-2025-13465 abarca desde la versión 4.0.0 hasta la 4.17.22, por lo que un PIN de hace cinco años, correspondiente a la versión 4.17.21, entra de lleno en ese rango.
Se detectó una forma de eludir esa corrección, que se registró como CVE-2026-2950. El parche 4.17.23 protegía los segmentos de ruta de las cadenas, pero no los que estaban envueltos en una matriz, por lo que el mismo ataque de eliminación seguía siendo posible. Lodash 4.17.23 y versiones anteriores se ven afectadas, y el problema se corrigió en la versión 4.18.0.
Inyección de código en _.template a través de los nombres de las claves de importación, CVE-2026-4800, se debe a una corrección incompleta del antiguo CVE-2021-23337. El parche original validaba la variable «option», pero no los nombres de las claves de importación, y ambas rutas conducen a la misma Function() sink. Afecta a las versiones 4.0.0 a 4.17.23 y se ha corregido en la línea 4.18.
La selección de la versión aquí no es automática. La versión 4.18.0 presentaba un error de regresión en la compilación modular, y npm ahora la marca como obsoleta con un aviso que dice: «Versión defectuosa. Por favor, utiliza [email protected] en su lugar». Esto lleva a los usuarios directamente a una versión afectada por las tres vulnerabilidades CVE mencionadas anteriormente. La versión 4.18.1 es la que realmente te interesa. Algunas de las funciones únicas lodash.* Los paquetes también se volvieron a generar en la nueva línea. lodash.unset ahora lleva la versión 4.18.0, mientras que otros, como lodash.merge siguen sin actualizarse en la versión 4.6.2 de 2019, por lo que los proyectos más antiguos que incluyen directamente esas compilaciones deben comprobar cada una de ellas por separado.
Atención: un resultado verde en el escáner para «lodash 4.17.21» de 2024 no se mantiene verde; los avisos publicados en 2026 se aplican con carácter retroactivo a esa versión concreta, y nada en tu archivo de bloqueo te lo indicará hasta que vuelvas a realizar el escaneo.
Imagina una consola de administración de Angular de 2018 con Lodash 3.10.1 incluido en el paquete y lodash.merge me llamaron la atención dos bibliotecas de gráficos abandonadas. No hay nada incorrecto en el informe del escáner, ni tampoco nada que requiera una acción concreta. Esa brecha entre lo preciso y lo útil es donde empieza el verdadero trabajo.
La contaminación de los prototipos ha cambiado la forma en que los equipos ven las bibliotecas de utilidades
Una función auxiliar que simplemente convierte el texto a mayúsculas no traspasa ese mismo límite de seguridad. En cambio, una función que fusiona objetos o asigna un valor en una ruta sí lo hace, y esa diferencia lo explica todo. La fusión de objetos y la asignación de valores en una ruta escriben en estructuras en las que tu código confiará más adelante, lo cual supone una línea _.capitalize nunca se acerca.
El modo de fallo no es nada fuera de lo común. Introduce una clave manipulada como __proto__ o constructor.prototype en un «merge» o «path setter» vulnerable, y puedes acceder a los prototipos compartidos de los que heredan los objetos normales, empezando por Object.prototype. En el extremo más leve, se produce una denegación de servicio cuando el código posterior se atasca con un objeto corrupto. En el extremo opuesto, con el receptor adecuado, como un motor de plantillas o un Function() En este caso, la vulnerabilidad de «prototype pollution» se convierte en un punto de apoyo para la ejecución de código. Una salvedad respecto a estos avisos concretos de Lodash: el _.unset y _.omit Estas vulnerabilidades permiten eliminar propiedades de los prototipos compartidos en lugar de sobrescribirlas, por lo que el impacto real es la interrupción del servicio y la denegación de servicio, en lugar de la clásica cadena que va de la contaminación a la ejecución de código remoto (RCE).
Sin embargo, la precisión es importante. No todas las llamadas a una función afectada son vulnerables. El factor decisivo es si un atacante puede influir en el objeto fusionado o en la ruta clave. Si ambos están totalmente controlados por el desarrollador y no son accesibles mediante entradas no fiables, el riesgo es bajo. Si alguno de ellos puede verse afectado por el cuerpo de una solicitud, una cadena de consulta o un archivo analizado, considera la ruta como potencialmente vulnerable hasta que la hayas descartado. Esa distinción es lo que diferencia un plan de corrección de una simple lista de CVE que te indica que todo está en peligro.
El gráfico de dependencias es el verdadero proyecto de corrección
Encontrar una copia vulnerable de Lodash puede ser cuestión de un solo análisis. Sin embargo, decidir qué hacer al respecto lleva bastante más tiempo. El informe «Snyk State of Open Source Security» de 2022 reveló que una aplicación en desarrollo presenta, de media, 49 vulnerabilidades repartidas entre 69 dependencias, y las bibliotecas de utilidades como Lodash son precisamente el tipo de bibliotecas que se encuentran en varias capas de profundidad.
El trabajo en sí es bastante concreto. Empieza por identificar la dependencia principal que introduce cada versión de Lodash y, a continuación, determina si la deduplicación es realmente segura o si dos consumidores necesitan realmente versiones principales diferentes. Decide si las sustituciones o las resoluciones son sostenibles o si solo se trata de una deuda aplazada. Prueba por separado las copias empaquetadas y las del lado del servidor, ya que se resuelven de forma independiente. A continuación, busca las compilaciones codificadas de forma rígida o copiadas manualmente que npm no puede detectar en absoluto.
Lodash no incluye ninguna dependencia de tiempo de ejecución propia, por lo que el árbol que lo contiene está vacío. El problema se invierte. Lodash aparece como una hoja en miles de árboles diferentes, y ahí es donde se multiplican las copias. Para las versiones compatibles, TuxCare ELS puede sustituir las copias vulnerables, tanto directas como transitivas, por versiones parcheadas, que es precisamente el objetivo cuando un escáner detecta seis versiones diferentes en un mismo repositorio.
Desde la primera línea: Los equipos pueden «actualizar Lodash», cerrar el ticket y, aun así, no superar la siguiente comprobación. Actualizaron la dependencia de nivel superior y dejaron sin tocar tres copias transitivas en la versión 4.17.15, ya que una actualización directa no reescribe lo que un paquete secundario ha fijado.
La eliminación merece una nota sincera. El encadenamiento opcional, la sintaxis de expansión y los métodos modernos de Array han hecho que muchas funciones auxiliares de Lodash sean innecesarias. La semántica de la fusión profunda, cloneDeep casos extremos, debounce comportamiento, y el fp Los módulos son otra historia.
Lo cual nos lleva a la decisión. Si Lodash aparece solo en unas pocas llamadas, eliminarlo suele ser la opción más limpia. Si _.merge o _.cloneDeep Si afecta a la lógica financiera o de generación de informes, considera la eliminación como un cambio de comportamiento con su propio plan de pruebas, ya que ese tipo de cambio puede superar la integración continua (CI) y, posteriormente, provocar un error en un informe de fin de mes.
Cuatro vías de corrección
No existe una solución única, y fingir lo contrario es lo que frena la recuperación. Hay cuatro vías que abarcan las opciones realistas, y la mayoría de los complejos inmobiliarios recurren a más de una.
| Ruta | Ideal para cuando | Coste |
|---|---|---|
| Actualizar Lodash directamente | Eres responsable de la dependencia directa y las pruebas cubren los puntos de llamada | Bajo, a menos que haya alguna razón por la que no se haya fijado |
| Sustituir las funciones por JavaScript nativo | Un pequeño número de métodos de llamada sencillos (encadenamiento, propagación, métodos de matriz) | Moderada, mayor en el caso de la lógica de fusión/clonación |
| Actualizar el paquete principal | Lodash se instala de forma transitiva a través de una dependencia que se mantiene actualizada | Depende de los cambios de compatibilidad de la clase padre |
| Aplicar el parche y mantener la versión anterior | Necesitas que se incluya una versión antigua concreta en el gráfico | Migración en curso, pero sin que se trate de una migración forzada |
Es en esta última vía donde un parche de proveedor cobra sentido. TuxCare ELS for Libraries cubre las versiones 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 y 4.18.1, por lo que la versión de la que no puedes actualizar sigue beneficiándose de la protección de seguridad que ofrece la corrección del desarrollador original.
El mecanismo no tiene nada de glamuroso, y esa es precisamente la idea. Añades un alias de npm en tu directorio raíz package.json junto a overrides De este modo, las copias transitivas se resuelven con la versión parcheada, o bien se ejecuta el TuxCare Patcher en un repositorio que contenga varias dependencias cubiertas. Esa es la respuesta directa al problema de las copias transitivas.
Consejo de experto: Declarar overrides en el directorio raíz package.json, ya que npm ignora las modificaciones declaradas dentro de las dependencias instaladas. Dirígelas a la versión parcheada con alias para que npm resuelva las instancias coincidentes del nombre del paquete vulnerable con el sustituto actualizado en todo el árbol de dependencias.
Cómo garantiza TuxCare la seguridad de las versiones antiguas de Lodash
Retroaplicar una corrección a una biblioteca de utilidades con una década de antigüedad no es una simple cuestión de «copiar y pegar», y si se aborda así es precisamente como se rompen esos casos extremos en los que se basan las aplicaciones. El proceso se desarrolla en cuatro fases.
En primer lugar, hay que analizar si cada nueva revelación afecta realmente a una versión cubierta, en lugar de dar por sentado que un rango de versiones publicadas describe la vulnerabilidad en todas las aplicaciones. En segundo lugar, hay que aplicar retroactivamente la medida de seguridad sin introducir cambios de comportamiento ajenos al tema. Esa moderación es más importante aquí que en casi cualquier otro ámbito, ya que las aplicaciones dependen del comportamiento de Lodash en casos extremos, que una refactorización bienintencionada alteraría sin que nadie se diera cuenta.
En tercer lugar, se deben realizar pruebas de regresión tanto en las funciones comunes como en las rutas específicas afectadas, para que una corrección de la contaminación del prototipo no altere lo que _.merge devuelve un objeto anidado válido. En cuarto lugar, firma todos los paquetes compilados y publica los documentos SBOM y VEX junto con cada lanzamiento, para que tus auditores dispongan de una procedencia verificable en lugar de una simple promesa.
Se trata de una labor de mantenimiento, no de innovación en el proyecto original, y la distinción es deliberada. TuxCare se especializa en mantener el código de producción seguro y estable una vez que las prioridades del proyecto original han pasado a otra cosa, con parches predecibles y que dan prioridad a la compatibilidad para sistemas que se prevé que sigan funcionando durante años.
¿Quién pagó el reinicio de Lodash y por qué es importante el modelo?
Lodash es el ejemplo más claro de un patrón que merece la pena destacar. La financiación de la Sovereign Tech Agency, gestionada con el apoyo de la OpenJS Foundation, sufragó el trabajo de gobernanza y seguridad de una biblioteca de la que dependen millones de sistemas, y merece la pena leer íntegramente el artículo de OpenJS al respecto.
Lo que esa financiación no cubre es el mantenimiento indefinido de la versión 3.10.1. Ha servido para reforzar el proyecto actual; no ha obligado a los voluntarios a adaptar las correcciones a una versión de 2015, y fingir lo contrario es lo que lleva al agotamiento de los mantenedores.
El Programa de Sostenibilidad del Ecosistema cubre esa carencia desde el punto de vista comercial, y una parte de los ingresos se destina a los proyectos participantes. TuxCare es miembro Gold de la OpenJS Foundation y uno de los proveedores del programa, y figura junto a HeroDevs y NodeSource en la página de fin de vida útil de Node.js.
Vale la pena dejarlo claro, porque así todos actúan con honestidad. Un parche de proveedor para la versión 4.17.21 es un parche de proveedor, no una versión de origen, y unas buenas herramientas dejan clara esa procedencia en lugar de ocultarla. Y cuando una copia no se puede actualizar en absoluto, ELS para Lodash proporciona las correcciones a través de npm a la versión que estés ejecutando realmente, durante todo el tiempo que necesites utilizarla.
PREGUNTAS FRECUENTES
¿Se ha llegado al final del ciclo de vida de Lodash?
No. Estuvo inactivo durante años, pero ahora se mantiene de nuevo de forma activa bajo OpenJS, con una reestructuración de la gobernanza financiada y una versión actual en la línea 4.18.
¿Sigue siendo segura la versión 4.17.21?
No se refiere a las vulnerabilidades reveladas desde la reactivación. Se encuentra dentro del ámbito afectado por tres avisos: CVE-2025-13465 y CVE-2026-2950 (contaminación de prototipos en _.unset y _.omit, incluida una forma de eludir la primera corrección) y CVE-2026-4800 (_.template (inyección de código). La actualización a la versión 4.18.1 corrige estos tres problemas, al igual que una versión mantenida que incluye correcciones para cada uno de ellos.
¿Debería tener la versión 4.18.1?
En el caso de los proyectos que se mantienen activamente, sí. La versión 4.18.1 es la actual y corrige la regresión en la compilación modular que se incluyó en la versión 4.18.0. Si en tu grafo hay una versión antigua concreta integrada de forma permanente, la alternativa es una versión parcheada y mantenida a través del servicio «Endless Lifecycle Support» de TuxCare.
¿Sigo necesitando Lodash?
A menudo no. La sintaxis nativa sustituyó a muchas de las funciones auxiliares sencillas, y structuredClone abarca los casos habituales de clonación profunda, aunque descarta los prototipos de clase y los metadatos de las propiedades, y lanza una excepción ante los valores que no puede clonar, incluidas las funciones. La fusión profunda, debounce, y el fp El módulo aún no tiene un sustituto conciso de una sola línea.
Antes de cerrar el ticket
«Actualizar Lodash» no constituye un plan de corrección hasta que se haya tenido en cuenta todas las copias accesibles. Puedes consultar los avisos actuales correspondientes a cada versión incluida en el rastreador de CVE de TuxCare.
