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
- jQuery UI se encuentra en modo de solo mantenimiento desde octubre de 2021, y solo la versión menor más reciente recibe correcciones.
- jQuery UI 1.10.4 contiene tres vulnerabilidades XSS conocidas, todas ellas corregidas únicamente en la versión 1.13.0.
- Las versiones de jQuery anteriores a la 3.5.0 contienen una vulnerabilidad XSS explotada que figura en la lista de la CISA, y una versión de jQuery UI de 2014 complica esa actualización.
- Las opciones más realistas son actualizar a la versión 1.14.x, sustituir los widgets o contratar el servicio de asistencia ampliada.
Muchas empresas que desarrollaron aplicaciones web entre 2008 y 2018 siguen teniendo jQuery UI por ahí en algún sitio. El selector de fechas de un formulario de gastos. El cuadro de diálogo modal de un panel de administración. La función de autocompletado de un cuadro de búsqueda interno. Esos componentes siguen funcionando, y precisamente por eso nadie los ha tocado en años. El problema es que el fin de la vida útil de jQuery UI llegó discretamente mientras esas aplicaciones seguían funcionando, y en el caso de las versiones más antiguas, ya no se retroaportan las correcciones de seguridad del proyecto original.
En esta entrada se analiza cuál es la situación actual del soporte de jQuery UI, qué vulnerabilidades CVE afectan a las versiones que aún están en producción, por qué su dependencia de jQuery merece más atención que la propia biblioteca y cuáles son tus opciones a partir de ahora.
Figura 1: Los widgets que ya conocerás.
¿Ha llegado realmente jQuery UI al final de su ciclo de vida?
Para todas las versiones, excepto la más reciente, sí. En octubre de 2021, los responsables de jQuery pasaron jQuery UI a un estado de «solo mantenimiento», anunciando la versión 1.13.0 como la última versión prevista del proyecto. Los planes cambiaron ligeramente y se han seguido lanzando versiones desde entonces, pero solo para tareas de seguridad, compatibilidad y corrección de errores, y únicamente en la versión menor más reciente.
No existe un calendario de fin de vida útil (EOL) publicado para jQuery UI, por lo que las fechas que figuran a continuación se basan en la política de «solo la versión menor más reciente», y no en avisos de fin de vida útil anunciados.
| Sucursal | Estado | Notas |
|---|---|---|
| 1.14.x | Mantenimiento: se incorporan correcciones | La última versión es la 1.14.2, lanzada en enero de 2026. No es compatible con Internet Explorer ni con Edge Legacy. |
| 1.13.x | Sin soporte desde agosto de 2024 | El soporte técnico finalizó con el lanzamiento de la versión 1.14.0 el 5 de agosto de 2024. La última versión fue la 1.13.3, lanzada en abril de 2024. |
| 1.12.x | Sin soporte desde octubre de 2021 | La versión 1.12.1 fue la vigente desde septiembre de 2016 hasta que salió la 1.13.0. |
| 1.11.x | Sin soporte desde julio de 2016 | El soporte técnico finalizó con el lanzamiento de la versión 1.12.0. La última versión fue la 1.11.4, en marzo de 2015. |
| 1.10.x y versiones anteriores | Sin soporte desde junio de 2014 | La versión 1.10.4 se lanzó en enero de 2014 y fue sustituida por la 1.11.0 en junio de ese mismo año. |
Las últimas filas son donde la cosa se complica. La 1.12.1 fue la versión actual durante cinco años y es la versión en la que muchos equipos se quedaron, pero muchas aplicaciones nunca llegaron tan lejos. La 1.10.4 se lanzó en enero de 2014 y dejó de recibir correcciones ese mismo año, por lo que cualquier sistema que aún la utilice lleva más de una década sin un parche de seguridad del desarrollador original. Si tu aplicación se desarrolló antes de 2014 y nadie ha actualizado deliberadamente la interfaz de usuario, eso es lo primero que conviene comprobar.
Figura 2: La brecha de soporte entre las líneas de lanzamiento.
Qué supone el fin de vida útil de jQuery UI para tus aplicaciones
Una biblioteca de jQuery UI abandonada presenta fallos distintos a los de un entorno de ejecución de servidor abandonado. El código vulnerable se ejecuta en los navegadores de tus usuarios, en páginas con las que interactúan a diario, y las vulnerabilidades de jQuery UI que se comentan a continuación son todas de tipo «cross-site scripting», en lugar de estar relacionadas con el lado del servidor.
Las CVE que ya figuran en los registros
En la versión 1.13 se corrigieron cuatro vulnerabilidades XSS. Tres de ellas se remontan hasta la versión 1.10.4. La cuarta solo afecta a la versión 1.12.0 y posteriores, ya que el widget al que se dirige no existía antes de esa versión.
41182 y 41183 permite la inyección de scripts a través del selector de fechas altField opción y su *Text opciones, respectivamente. 41184 hace lo mismo a través de la of opción de la .position() utilidad que utilizan internamente widgets como la información sobre herramientas y el autocompletado. Los tres se corrigieron en la versión 1.13.0, por lo que una implementación de la versión 1.10.4 los contiene todos. El cuarto, 31160, es un XSS que se activa al actualizar un widget «checkboxradio» con una etiqueta similar a HTML, y se corrigió en la versión 1.13.2. Ese widget se introdujo en la versión 1.12.0, por lo que la ruta de código vulnerable no existe en las versiones 1.10.4 ni 1.11.x. No obstante, conviene saberlo antes de que llegue tu próximo informe de análisis, ya que el aviso publicado señala como afectadas todas las versiones anteriores a la 1.13.2 sin establecer un límite inferior, por lo que un escáner lo marcará como vulnerable en la versión 1.10.4 de todos modos.
Merece la pena fijarse en la cronología. Tres de las cuatro se corrigieron en la propia versión 1.13.0, el lanzamiento que se publicó junto con el anuncio del modo de mantenimiento, y cuyos avisos se publicaron unas semanas más tarde. La cuarta se solucionó nueve meses después de entrar en modo de mantenimiento. Las vulnerabilidades no dejaron de aparecer cuando se detuvo el desarrollo activo. Lo que cambió fue hasta qué punto se remontan las correcciones.
Figura 3: Ubicación de las CVE en la interfaz.
Lo que nunca se retroporta
La política de mantenimiento solo cubre la versión menor más reciente. Cuando surge el siguiente fallo en el selector de fechas o en el cuadro de diálogo, se evalúa en relación con la versión 1.14.x, se corrige allí si se considera necesario y no se modifica en ninguna otra parte.
Es probable que el aviso te indique que tu rama se ve afectada, ya que los avisos de jQuery UI especifican los rangos afectados de la siguiente manera: < 1.13.0 y < 1.13.2. Lo que no va a ocurrir es una adaptación a versiones anteriores. Para los equipos que utilicen versiones congeladas, cualquier aviso futuro que llegue a su rama describirá una vulnerabilidad que nadie en el proyecto original va a corregir.
Cuando los marcos de cumplimiento se vuelven estrictos
La lógica de auditoría es la misma para cualquier componente sin mantenimiento, pero se aplica de forma diferente según el marco normativo al que estés sujeto. La norma PCI DSS 4.x exige la aplicación de parches para vulnerabilidades críticas en el plazo de un mes desde su publicación, mientras que el resto se rige por plazos basados en el riesgo que tú mismo definas; y ninguno de estos plazos es fácil de cumplir mediante la aplicación de parches cuando no existe una solución compatible. Si tus controles SOC 2 incluyen la gestión de vulnerabilidades, un componente sin soporte técnico dificulta demostrar que los riesgos identificados se están gestionando realmente una vez que no hay disponible una solución por parte del proveedor, que es el momento en el que los auditores empiezan a preguntarse qué hace realmente tu proceso de gestión de vulnerabilidades. La Norma de Seguridad de la HIPAA exige a las entidades reguladas que identifiquen los riesgos para la ePHI y los reduzcan a un nivel razonable y adecuado, por lo que un XSS conocido e irreparable en un portal de atención al paciente pasa a formar parte de ese análisis, lo quieras o no.
El ámbito federal ha evolucionado recientemente, y la antigua terminología ha quedado obsoleta. La CISA revocó la BOD 22-01 en junio de 2026 y la sustituyó por la BOD 26-04, que establece plazos de corrección diferenciados para las agencias civiles federales en función de la exposición de los activos, el estado KEV, la automatización de los exploits y el impacto técnico, debiéndose cumplir los plazos más estrictos en tan solo tres días. FedRAMP se está alineando con este mismo enfoque basado en el riesgo, y sus normas de detección y respuesta ante vulnerabilidades pasarán a ser obligatorias para los proveedores de servicios en la nube a partir del 7 de diciembre de 2026, sustituyendo el plazo fijo de 30 días para las vulnerabilidades de alta gravedad por una evaluación basada en el riesgo. Los fabricantes de productos cuentan con su propia versión de esta normativa en virtud de la Ley de Ciberresiliencia de la UE, en la que las obligaciones de notificación de vulnerabilidades explotadas activamente entrarán en vigor el 11 de septiembre de 2026, y los requisitos completos de gestión de vulnerabilidades lo harán en diciembre de 2027.
Ninguno de estos marcos convierte el mensaje «se ha detectado jQuery heredado» en un hallazgo automático, ya que el ámbito de aplicación, la exposición y los controles compensatorios son factores importantes. Sin embargo, los escáneres señalan rápidamente las pilas de front-end heredadas y, en cualquiera de estos regímenes, esa señal se convierte en un trabajo que hay que justificar.
Cómo jQuery UI, al llegar al final de su ciclo de vida, mantiene la versión antigua de jQuery
El árbol de dependencias de jQuery UI es de lo más sencillo que hay. En el paquete actual de npm, jQuery es la única dependencia de tiempo de ejecución declarada, fijada como jquery >=1.12.0 <5.0.0. El código anterior de jQuery UI sí presentaba una dependencia a nivel de componente del complemento jQuery Mousewheel dentro del widget «spinner», que se eliminó en la versión 1.14.2 en enero de 2026, pero esa nunca fue una segunda dependencia declarada. En cualquier caso, no se trata de un componente integrado en un binario de tiempo de ejecución. jQuery se carga en su propia etiqueta de script, normalmente en la línea anterior a la de jQuery UI, y la mayoría de los equipos pueden identificar su versión de jQuery más rápidamente que la de jQuery UI. El riesgo aquí no está oculto. Se trata de un acoplamiento.
Empecemos por lo que está en juego en esa dependencia visible. La vulnerabilidad CVE-2020-11023, un XSS que afecta a todas las versiones de jQuery desde la 1.0.3 hasta la 3.4.1, se incluyó en el catálogo de «Vulnerabilidades explotadas conocidas» de la CISA en enero de 2025 tras detectarse pruebas de su explotación en el mundo real, con un plazo federal para su corrección fijado para el 13 de febrero de 2025. Su vulnerabilidad hermana, CVE-2020-11022, pertenece a la misma familia de manipulación del DOM, y CVE-2019-11358 añade una contaminación de prototipos en versiones anteriores a la 3.4.0. La contaminación de prototipos se corrigió en la versión 3.4.0 y ambas vulnerabilidades XSS en la 3.5.0, por lo que todo lo mencionado aquí ya ha sido corregido en el código fuente desde 2020.
Entonces, ¿por qué hay pilas que siguen ejecutando jQuery 1.x o 2.x seis años después? Para algunas de ellas, jQuery UI es parte de lo que dificulta la transición. jQuery UI 1.10.4 se lanzó en enero de 2014, más de dos años antes de que existiera jQuery 3.0, y el proyecto describió posteriormente el objetivo principal de la versión 1.13.0 como «mejorar la compatibilidad con las versiones recientes de jQuery». Una versión tan antigua no puede haberse probado con un jQuery que aún no existía, por lo que actualizar jQuery en el marco de una implementación 1.10 congelada es más un ejercicio de compatibilidad que un simple cambio de versión. La actualización de jQuery depende de la de jQuery UI, que a su vez depende de un periodo de control de calidad que nunca llega a producirse. Una biblioteca de widgets en fin de vida útil no oculta el riesgo que supone jQuery. Lo que sí puede hacer es mantenerlo estancado.
Figura 4: Cómo una biblioteca de widgets obsoleta puede complicar la actualización de jQuery.
El soporte ampliado es una forma de salir de ese punto muerto sin obligar a realizar ninguna actualización por el momento, y TuxCare ya ofrece parches de seguridad para determinadas versiones de jQuery que han llegado al final de su vida útil (EOL), desde la 1.8.2 hasta la 3.4.1, de modo que la capa de jQuery permanece actualizada tal y como está.
Tus opciones tras el fin de vida útil de jQuery UI
La opción más adecuada dependerá de la cantidad de trabajo en el front-end que puedas asumir en este momento. Si necesitas mantenerte al día con los parches sin tocar una interfaz que ya funciona, la ampliación del soporte para la capa de jQuery te dará un respiro. Si puedes programar una migración a jQuery y una ronda de control de calidad en condiciones, actualizar a la versión 1.14.x es la solución más limpia. Y si, de todos modos, está previsto reconstruir el front-end, eliminar jQuery UI como parte de ese proyecto es mejor que hacer el trabajo dos veces.
Gana tiempo con el servicio de asistencia ampliada
El soporte de ciclo de vida ilimitado ( ELS ) de TuxCare para las versiones de jQuery que han llegado al final de su vida útil (EOL) mantiene actualizada la versión que ya utilizas, y existe un paquete ELS correspondiente para jQuery UI 1.10.4. Las correcciones se retroaplican a esa versión, se prueban comparándolas con el comportamiento existente, se firman, cuentan con el respaldo de un SLA y se distribuyen a través de npm, por lo que incorporarlas supone un simple cambio en la configuración de las dependencias, en lugar de una migración del marco de trabajo. TuxCare también cubre determinadas versiones del núcleo de jQuery que han llegado al final de su vida útil (EOL), por lo que un equipo que utilice jQuery UI 1.10.4 con una versión de jQuery incluida en la cobertura puede gestionar ambas capas sin necesidad de migrar el marco de trabajo en ninguno de los dos casos. La matriz de soporte pública enumera versiones específicas en lugar de ramas completas, y 1.10.4 es la versión de jQuery UI documentada actualmente, así que comprueba si la tuya se ajusta a ella antes de planificar nada al respecto.
TuxCare lleva a cabo esta labor en calidad de miembro Gold de la OpenJS Foundation y socio estratégico del Programa de Sostenibilidad del Ecosistema, el programa no exclusivo que utiliza la Fundación para conectar sus proyectos con apoyo comercial para aquellas versiones que ya no mantiene. También puedes consultar en tiempo real las vulnerabilidades y las correcciones en el CVE Tracker de TuxCare.
El objetivo del soporte ampliado no es mantenerte en una versión antigua para siempre. Lo que hace es eliminar la presión de los plazos, de modo que la actualización final se realice según tu calendario y se lleve a cabo correctamente.
Actualizar a la versión 1.14.x
Mantenerse en la versión secundaria compatible es la opción más clara, aunque, para una aplicación de la era 1.10, el camino hasta llegar a ella es bastante más largo de lo que sugiere el número de versión. La versión 1.14 dejó de ser compatible con jQuery 1.7 a 1.11, 2.0 a 2.1 y 3.0 a 3.5, lo que en la práctica significa todo excepto la última versión de cada línea principal de jQuery.
Esto plantea un problema que merece la pena señalar. jQuery UI 1.14.x sigue siendo compatible con jQuery 1.12.4 y 2.2.4, por lo que una implementación que ya utilice una de esas versiones no necesita actualizar jQuery para pasar a la 1.14. Además, no aporta ninguna mejora en materia de seguridad, ya que ambas versiones son anteriores a la 3.5.0 y siguen conteniendo el CVE incluido en la lista de KEV. Es perfectamente posible llegar a una versión secundaria compatible de jQuery UI sin dejar de utilizar una versión vulnerable de jQuery.
En cuanto a jQuery, la versión 4.0.0, lanzada en enero de 2026, deja de ser compatible con Internet Explorer 10 y versiones anteriores, aunque por ahora sigue siendo compatible con IE 11, y jQuery UI 1.14.2 ha sido probada con ella. Si vas a seguir utilizando la línea 3.x, es mejor optar por una versión actual, como la 3.7.1, en lugar de la versión mínima que, casualmente, corrige las antiguas vulnerabilidades (CVE).
La versión 1.14 también elimina por completo la compatibilidad con Internet Explorer y Edge Legacy y desactiva de forma predeterminada la antigua capa de compatibilidad con la API 1.11, aunque al configurar jQuery.uiBackCompat a true Restablece el comportamiento de la versión 1.13 si necesitas una transición más suave. Si vienes directamente de la versión 1.10.4, también tendrás que asimilar los cambios que rompen la compatibilidad de las versiones 1.11 y 1.12, incluidos los cambios en la API de botones y la API de efectos rediseñada, y esa capa de compatibilidad se basa en la API de la versión 1.11 en lugar de en el comportamiento completo de la versión 1.10. Ambos aspectos son importantes precisamente para el tipo de aplicaciones empresariales internas en las que jQuery UI sigue utilizándose. Y la rutina de mantenimiento continúa tras la actualización, ya que la versión 1.14 solo recibirá soporte hasta que aparezca la siguiente versión menor.
Migrar fuera de jQuery UI
Los widgets tienen equivalentes modernos. Los controles nativos como <input type="date"> Los casos más sencillos se resuelven con las bibliotecas de componentes creadas para React o Vue, o con componentes web basados en estándares, que se encargan del resto. Si, de todos modos, la aplicación debe someterse a una reconstrucción del front-end, la decisión más acertada es integrar la eliminación de jQuery UI en ese proyecto. Como medida aislada ante el fin de vida útil (EOL), suele ser la opción más costosa de las disponibles, ya que implica reconstruir y volver a probar todas las interfaces interactivas que actualmente utilizan esos widgets.
Los riesgos de precipitarse al realizar una actualización
Una actualización de jQuery UI supone un cambio visible para el usuario, por lo que precipitarse al realizarla tiene mayores repercusiones que hacerlo con una actualización del backend. La migración a jQuery 3.x puede alterar comportamientos en los que el código de la década de 2010 se basaba de forma implícita. El marcado de los widgets y la aplicación de temas han cambiado a lo largo de las distintas versiones, por lo que es necesario revisar el CSS personalizado de la época de ThemeRoller. Y la verificación no puede limitarse a ejecutar pruebas unitarias. Implica realizar pruebas de regresión visuales y funcionales en todas las páginas que contengan un selector de fechas, un cuadro de diálogo, un acordeón o autocompletado, en todos los navegadores que tus usuarios sigan utilizando.
Los equipos que condensan todo eso en un sprint de emergencia corren el riesgo de entregar directamente a los usuarios diseños defectuosos y formularios que no funcionan correctamente, para luego pasar las semanas siguientes atendiendo incidencias y aplicando parches. La deuda técnica se acumula silenciosamente, ya que las soluciones provisionales añadidas durante las prisas se convierten en lo siguiente que nadie se atreve a tocar. Las actualizaciones de las bibliotecas a las que acceden los usuarios premian la planificación y castigan los plazos ajustados.
Protege las aplicaciones front-end heredadas más allá de su fin de vida útil con TuxCare
TuxCare lleva más de una década manteniendo actualizado el software de código abierto en entornos de producción empresarial para miles de organizaciones, gracias a un proceso de aplicación de parches que combina la supervisión automatizada de CVE y la retrocompatibilidad con pruebas y una revisión obligatoria por parte de expertos. En el caso de una interfaz congelada, esto significa que el código del que sigue dependiendo tu empresa sigue recibiendo correcciones de seguridad sin que la reescritura de la interfaz se convierta en una emergencia.
Explora ELS para jQuery o empieza por el CVE Tracker para ver qué vulnerabilidades ya tienen soluciones.
