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 mayor parte del riesgo asociado a jQuery proviene de versiones antiguas que aún se utilizan en entornos de producción, y no de ningún problema recién descubierto.
- El XSS encabeza la lista gracias a los CVE-2020-11022, CVE-2020-11023 y CVE-2015-9251, seguido de cerca por la contaminación de prototipos.
- Las versiones 1.x y 2.x de jQuery ya no reciben soporte; la versión 3.x solo recibe correcciones críticas, y la 4.x es la rama actual.
- Si la actualización aún no es viable, los parches proporcionados por el fabricante evitan que una versión antigua se convierta en un problema.
Un escáner de seguridad detecta jQuery 3.4.1 en una aplicación que nadie ha tocado en tres años y, de repente, te encuentras con un CVE que ni siquiera sabías que tenías. Así es toda la historia de las vulnerabilidades de jQuery en 2026. Los fallos son antiguos, las correcciones ya existen y el riesgo se esconde en una versión que nadie recordaba que todavía estaba en producción.
Esta guía explica en detalle cuáles son las vulnerabilidades CVE, qué permiten hacer a un atacante, por qué siguen pasando desapercibidas en las auditorías y cómo solucionarlas, tanto si puedes actualizar el sistema como si no.
Resumen de las vulnerabilidades de jQuery
Las vulnerabilidades de jQuery son fallos de seguridad en versiones concretas de la biblioteca que pueden permitir a un atacante ejecutar código JavaScript no fiable en el navegador, alterar los prototipos de objetos compartidos o provocar el colapso de una página. Se registran como CVE, al igual que cualquier otro fallo notificado.
Lo complicado es que jQuery casi nunca es algo que un equipo mantenga de forma activa. Se incluye en un paquete, se fija en una versión que funciona y se olvida. Esa brecha entre «existe un parche» y «se aplica el parche» es donde reside el verdadero riesgo.
Tipos de vulnerabilidades de jQuery
Las vulnerabilidades se clasifican en tres categorías en las cinco CVE que se indican a continuación. XSS predomina, aunque también se dan casos de contaminación de prototipos y la denegación de servicio completan lo que realmente aparece en los resultados del análisis.
| CVE | Tipo | Versiones afectadas | Corregido en |
| 11022 | XSS (htmlPrefilter) | 1.2 – 3.4.x | 3.5.0 |
| 11023 | XSS (select/option) | 1.0.3 – 3.4.x | 3.5.0 |
| 11358 | Contaminación por prototipos | 1.1.4 – 3.3.x | 3.4.0 |
| 9251 | XSS (Ajax entre dominios) | Antes de la versión 3.0.0 | 3.0.0 |
Scripting entre sitios (XSS)
El XSS es el principal problema de jQuery. CVE-2020-11022 se refiere al HTML no fiable en general que se pasa a los métodos de manipulación del DOM de jQuery, y tiene su origen en cómo jQuery.htmlPrefilter normaliza el código de marcado. CVE-2020-11023 afecta al código HTML que contiene elementos «option». Entre ambos, abarcan todas las versiones desde la 1.0.3 hasta cualquier versión anterior a la 3.5.0, lo que incluye jQuery 3.4.1, que sigue muy presente en el entorno real. En condiciones de vulnerabilidad, el código controlado por un atacante y pasado a uno de esos métodos puede acabar ejecutando un script en la página, incluso después de haber sido depurado. En cualquier versión anterior a la 3.0.0 también existe CVE-2015-9251, el XSS de Ajax entre dominios, en el que la versión 1.12.2 es la única excepción parcheada en ese rango.
Contaminación por prototipos
CVE-2019-11358 afecta a las versiones desde la 1.1.4 hasta la 3.4.0, excluida esta última. Un objeto manipulado pasado a través de jQuery.extend(true, {}, …) puede escribir en Object.prototype, de modo que las propiedades controladas por el atacante son heredadas por otros objetos que dependen de esa cadena de prototipos. Por sí sola, se trata de una técnica de manipulación básica. Dependiendo de cómo se utilicen posteriormente las propiedades contaminadas, puede encadenarse con XSS u otros impactos específicos de la aplicación. Se ha detectado de forma destacada en Drupal y Backdrop CMS, lo que explica en parte por qué se encuentra mucho más allá del código jQuery escrito a mano.
Denegación de servicio (DoS)
La categoría más silenciosa. CVE-2016-10707 afecta a jQuery 3.0.0-rc.1 y a nada más. Esa versión candidata gestionaba incorrectamente los nombres de atributos booleanos con mayúsculas y minúsculas mezcladas, por lo que el getter afectado entraba en una recursión infinita y agotaba la pila de llamadas. Se trata de un tipo de impacto diferente al del par de vulnerabilidades XSS, y llegar a esa ruta de código sigue bloqueando la página en la que se ejecuta. La versión final 3.0.0 lo corrigió.
¿Sabías que...? El informe OSSRA de 2026 (Black Duck) identificó cuatro CVE de jQuery entre las diez vulnerabilidades más frecuentes, que en conjunto afectaban entre el 25 % y el 28 % de los códigos fuente auditados. Fallos con años de antigüedad, para los que hace tiempo que hay parches disponibles, siguen apareciendo en más de una cuarta parte del software comercial.
Riesgos de no corregir las vulnerabilidades de jQuery
Una vulnerabilidad CVE de jQuery no es un riesgo abstracto. La biblioteca está presente en una gran parte de la web y, dependiendo de la vulnerabilidad CVE que contenga y de cómo la utilice tu aplicación, las consecuencias pueden ir desde la ejecución de código en los navegadores de tus usuarios hasta una observación en un informe de auditoría o una página que deje de responder.
Apropiación indebida de cuentas y robo de sesión
El XSS es la principal consecuencia de las vulnerabilidades CVE más frecuentes de jQuery, y el XSS implica que un atacante puede ejecutar código JavaScript en el navegador de tu usuario. En la práctica, esto se traduce en la captura de credenciales en un formulario de inicio de sesión, el robo de cualquier dato de sesión al que pueda acceder JavaScript o la realización de acciones de forma encubierta en nombre del usuario que ha iniciado sesión.
Las cookies «HttpOnly» mantienen la propia cookie fuera del alcance de terceros, lo que ayuda, pero no impide en absoluto que un atacante actúe dentro de esa sesión. En el caso de una aplicación SaaS más pequeña, en la que el panel de administración sigue funcionando con jQuery 3.4.1, basta con una sola carga útil almacenada para acceder a la sesión de un administrador.
Cumplimiento y fallos de auditoría
Las vulnerabilidades conocidas en las dependencias de producción salen a la luz constantemente en las evaluaciones de PCI DSS, los análisis de vulnerabilidades y las revisiones de seguridad empresarial, y decir «solo es la biblioteca de front-end» no basta para dar por resuelto el informe. Aún así, hay que demostrar que el componente se ha parcheado o se ha corregido de alguna otra forma. Los CVE subyacentes en este caso son auténticos, y no falsos positivos, aunque el resultado de un escáner concreto debe contrastarse con el código real y el estado de los parches. Vale la pena tener clara esa distinción antes de que un revisor la solicite.
Un radio de explosión mayor de lo que crees
jQuery casi nunca se utiliza como una única instancia. Los temas, los complementos y los núcleos de los CMS lo incorporan, por lo que una versión al final de su vida útil (EOL) puede repetirse en docenas de páginas o subsistemas. Hacer un seguimiento de esa difusión requiere un esfuerzo deliberado, y leer la puntuación CVSS correctamente es fundamental a la hora de empezar a priorizar la cola.
Atención: Muchos escáneres de vulnerabilidades y de cumplimiento normativo deducen la exposición a partir de la cadena de la versión de jQuery que detectan. Una corrección retroportada que mantiene el número de versión original puede seguir activando una alerta, así que documenta el parche de forma explícita.
¿Cómo se producen las vulnerabilidades de jQuery?
Hay tres motivos que explican casi todos estos problemas: utilizar una versión antigua, heredar un jQuery que nunca elegiste y proporcionarle datos no fiables.
Versiones obsoletas de jQuery
Esta es la causa principal para la mayoría de los equipos. jQuery 1.x y 2.x lanzaron sus versiones finales, 1.12.4 y 2.2.4, el 20 de mayo de 2016, y desde entonces no ha habido más versiones de desarrollo. La rama 3.x ahora solo recibe parches de seguridad críticos y correcciones de errores, siendo la 3.7.1 de agosto de 2023 su versión más reciente, y el proyecto recomienda a todos que se pasen a la 4.x.
Una vez que una versión deja de recibir soporte por parte de los desarrolladores originales, los fallos que se descubran en ella no serán corregidos por el proyecto jQuery, a menos que actualices o apliques parches procedentes de otra fuente que ofrezca soporte. Es lo mismo que ocurre con cualquier software al final de su ciclo de vida: los responsables del mantenimiento dejan de ocuparse de él, pero tus sistemas de producción siguen funcionando como si nada.
jQuery heredado y transitivo
Rara vez se asume el riesgo a propósito. WordPress, Drupal y una larga lista de temas y plugins de interfaz de usuario incorporan jQuery automáticamente. Se introduce en tu pila sin que nadie lo decida, normalmente fijado a la versión con la que lo haya probado el autor del plugin. Encontrar esas copias requiere un análisis exhaustivo, no basta con echar un vistazo a tu propio package.json. Es el mismo problema de dependencias ocultas que aparece en gestión de vulnerabilidades de PHP y en muchos otros ecosistemas.
Patrones DOM inseguros
Incluso en una versión actual, al enviar código HTML no fiable a través de .html() o .append() sigue pudiendo provocar un XSS a nivel de aplicación. La biblioteca hace exactamente lo que pedías. El error está en la entrada en la que confiaste.
Las fusiones profundas de objetos no fiables merecen el mismo escrutinio, aunque la versión parcheada ya soluciona la vulnerabilidad CVE-2019-11358, por lo que el riesgo con $.extend radica en lo que le pasas, más que en la función en sí. La aplicación del parche a la versión corrige el fallo por parte de la biblioteca. La revisión del código aún debe detectar este patrón.
La realidad: «Usamos jQuery 3, así que estamos a salvo» es la suposición errónea más habitual. Las vulnerabilidades CVE-2020-11022 y CVE-2020-11023 no se han corregido hasta la versión 3.5.0, por lo que la 3.4.1 y todas las versiones anteriores de la serie 3.x siguen siendo vulnerables.
Cómo proteger jQuery frente a vulnerabilidades
Hay un orden de actuación muy claro. Actualiza si puedes; si no puedes, consigue parches proporcionados por el fabricante; y, en cualquier caso, refuerza las defensas.
1. Actualiza a una versión compatible
La solución más limpia. Actualizar a jQuery 3.5.0 o una versión posterior cierra el par de vulnerabilidades XSS, y actualizar a la última versión 4.x te sitúa en la rama actual con soporte completo por parte de los desarrolladores originales. El inconveniente son los cambios que rompen la compatibilidad, ya que en la versión 4.0 se eliminaron API obsoletas como jQuery.trim y jQuery.isArray.
Empieza por una auditoría:
npm ls jquery
Si el árbol está limpio, actualiza y ejecuta la versión de desarrollo del complemento jQuery Migrate para que las advertencias de compatibilidad aparezcan antes de pasar a producción, en lugar de después. Si una aplicación heredada deja de funcionar tras la actualización, la segunda opción que se indica a continuación es la vía más realista.
2. Parches proporcionados por el fabricante cuando no es posible actualizar
Muchos equipos se encuentran realmente en un callejón sin salida. Un panel de control empresarial heredado que depende de jQuery 1.x, o una plantilla de CMS que deja de funcionar ante un cambio importante de versión, no van a dar el salto a la versión 4.x de la noche a la mañana. Esa es precisamente la brecha que cubre el servicio Endless Lifecycle Support (ELS) de TuxCare para jQuery .
ELS adapta las correcciones de CVE a la versión que ya estás utilizando y las distribuye a través de npm. La cobertura abarca diez versiones, desde jQuery 1.8.2 hasta la 3.4.1, todas ellas con el ciclo de vida de su código fuente original ya superado desde hace tiempo. La ventaja práctica es que se garantiza la seguridad sin obligar a una migración ni a una reescritura inmediatas del front-end, por lo que una aplicación con profundas dependencias de jQuery puede mantenerse actualizada mientras el equipo planifica el cambio adecuadamente.
Además, su alcance va más allá de jQuery, ya que abarca los ecosistemas de Java, JavaScript, Python, PHP y .NET.
3. Defensa en profundidad
La aplicación de parches para vulnerabilidades es la solución. Estas capas reducen el daño cuando, a pesar de todo, algo se cuela. Trata el HTML controlado por el atacante como si fuera inseguro, da prioridad a las API DOM seguras para texto siempre que puedas y recurre a un sanitizador de HTML de confianza cuando la aplicación tenga que renderizar realmente código de marcado no fiable. Además, establece una Política de Seguridad de Contenidos (CSP) estricta. Y genera un SBOM para que quede registrada cada copia de jQuery que figure en los metadatos de tus dependencias.
Consejo de experto: Una búsqueda con «grep» basada en la cadena de versión no detecta las copias minificadas y empaquetadas, y un SBOM generado a partir de tus manifiestos y archivos de bloqueo no detectará aquellas que nunca hayan incluido metadatos de npm. Ejecuta también un escáner basado en el contenido, como retire.js, en tus activos compilados, ya que se ha diseñado específicamente para detectar bibliotecas que se han descargado y confirmado, en lugar de instaladas.
Minimizar el riesgo empresarial relacionado con jQuery al final de su ciclo de vida
El problema de jQuery no es que la biblioteca sea complicada de entender. Es que está en todas partes, en su mayoría es antigua y rara vez es objeto de un seguimiento activo por parte de nadie. Así es como una vulnerabilidad CVE revelada en algún momento entre 2015 y 2020 acaba apareciendo en tu próxima auditoría. Según W3Techs, actualmente jQuery en aproximadamente el 66 % de todos los sitios web, y algo más de uno de cada cinco de esos sitios sigue utilizando una rama 1.x o 2.x cuya última versión original se remonta a 2016.
Busca todas las instancias. Actualiza las que puedas. En el caso de las que no puedas actualizar, contrata una cobertura respaldada por el proveedor en lugar de dejarlas expuestas. Si te ves obligado a seguir utilizando una versión al final de su ciclo de vida (EOL), el servicio «Endless Lifecycle Support» de TuxCare para jQuery la mantiene actualizada mientras planificas la migración, sin obligarte a reescribirla antes de que estés preparado.
