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
- La longevidad ha generado el problema del ciclo de vida. Las versiones 1.x y 2.x de jQuery han llegado al final de su vida útil (EOL) y ya no reciben parches del desarrollador original, y todas las versiones de jQuery anteriores a la 3.5.0 contienen al menos una vulnerabilidad XSS (CVE) que solo se corrigió en una versión posterior.
- Por lo general, esa exposición aparece en tu gráfico de dependencias. jQuery no tiene dependencias propias, pero los complementos, los temas y los paquetes de proveedores lo incluyen en versiones que tú nunca has elegido.
- Una migración a una versión principal no consiste simplemente en cambiar de archivo. Las API eliminadas, los fallos en los complementos y los cambios de comportamiento generan errores que salen a la luz durante la interacción real de los usuarios, y no en la integración continua (CI).
- La disyuntiva entre «actualizar» o «reescribir» es falsa. OpenJS gestiona un programa no exclusivo de asistencia técnica comercial para versiones del proyecto que ya no reciben soporte, y TuxCare es uno de sus socios.
En enero de 2006, John Resig presentó jQuery en el BarCamp de Nueva York con un objetivo modesto: hacer que escribir en JavaScript resultara menos complicado. Veinte años y tres días después, el proyecto lanzó la versión 4.0.0. En algún momento entre esas dos fechas, tu aplicación incorporó jQuery 1.11.3, y sigue formando parte del paquete que implementaste el martes pasado.
Esa brecha es el verdadero problema del fin de vida útil (EOL) de jQuery. La biblioteca en sí no es el problema. El problema es que jQuery se implantó de forma tan generalizada, tan pronto y de manera tan profunda en el código de otros usuarios, que líneas completas de versiones quedaron sin soporte técnico mientras seguían funcionando en producción a una escala enorme. jQuery 1.x y 2.x llevan sin soporte técnico desde 2016. La mayoría de los sitios web que las utilizan ni siquiera se dieron cuenta.
He aquí el argumento que merece la pena plantear, porque debería cambiar la forma en que valoras tus opciones: esto no es una historia sobre equipos descuidados. Es una historia sobre un proyecto fundado por voluntarios que ha sobrevivido a la suposición de que todo el mundo se actualiza. La Fundación OpenJS, sede actual de jQuery, así lo ha manifestado públicamente y ha creado un programa específicamente para abordar esta cuestión. Esa historia te indica cuáles de tus opciones son legítimas y cuáles no son más que una forma de posponer las cosas con pasos adicionales.
¿Por qué la versión antigua de jQuery sigue estando por todas partes?
Para entender por qué persisten estas versiones, hay que recordar para qué se creó jQuery. A mediados de la década de 2000, los navegadores implementaban JavaScript y el DOM de forma tan diferente que encontrar un elemento, asociarle un controlador o realizar una solicitud asíncrona podía requerir ramificaciones específicas para cada navegador. El código que funcionaba en Firefox fallaba en Internet Explorer.
jQuery integró toda esa complejidad en una única API concisa. Eso no solo resultaba práctico, sino que proporcionaba a los equipos una capa de compatibilidad fiable en un momento en el que la plataforma no podía ofrecerla, y hacía que el desarrollo interactivo de la interfaz de usuario fuera accesible a un grupo mucho más amplio de desarrolladores.
Cada línea de lanzamiento marca una etapa de esa historia:
jQuery 1.x (2006) era compatible con navegadores desde IE 6, lo que lo convertía en una opción imprescindible para aplicaciones empresariales y gubernamentales con amplios requisitos de los clientes. La versión 1.12.4, lanzada en mayo de 2016, fue la última de la serie.
jQuery 2.x (2013) dejó de ser compatible con IE 6-8 para reducir el tamaño del paquete, aunque mantuvo una API familiar. La versión 2.2.4 fue la última, también en mayo de 2016.
jQuery 3.x (2016) unificó las dos ramas. La versión 3.7.1 (agosto de 2023) es la última versión con nuevas funcionalidades, y la política de soporte del propio proyecto establece ahora que la versión 3.x solo recibe parches de seguridad críticos y correcciones de errores, y se anima a todos los usuarios a migrar a la versión 4.x. Utilizar la versión 3.7.1 no equivale a utilizar una rama con soporte completo.
jQuery 4.0.0 se lanzó el 17 de enero de 2026, la primera versión importante en casi una década. Deja de ser compatible con IE 10 y versiones anteriores, y la eliminación de IE 11 está prevista para la versión 5.0; añade compatibilidad con Trusted Types y deja de convertir de forma silenciosa las solicitudes JSON entre dominios a JSONP. Estas dos últimas son auténticas mejoras de seguridad.
Algo que se les escapa a los equipos: jQuery UI, jQuery Mobile y Sizzle son ahora proyectos eméritos en OpenJS, lo que significa que se han retirado oficialmente. Si tu plan de migración incluye «y actualizar jQuery UI», no hay ninguna versión compatible esperándote al otro lado.
¿Qué cambia realmente al final de la vida?
Cuando finaliza el mantenimiento en el servidor, no falla nada. Los formularios se envían. Los menús se abren. Ajax funciona. La aplicación se comporta exactamente igual que el día anterior.
Lo que cambia es el modelo de seguridad. Ya no se espera que el proyecto publique correcciones para esa rama, por lo que la siguiente vulnerabilidad que afecte a tu versión llegará sin que haya ningún parche de origen que la solucione. Te enteras de ello a través de un escáner, en lugar de por las notas de la versión.
Si quieres conocer con más detalle los riesgos de seguridad más comunes y los CVE, puedes consultar nuestra guía detallada sobre las vulnerabilidades de jQuery.
El historial de CVE se centra precisamente en las funciones para las que la gente utiliza jQuery:
CVE-2020-11023: XSS in HTML parsing. Passing HTML containing <option> elements from an untrusted source into .html(), .append(), or similar can execute untrusted code even after sanitization. Affects 1.0.3 through 3.4.1, fixed in 3.5.0. CISA added it to the Known Exploited Vulnerabilities catalog on January 23, 2025, giving federal civilian agencies until February 13 to remediate. Published CVSS scores for this one range from 6.1 to 6.9 depending on which scoring source you consult, which is a fair reminder that the KEV listing rather than the number is what carries the deadline.
CVE-2020-11022: La vulnerabilidad relacionada en la misma lógica de análisis, con la misma puntuación de división. Afecta a las versiones 1.2 a 3.4.1, por lo que su rango comienza un poco más tarde que el de CVE-2020-11023.
CVE-2019-11358 (CVSS 6.1): Contaminación de prototipos en jQuery.extend(). Un atacante que pueda influir en el objeto fusionado puede modificar Object.prototype. Afecta a todas las versiones anteriores a la 3.4.0, es decir, a todas las de las series 1.x y 2.x.
CVE-2015-9251: Vulnerabilidad XSS en el manejo de Ajax entre dominios. Envío de una solicitud sin dataType y un servidor malintencionado puede responder con text/javascript, que jQuery ejecuta. Afecta a todas las versiones anteriores a la 3.0.0.
CVE-2012-6708 (CVSS 6.1): jQuery(strInput) decides whether input is HTML by looking for < anywhere in the string, which gives an attacker more room to build a payload. Affects versions before 1.9.0.
Vale la pena ser preciso: el hecho de que una versión se vea afectada no significa automáticamente que la aplicación sea vulnerable a un ataque. La exposición real depende de cómo utilices jQuery en tu código, de si llegan datos no fiables a la ruta vulnerable y de qué controles compensatorios tengas. Lo que sí demuestran estas CVE es que «la aplicación sigue funcionando» y «la aplicación sigue manteniéndose de forma segura» son afirmaciones diferentes.
Ahí es donde entran en juego las auditorías. Para un organismo estatal que gestiona un portal de permisos en la versión 1.11.3, la consecuencia práctica no es una historia dramática de violación de seguridad. Se trata de una vulnerabilidad CVE incluida en la lista KEV con un plazo federal, un hallazgo relacionado con la norma PCI DSS 6.3.3 si hay pagos de por medio, y un auditor que pregunta cuál es tu plan de corrección. Decir que «Upstream dejó de aplicar parches» no resuelve el hallazgo.
La exposición se encuentra en tu gráfico de dependencias
jQuery es autónomo y no tiene dependencias de tiempo de ejecución, lo que lo hace más sencillo que la mayoría de los paquetes modernos.
Si lo ves al revés, encontrarás el problema. jQuery es una de las bibliotecas más utilizadas en la historia de la web, y tu propio código no es más que una pequeña parte del conjunto. El resto lo componen plugins que dan por sentada una versión principal, temas de WordPress, widgets de interfaz de usuario, componentes comerciales que ya nadie mantiene, scripts de proveedores y plataformas antiguas de CMS o de comercio electrónico.
Un caso habitual: un equipo migró su propio código fuera de jQuery hace años, todo el mundo da por hecho que ya no está, y entonces abres la pestaña de red en el entorno de producción y descubres que se está cargando la versión 1.11.3 desde una ruta que nadie reconoce, porque un widget de informes con licencia incluye su propia copia. Hay dos versiones en la página, una de ellas fuera de servicio, y ninguna de ellas figura en el archivo package.json que nadie revisa. En algunos entornos, el archivo se copió en el árbol de código fuente hace años y no está gestionado por ningún gestor de paquetes.
Los escáneres detectarán muchas de ellas. Encontrar la biblioteca es lo más fácil. El equipo aún tiene que averiguar por qué está ahí esa versión, de qué depende y si su sustitución altera el comportamiento.
Ese mismo gráfico es lo que dificulta la actualización. El complemento A está pensado para la versión 1.x. El complemento B llama a .live(), que se eliminó en la versión 1.9. El complemento C es un componente comercial cuyo proveedor dejó de distribuirlo en 2019 y cuya licencia no incluye el código fuente.
Por qué OpenJS ha creado un programa para esto
jQuery es un proyecto «Impact» de la OpenJS Foundation, la entidad independiente de cualquier proveedor en la que se ha asentado tras un largo proceso de gobernanza: la Software Freedom Conservancy en 2009, la jQuery Foundation en 2012 y, posteriormente, la fusión de 2019 con la Node.js Foundation, que dio lugar a OpenJS.
La Fundación lleva años trabajando en el problema de seguridad de jQuery. El proyecto Alpha-Omega de OpenSSF destinó 350 000 dólares en 2022 a reducir los incidentes de seguridad de jQuery mediante la modernización tanto de su código como de sus usuarios. OpenJS trasladó el CDN de jQuery a Fastly, que a finales de 2024 atendía alrededor de 70 000 millones de solicitudes al mes relacionadas con él. La Fundación creó «Healthy Web Checkup», una herramienta que en cinco segundos te indica qué versión de jQuery carga tu sitio web. Encargó a IDC un estudio en el que se estimaba que, de unos 1.900 millones de sitios web, cerca del 90 % utiliza jQuery y aproximadamente un tercio de ellos necesita una actualización.
Lo que esa financiación no cubre es el mantenimiento indefinido de jQuery 1.8.2. Existe un límite estricto en cuanto al tiempo que los mantenedores pueden dedicar, sin remuneración, a corregir versiones que se lanzaron cuando Windows 7 era el sistema operativo vigente, y fingir lo contrario es lo que lleva a los mantenedores al agotamiento.
OpenJS puso en marcha el Programa de Sostenibilidad del Ecosistema en mayo de 2024 para subsanar esa carencia. Los socios proporcionan correcciones de seguridad comerciales para los proyectos alojados en OpenJS que se encuentran archivados, fuera de servicio o que son versiones anteriores de los proyectos actuales, y una parte de esos ingresos empresariales se destina a los proyectos participantes. HeroDevs fue el primer socio, le siguió NodeSource y TuxCare se unió a la Fundación como miembro Oro en 2026 y ahora figura entre los socios del ESP en la página de socios de OpenJS.
Cabe destacar que el propio proyecto jQuery considera esto como una vía legítima. Su política de soporte de versiones ofrece tres opciones a quienes utilicen una versión anterior: actualizarla, mantener la versión antigua y obtener parches de seguridad a través del soporte comercial, o mantenerla sin ningún tipo de parches, lo que el proyecto señala como un riesgo real.
Los límites siguen siendo importantes, porque el marketing de los proveedores tiende a difuminarlos:
- El programa no es exclusivo. OpenJS no te indica a qué proveedor debes acudir, y actualmente hay tres proveedores incluidos en el nivel «Foundation».
- Los socios de ESP deben ser miembros Gold o Platinum y disponer de una licencia de marca para la comercialización conjunta, con el respaldo a nivel de proyecto del TSC o del equipo central correspondiente, según proceda. La colaboración a nivel de la Fundación y la lista de proveedores aprobados para un proyecto concreto son dos cosas diferentes, así que consulta la página del proyecto que estés llevando a cabo.
- Un parche de un colaborador para jQuery 1.12.4 es un parche de ese colaborador. No se trata de una versión oficial del proyecto original y no hace que una versión antigua vuelva a tener soporte oficial.
- El programa no impide en modo alguno que los responsables de mantenimiento den su apoyo público a cualquier versión que elijan.
Los responsables del mantenimiento de jQuery son los propietarios del proyecto y de sus versiones actuales. OpenJS ofrece un espacio neutral. Los proveedores de soporte ampliado se encargan de versiones antiguas específicas una vez que finaliza el soporte por parte del desarrollador original. Se trata de una división más sostenible que esperar que los voluntarios mantengan todas las versiones históricas para siempre, o que todas las organizaciones completen una migración compleja en el momento en que finalice el plazo de soporte.
Tus tres opciones
Actualiza a una versión compatible
Siempre que sea posible, esta es la solución adecuada a largo plazo. La versión actual de jQuery es un software mejor, y la compatibilidad con «Trusted Types» de la versión 4.0, junto con el cambio en JSONP, reducen de forma efectiva tu superficie de ataque XSS.
Pero pasar de la versión 1.x no supone un simple salto de versión. Se ha reescrito el sistema de eventos. Se han modificado Ajax y los «Deferreds». .bind(), .delegate(), .live()y .error() han desaparecido o han cambiado. Los casos extremos de los selectores han variado. El complemento jQuery Migrate detectará gran parte del comportamiento obsoleto, por lo que es la primera herramienta a la que hay que recurrir. Sin embargo, no te indicará cuáles de tus complementos carecen de un sucesor que se siga manteniendo.
Para un equipo de SaaS de 40 personas con una sola aplicación, los complementos actuales y una cobertura de pruebas real, esto supone un par de sprints. Para una suite administrativa interna de un banco con 200 complementos acumulados y unos requisitos del cliente que aún mencionan Internet Explorer 11, se trata de meses, y los errores que se pasen por alto serán de ese tipo que depende de la interacción y que solo aparecen en producción.
Eliminar jQuery por completo
querySelector(), fetch(), addEventListener()y classList cubren la mayor parte de los usos que los equipos dan realmente a jQuery. Si tu uso es limitado, eliminar la dependencia es la solución más limpia, y hacerlo de forma gradual es mejor que una reescritura completa.
Si no es ligero, valóralo con honestidad. Estás reescribiendo cada operación del DOM, reimplementando funciones auxiliares, renunciando a la capa de normalización de jQuery y ejecutando el sistema antiguo en paralelo mientras desarrollas el nuevo.
Asistencia ampliada mientras modernizas
Hay algunas aplicaciones que no pueden actualizarse según el calendario que impone una divulgación, pero que tampoco pueden quedarse sin mantenimiento. El servicio «Endless Lifecycle Support» de TuxCare para jQuery cubre las versiones sin soporte , incluidas las versiones 1.8.2, 1.11.3, 1.12.4, 2.2.4, 3.1.1, 3.2.1, 3.3.1 y 3.4.1, que se distribuyen a través de npm.
El objetivo no es que sigas utilizando una versión antigua, sino separar el plazo de seguridad del plazo de migración.
Normalmente, tres preguntas bastan para aclararlo:
- ¿Un gráfico de dependencias limpio, cobertura de pruebas real y sin plugins comerciales abandonados? Actualiza a la versión 4.0.0 y listo.
- jQuery solo hace $() y .on() en unos pocos archivos? Elimínalo. No pagues por mantener código que no necesitas.
- ¿Plugins sin mantenimiento, la necesidad de mantener el navegador sin cambios o una migración que, siendo realistas, no se llevará a cabo hasta dentro de dos trimestres? Amplía el soporte técnico y planifica la actualización adecuadamente.
Lo que cuesta precipitarse
Cuando una inclusión en la lista KEV o una auditoría fallida obligan a concentrar una migración de gran envergadura en un plazo poco realista, los posibles fallos son lo suficientemente predecibles como para poder identificarlos de antemano.
Lo primero es la carga de soporte: formularios que no se envían, menús desplegables que no se abren, Ajax que falla de forma silenciosa; gran parte de ello se debe a diferencias de comportamiento entre versiones, más que a nada que haya en tu diff. Luego viene la estabilidad, normalmente un caso extremo de un plugin que solo aparece bajo la concurrencia de producción. Y, por último, la deuda técnica, porque bajo la presión de los plazos, la refactorización se pospone y el «lo arreglaremos el próximo trimestre» se convierte en algo permanente. Después, el presupuesto: horas de los contratistas, retrasos en la hoja de ruta y tus mejores ingenieros de front-end dedicando semanas a tareas de compatibilidad.
Las actualizaciones planificadas son positivas. Las actualizaciones realizadas por pánico son algo distinto, con una estructura de costes diferente, y los equipos suelen subestimarlas en un factor de dos o más.
Cómo TuxCare aplica parches a jQuery al final de su ciclo de vida
El soporte ampliado es algo más que volver a publicar un paquete antiguo, y lo más complicado es precisamente la adaptación a versiones anteriores. Una corrección escrita para una rama actual suele depender de refactorizaciones posteriores, pruebas diferentes o supuestos sobre el navegador que no existen en la versión de destino. El parche debe preservar el objetivo de seguridad del cambio del desarrollador original sin introducir comportamientos ajenos al mismo ni romper la compatibilidad que te ha llevado a seguir utilizando la versión anterior.
Seguimiento y análisis. TuxCare realiza un seguimiento de NVD, los avisos de los proveedores, las alertas de seguridad de GitHub y el catálogo KEV de la CISA, y a continuación determina si un problema notificado afecta realmente a una versión cubierta. No basta con los rangos de versiones publicadas; es necesario revisar la ruta del código vulnerable.
Retroportación y validación. Las correcciones del proyecto original se adaptan al código fuente anterior mediante herramientas automatizadas; los ingenieros de seguridad validan el resultado y, a continuación, se comprueba la integridad, la funcionalidad y la regresión antes del lanzamiento. Los paquetes se firman y se distribuyen desde los repositorios alojados por TuxCare. Si prefieres conocer los detalles técnicos en lugar del resumen, consulta el informe técnico de TuxCare sobre su proceso de aplicación de parches de código abierto es más fácil de leer que la mayoría de los documentos de este tipo.
Documentación. Cada versión registra qué CVE se han solucionado y qué componentes se han modificado, con información de SBOM y VEX, para que puedas demostrar qué incidencias ya se han subsanado. Ese es el documento que busca un auditor, y marca la diferencia entre una incidencia cerrada y una abierta.
A modo de referencia: TuxCare ha publicado más de 220 000 parches y ha resuelto más de 5 000 CVE en distintos sistemas operativos, entornos de ejecución, bibliotecas y aplicaciones a lo largo de unos 15 años.
Empieza por hacer un inventario
Antes de evaluar cualquier opción, averigua qué es lo que realmente estás ejecutando. Comprueba los árboles de código fuente, los paquetes compilados, los manifiestos de paquetes, las referencias a CDN, los complementos del CMS, las bibliotecas de proveedores y las páginas de producción renderizadas. No des por sentado que la versión que declara tu aplicación es la única que llega a los usuarios.
Para cada caso, anota la versión exacta, el componente que la utiliza, si se carga directamente o a través de otro producto, de qué depende, qué entornos de cliente deben seguir funcionando y cuántas pruebas de regresión requeriría un cambio. Una vez que se dispone de esta información, las actualizaciones sencillas se distinguen claramente de las de alto riesgo.
A continuación, comprueba la cobertura de tus versiones concretas mediante el rastreador de CVE en tiempo real, que enumera lo que ya se ha corregido. Para conocer las versiones compatibles, los precios y los detalles de implementación, consulta el página «Soporte de ciclo de vida ilimitado para jQuery» de TuxCare.
El siguiente capítulo
La persistencia de jQuery no es prueba de que una biblioteca se haya quedado obsoleta. Es prueba de hasta qué punto resolvió por completo un problema fundamental, hasta el punto de que la plataforma acabó incorporando gran parte de lo que hacía. La versión 4.0.0 demuestra que el proyecto sigue avanzando.
Sin embargo, durante las primeras etapas de esa historia se escribieron millones de líneas de código de producción, y estas avanzan a ritmos diferentes. Algunas pueden actualizarse este trimestre. Otras están vinculadas a aplicaciones críticas para el negocio, complementos en desuso, navegadores de quiosco y navegadores integrados, o a programas de modernización que se miden en años.
Pásate a software con soporte técnico siempre que puedas. Si no puedes hacerlo de inmediato, averigua exactamente qué versiones estás utilizando y establece un plan de mantenimiento real para ellas. El Programa de Sostenibilidad del Ecosistema existe para que ese plan no tenga que consistir en pedir a voluntarios que apliquen parches a las versiones de 2016 indefinidamente.
Visita la página de TuxCare «Soporte de ciclo de vida ilimitado para software de código abierto» para descubrir cómo el soporte ampliado puede cubrir el resto de tu pila de código abierto durante todo el tiempo que lo necesites.
