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 no tiene ninguna dependencia directa, pero es utilizado por más de 195 000 paquetes de npm, lo que lo convierte en un punto crítico de fallo en innumerables árboles de dependencias.
- Las soluciones provisionales para problemas de contaminación y los cambios que rompen la compatibilidad entre versiones de Lodash pueden introducir errores sutiles que solo salen a la luz bajo carga de producción, lo que conlleva un exceso de presupuesto garantizado.
- Las opciones de soporte ampliado, como TuxCare ELS, ofrecen una cobertura de seguridad continua para las versiones que han llegado al final de su ciclo de vida, mientras usted planifica las actualizaciones de forma estratégica.
Si estás desarrollando aplicaciones en JavaScript, es muy probable que Lodash forme parte de tu árbol de dependencias. Quizás lo estés utilizando directamente para esas funciones de utilidad que hacen que el desarrollo en JavaScript sea mucho más agradable. Quizás esté oculto a tres niveles de profundidad porque algún paquete que instalaste depende de él. Sea como sea, probablemente hayas visto aparecer esas advertencias de fin de vida útil (EOL) de Lodash en los análisis de seguridad y hayas pensado: «Sí, lo sé… pero ¿de verdad tengo que ocuparme de esto ahora mismo?».
No te equivocas al dudar. Y, desde luego, no eres el único.
Lodash ha sido una de las bibliotecas de JavaScript más utilizadas desde 2012, situándose constantemente como el paquete más utilizado en el ecosistema de npm. Se integra en todo tipo de proyectos, desde prototipos rápidos hasta aplicaciones empresariales que gestionan millones de usuarios. Cuando las versiones de Lodash llegan al final de su ciclo de vida, no se trata solo de actualizar un único paquete, sino de lidiar con una compleja red de dependencias que puede afectar fácilmente al funcionamiento de las aplicaciones existentes.
Hablemos de cómo mantener la seguridad y el cumplimiento normativo de tus aplicaciones basadas en Lodash, incluso cuando la versión de Lodash que ha llegado al final de su vida útil (EOL) haya dejado oficialmente de recibir soporte.
Cómo funciona el ciclo de lanzamiento de Lodash
Antes de profundizar en lo que ocurre cuando finaliza el soporte, pongámonos de acuerdo sobre cómo funciona realmente el ciclo de vida de Lodash. Porque, sinceramente, si no lo sigues de cerca, es fácil que un día te des cuenta de que tu versión de Lodash en fin de vida útil lleva años en tu código sin parches.
Lodash no sigue un calendario de lanzamientos estrictamente basado en plazos, como otros marcos de trabajo. En su lugar, lanza nuevas versiones en función de la finalización de funciones, la corrección de errores y los parches de seguridad. Las versiones principales (como de la 3.x a la 4.x) pueden mantenerse durante años, con lanzamientos de parches incrementales que resuelven los problemas de seguridad y los errores a medida que se detectan.
Así es como se ve en la práctica:
Lodash 3.x se lanzó en 2015 e introdujo métodos de cadenas, utilidades de programación funcional y compatibilidad con ES6. Estuvo en uso durante aproximadamente un año antes de que llegara la versión 4.
Lodash 4.x dropped in 2016 with major changes; it removed old IE < 9 support, introduced a 4KB core build, and modernized the entire codebase. This version has been the primary release line for nearly a decade, with 4.17.23 being the latest stable release from January 2026, which includes a security fix for CVE-2025-13465.
¿Y qué ocurre después de años utilizando la misma versión? Ahí es donde las cosas se complican. Lodash no sigue un calendario formal de anuncios de fin de vida útil como lo hacen Node.js o Bootstrap. Sin embargo, sí publica una página de política de soporte que recoge qué versiones reciben soporte activo y cuáles han llegado al final de su vida útil. Las versiones más antiguas simplemente dejan de recibir parches, la comunidad pasa a versiones más recientes y, si aparece una vulnerabilidad en una versión sin soporte, no habrá correcciones oficiales.
Qué significa realmente el EOL de Lodash para tu entorno de producción
Vale, el soporte oficial va desapareciendo. ¿Y qué? Tu código sigue funcionando bien, todo va bien, así que ¿por qué preocuparse?
Bueno, esta es la cruda realidad: el hecho de que dejen de publicarse parches no significa que dejen de aparecer vulnerabilidades. De hecho, los atacantes buscan específicamente organizaciones que sigan utilizando versiones de Lodash para las que ya no hay soporte, porque saben que esas vulnerabilidades no se van a corregir.
¿Quieres algunos ejemplos reales? Lodash tiene un historial bien documentado de problemas de seguridad, especialmente en lo que respecta a la contaminación de prototipos. Echemos un vistazo a su historial:
CVE-2021-23337 (CVSS 7.2): Vulnerabilidad de inyección de comandos en la función . Esta es grave; los atacantes remotos autenticados pueden ejecutar comandos arbitrarios enviando solicitudes especialmente diseñadas. Afecta a todas las versiones anteriores a la 4.17.21.
CVE-2020-8203 (CVSS 7.5): Contaminación de prototipos en merge, mergeWithy defaultsDeep . Los atacantes pueden inyectar propiedades en Object, lo que podría provocar una denegación de servicio o incluso la ejecución de código arbitrario. Afecta a las versiones anteriores a la 4.17.19.
CVE-2020-28500 (CVSS 5.3): Denegación de servicio mediante expresiones regulares (ReDoS) en toNumber, trimy trimEnd . Al enviar cadenas excesivamente largas, los atacantes pueden provocar que la aplicación se cuelgue indefinidamente.
CVE-2019-10744 (CVSS 9.1): Otro fallo de contaminación de prototipos, esta vez utilizando cargas útiles del constructor para inyectar propiedades en Object. Afecta a las versiones anteriores a la 4.17.12.
CVE-2019-1010266 (CVSS 4.0): Denegación de servicio causada por un consumo incontrolado de recursos en el controlador Date. Afecta a las versiones anteriores a la 4.17.11.
CVE-2018-16487 (CVSS 6.5): Otra vulnerabilidad más de contaminación de prototipos en los valores predeterminados de Deep, mergey mergeWith. Esta opción permite modificar propiedades existentes que se aplicarán a todos los objetos.
CVE-2018-3721 (CVSS 5.3): Contaminación de prototipos a través de __proto__ , lo que permite a los atacantes añadir o modificar propiedades en todos los objetos.
¿Ves la pauta? En Lodash siguen apareciendo vulnerabilidades relacionadas con la contaminación de prototipos, que afectan precisamente a las funciones de utilidad que hacen que sea tan cómodo de usar. No se trata de problemas teóricos o académicos. Son problemas de seguridad reales que pueden convertir una situación del tipo «bueno, probablemente deberíamos actualizar eso» en una auténtica pesadilla en materia de cumplimiento normativo o, lo que es peor, en una filtración real. Cuando utilizas versiones de Lodash que han llegado al final de su vida útil, quedas expuesto a todas estas vulnerabilidades sin que haya parches oficiales disponibles.
Lo que hace que estos ataques relacionados con el fin de la vida útil de Lodash sean peligrosos no es solo que sean habituales, sino lo que permiten. La contaminación de prototipos puede provocar denegación de servicio, inyección de propiedades que altere la lógica de la aplicación y, en algunos casos, ejecución remota de código. Para las aplicaciones que gestionan datos confidenciales o transacciones financieras, utilizar versiones de Lodash cuyo ciclo de vida haya finalizado significa que estos riesgos no son meras hipótesis. Son infracciones de cumplimiento a la espera de producirse.
Pero esto es lo que hace que la seguridad de Lodash resulte especialmente interesante en comparación con otras bibliotecas…
El riesgo oculto: tu árbol de dependencias
Cuando la mayoría de la gente piensa en la seguridad de Lodash, se pregunta si lo está importando directamente en su código. Pero eso es solo la punta del iceberg. El verdadero riesgo que supone el fin de la vida útil de Lodash no reside únicamente en tus dependencias directas, sino que se esconde en todo tu árbol de dependencias.
Esto es lo que pasa con Lodash: tiene cero dependencias directas. Ninguna. Es una biblioteca de utilidades autónoma que no depende de nada más. Suena genial, ¿verdad?
Pero si le das la vuelta a la cuestión, verás cuál es el verdadero problema: Lodash es sistemáticamente el paquete del que más se depende en todo el ecosistema de npm. Antes de que te des cuenta, aunque nunca hayas instalado Lodash explícitamente, lo tienes escondido en algún lugar de tu node_modules.
Estas dependencias transitivas (paquetes que no has instalado directamente) crean una maraña en la que Lodash puede aparecer varias veces en diferentes versiones. He visto proyectos en los que el equipo nunca añadió explícitamente Lodash a su package.json, pero cuando ejecutas npm list lodash, te encuentras con 15 paquetes diferentes que dependen de él, algunos en la versión 4.17.15, otros en la 4.17.19 y unos cuantos rezagados que siguen en la 3.x.
Cada instancia de Lodash supone un posible agujero de seguridad. Y, dado que se trata de dependencias anidadas que no has instalado directamente, es muy fácil pasarlas por alto durante las auditorías de seguridad.
Y aquí está el quid de la cuestión: cuando Lodash llegue al final de su ciclo de vida, no solo te enfrentarás a una biblioteca sin soporte técnico. Te enfrentarás a todo un ecosistema de paquetes que dependen de esa versión de Lodash que ha llegado al final de su ciclo de vida. Herramientas como npm audit pueden ayudarte a detectar vulnerabilidades conocidas, claro. Pero no pueden parchear mágicamente las versiones al final de su ciclo de vida por ti.
Y aquí es donde las cosas se complican de verdad. Aunque quisieras actualizar Lodash mañana mismo, tu árbol de dependencias podría tener otros planes. El paquete A requiere Lodash 3.x por motivos de compatibilidad. El paquete B no funciona con versiones posteriores a la 4.17.15. El paquete C tiene una dependencia transitiva del paquete D, que no se ha actualizado en tres años y deja de funcionar con las versiones modernas de Lodash.
Lo que parecía una tarea sencilla de «solo actualizar el paquete» se convierte de repente en un proyecto de gran envergadura para «desenredar todo este lío de dependencias». Qué divertido.
Tus opciones cuando llegue el fin de vida útil de Lodash
Vale, tu versión de Lodash se acerca al fin de su ciclo de vida, o quizá ya lo haya superado. ¿Qué opciones tienes realmente en este caso?
Básicamente, tienes tres opciones. Analicemos cada una de ellas con realismo.
Opción 1: Actualizar a la siguiente versión principal
Esta es la respuesta «oficial» que todo el mundo da. ¡Solo tienes que actualizar a la última versión de Lodash! ¡Problema resuelto! ¡Se acabaron tus preocupaciones!
Y fíjate, para muchos equipos, esta es realmente la decisión acertada. Las versiones modernas de Lodash son, sin duda, mejores; han solucionado problemas de seguridad, han mejorado el rendimiento y han añadido funciones útiles.
Pero seamos realistas por un momento: ¿qué significa realmente «simplemente actualizar» cuando se trata de una migración a una versión principal?
En primer lugar, tienes que revisar todo tu código en busca de cambios que puedan provocar errores. Lodash ha sufrido varios cambios en su API entre versiones: se han renombrado funciones, se han modificado sutilmente algunos comportamientos y se han dejado de utilizar otras funciones. A continuación, debes actualizar todas tus dependencias y esperar que sean compatibles con la nueva versión de Lodash. Después, hay que refactorizar el código que depende de comportamientos antiguos. Coordinar las implementaciones entre lo que pueden ser docenas de microservicios. Establecer planes de reversión por si algo falla en producción.
¿Se trata de una aplicación pequeña con dependencias modernas y una cobertura de pruebas sólida? Quizás puedas terminarla en un par de semanas. ¿O es una aplicación empresarial de gran envergadura con cientos de paquetes que dependen transitivamente de Lodash? Te esperan meses de trabajo de migración. Ciclos de control de calidad exhaustivos. Y la posibilidad muy real de introducir errores sutiles que solo se manifiestan bajo la carga de producción.
El salto de Lodash 3 a 4 fue especialmente complicado. Los nombres de los métodos cambiaron. El comportamiento del encadenamiento cambió. Algunos métodos se eliminaron por completo. Incluso las versiones de parche 4.17.x han introducido cambios que rompen la compatibilidad en casos extremos.
Nada de esto es imposible. Solo requiere planificación, recursos y tiempo: tres cosas de las que suele haber escasez cuando tu equipo de seguridad te está presionando con las advertencias sobre el fin de vida útil de Lodash en el último análisis de vulnerabilidades.
Opción 2: Migración a tecnologías alternativas
Hay equipos que, ante la situación del fin de vida útil de Lodash, piensan: «¿Sabes qué? Quizá esta sea nuestra oportunidad para replantearnos todo el asunto».
El paso a los métodos nativos de ES6+, el uso de Ramda para la programación funcional y el cambio a bibliotecas más especializadas son, sin duda, razones de peso para plantearse alternativas. El JavaScript moderno cuenta con métodos integrados como Array.map(), Object.assign()y Promise.all() que pueden sustituir a muchas utilidades de Lodash.
Pero no nos engañemos sobre lo que esto implica. Ya no se trata solo de una actualización de la biblioteca. Se trata de una refactorización integral. Y las refactorizaciones tienen esa curiosa costumbre de resultar mucho más complicadas de lo que nadie espera.
Lo que empieza como «simplemente sustituiremos Lodash por métodos nativos» se convierte rápidamente en «espera, tenemos que añadir polyfills para los navegadores más antiguos, reescribir todas nuestras funciones de utilidad, actualizar nuestras normas de codificación, volver a formar al equipo en patrones de programación funcional y, por cierto, tenemos que mantener el sistema antiguo mientras construimos el nuevo».
La flexibilidad es realmente atractiva. ¿El plazo y el coste? Normalmente dan bastante que pensar una vez que los calculas.
Opción 3: Asistencia técnica ampliada de TuxCare
Esta es la opción que lo cambia todo: el soporte técnico ampliado que ofrecen empresas especializadas en garantizar la seguridad del software al final de su ciclo de vida.
El servicio Endless Lifecycle Support (ELS) de TuxCare para Lodash está diseñado específicamente para esta situación. En lugar de precipitarte a realizar una actualización para la que no estás preparado o de reestructurar toda tu aplicación, puedes seguir utilizando tu versión actual de Lodash, pero con el mismo nivel de seguridad que las versiones que reciben soporte activo.
Así es como funciona: TuxCare supervisa las nuevas vulnerabilidades (CVE) que afectan a las versiones de Lodash que han dejado de recibir soporte, adapta las correcciones de seguridad a esas versiones, lo comprueba todo minuciosamente y ofrece parches que se integran a la perfección en tu configuración actual. No estás eludiendo la modernización, sino que la estás llevando a cabo de forma estratégica, según tu propio calendario y sin exponerte a riesgos de seguridad.
No se trata solo de ganar tiempo. Se trata de tomar el control de tu plan de actualizaciones sin dejar de garantizar la seguridad y el cumplimiento normativo propios de una empresa.
El verdadero coste de precipitarse al actualizar Lodash ante su fin de vida útil
Hablemos de lo que ocurre realmente cuando los equipos intentan forzar una actualización de Lodash porque se han asustado al ver las advertencias sobre el fin de vida útil (EOL) de Lodash en sus paneles de seguridad.
Cuando los equipos se ven obligados a realizar una actualización importante de la biblioteca en un plazo poco realista debido a la presión que les imponen los requisitos de cumplimiento normativo o de seguridad, es previsible que surjan problemas:
Aumento de la carga de asistencia técnica: ¿Todos esos errores que no se detectaron durante las pruebas? Empiezan a aparecer en producción. Tu equipo de soporte se ve desbordado por tickets sobre comportamientos extraños, y la mitad de ellos se remontan a sutiles diferencias en el comportamiento de los métodos de Lodash.
Inestabilidad del sistema: Quizás alguna dependencia transitiva tenía un error en un caso extremo con la nueva versión de Lodash que solo se manifiesta bajo carga de producción. Quizás una corrección de contaminación de prototipos cambió la forma en que funciona de tal manera que interrumpe el procesamiento de datos. Cuando se apresura una actualización, estos son los problemas que generan alertas a las 3 de la madrugada e ingenieros muy irritables.
Acumulación de deuda técnica: En el afán por cumplir con los requisitos, los equipos empiezan a tomar atajos. Se omite la refactorización adecuada. Las soluciones provisionales se acumulan. «Lo arreglaremos como es debido más adelante» se convierte en una situación permanente y, seis meses después, te encuentras con un lío aún mayor que el que tenías al principio.
Sobrecostes presupuestarios: Los sobrecostes están prácticamente garantizados cuando hay que apagar incendios con los problemas de actualización. Las horas extras de los contratistas de emergencia, los retrasos en el lanzamiento de nuevas funciones, el coste de oportunidad de que tus mejores ingenieros dediquen su tiempo a depurar la compatibilidad con Lodash en lugar de desarrollar nuevas capacidades... Todo ello se acumula rápidamente.
No digo que las actualizaciones sean malas. Lo que digo es que las actualizaciones precipitadas son caras y arriesgadas. La diferencia entre una actualización bien planificada y una impulsada por el pánico no es sutil. Es enorme.
La solución fácil: TuxCare ELS para el fin de vida útil de Lodash
Aquí es donde el soporte de ciclo de vida ilimitado de TuxCare para Lodash marca realmente la diferencia.
TuxCare lleva más de una década dedicándose a esto. Han proporcionado parches de seguridad para sistemas operativos, entornos de ejecución, bibliotecas y aplicaciones que han dejado de recibir soporte; estamos hablando de más de 120 000 parches. Cuando afirman que cuentan con experiencia en la gestión de los ciclos de vida del software de código abierto, no se trata solo de palabras vacías de marketing. Realmente lo han hecho a gran escala.
¿Qué diferencia al enfoque de TuxCare?
Cobertura completa del árbol de dependencias: Esto es muy importante. Aunque Lodash en sí mismo no tiene dependencias, TuxCare no se limita a parchear versiones que han llegado al final de su vida útil; entiende cómo encaja en todo tu ecosistema de dependencias. Supervisa las vulnerabilidades en todos los paquetes que dependen de Lodash y ofrece una guía completa para proteger toda tu pila. No solo estás protegiendo una biblioteca; estás protegiendo la capa de utilidades crítica de la que dependen cientos de otros paquetes.
Proceso de aplicación de parches optimizado y automatizado: El proceso de TuxCare combina una automatización avanzada con la validación de expertos. Supervisan el NVD, los avisos de seguridad de los proveedores, los feeds de seguridad de GitHub y, básicamente, todos los lugares donde se revelan vulnerabilidades. Cuando se publica un CVE, utilizan una combinación de herramientas algorítmicas y automatización asistida por IA para aplicar las correcciones a versiones sin soporte; a continuación, expertos en seguridad validan todo el proceso. Cada parche se somete a exhaustivas pruebas de integridad, funcionalidad y regresión antes de llegar a sus repositorios.
Si quieres saber exactamente cómo funciona esto «bajo el capó», echa un vistazo a el informe técnico de TuxCare sobre su proceso de parches de código abierto. Es sorprendentemente fácil de leer para ser un documento técnico.
Integración perfecta: Los parches de TuxCare se integran directamente en cualquier flujo de trabajo que ya estés utilizando. Ya sea npm, Yarn, pnpm o cualquier otro gestor de paquetes que tengas, los paquetes ELS simplemente funcionan. No tienes que reformar tus procesos ni tus herramientas. Simplemente sigues utilizando lo que ya tienes configurado.
Respuesta rápida respaldada por un acuerdo de nivel de servicio (SLA): Cuando se revelan nuevas vulnerabilidades, TuxCare ofrece parches respaldados por acuerdos de nivel de servicio reales. No tendrás que cruzar los dedos y esperar a que alguien acabe adaptando una solución. Recibirás actualizaciones de seguridad listas para producción en un plazo predecible, con asistencia garantizada si algo sale mal.
Relación calidad-precio: Esto es lo que sorprende a la gente sobre el soporte ampliado: suele ser mucho más económico que las alternativas. Si sumas el tiempo de ingeniería (a las tarifas por hora reales de tu equipo), los ciclos de pruebas, los honorarios de los contratistas, el posible tiempo de inactividad, el retraso en las funciones y el coste de oportunidad, el soporte ampliado suele suponer una fracción de ese precio. Además, no estás agotando a tu equipo con un proyecto de migración de alta presión.
Cumplimiento normativo y transparencia: Cada versión de TuxCare ofrece una visibilidad completa de los parches aplicados. Se proporciona documentación detallada sobre qué vulnerabilidades (CVE) se han solucionado, qué componentes se han modificado y cómo verificar todo ello en la lista de materiales de software (SBOM). Esto es fundamental para las auditorías de cumplimiento normativo y la elaboración de informes de seguridad.
Cómo empezar
Si estás utilizando versiones que han llegado al final de su ciclo de vida y quieres ver qué hay realmente disponible, TuxCare mantiene un rastreador CVE en tiempo real donde puedes buscar tu versión específica y ver qué vulnerabilidades se han corregido. Es una forma bastante sencilla de saber qué cobertura de seguridad obtendrías.
¿Quieres más detalles? Echa un vistazo a la página «Soporte de ciclo de vida ilimitado para Lodash» de TuxCare para obtener información sobre las versiones compatibles, los precios y cómo funciona realmente la implementación.
No dejes que el fin de la vida útil de Lodash ponga en riesgo tus sistemas
La evolución de Lodash de la versión 3 a la 4 trajo consigo mejoras reales, un mejor rendimiento, prácticas modernas de JavaScript, un código más limpio e importantes correcciones de seguridad. Se trata de ventajas reales, y si estás empezando desde cero, sin duda merece la pena utilizar Lodash 4.17.21 o una versión posterior.
Pero, ¿qué pasa si estás manteniendo aplicaciones existentes que, siendo realistas, no pueden actualizarse según el calendario de lanzamientos indefinido de Lodash sin que ello suponga una interrupción importante? El fin de la vida útil (EOL) de Lodash no tiene por qué significar «modo pánico» o «pesadilla de seguridad».
Tienes opciones. Opciones reales. Puedes planificar una actualización bien meditada cuando realmente tenga sentido para tu empresa. Puedes explorar enfoques alternativos si existe una razón técnica realmente convincente. O puedes recurrir al soporte ampliado para mantener la seguridad y el cumplimiento normativo mientras tomas esas decisiones a tu propio ritmo, en lugar de verte obligado a tomarlas a raíz de la divulgación de una vulnerabilidad.
Los equipos que gestionan adecuadamente el panorama de seguridad tras el fin de vida útil de Lodash no son necesariamente los que cuentan con los presupuestos más elevados o con los códigos fuente más modernos. Son aquellos que reconocen los riesgos, comprenden las opciones de las que disponen y toman decisiones meditadas sobre cómo actuar en el futuro.
Si actualmente estás considerando la actualización de Lodash, vale la pena que eches un vistazo a lo que ofrece TuxCare. Quizás descubras que lo mejor no es precipitarte a realizar una actualización para la que no estás preparado, sino proteger lo que ya tienes mientras planificas la actualización que realmente quieres llevar a cabo.
Visita el soporte de ciclo de vida ilimitado de TuxCare para software de código abierto para descubrir cómo el soporte ampliado puede proteger toda su pila de código abierto durante todo el tiempo que lo necesite.
