CVE-2026-9022 es una vulnerabilidad de tipo XSS almacenado que afecta al plugin Splide Carousel Block para WordPress en todas las versiones hasta la 1.7.1 inclusive, publicada en 2026 y clasificada con severidad MEDIUM (CVSS 6.4). El fallo permite que un atacante autenticado con acceso de contribuidor inyecte scripts maliciosos en el atributo url del bloque, que se ejecutan cuando un visitante accede a la página publicada.

En 30 segundos

  • Plugin afectado: Splide Carousel Block, versiones hasta 1.7.1 (inclusive).
  • Tipo de ataque: XSS almacenado vía atributo url del bloque, sin sanitización ni escapado.
  • Requiere autenticación: nivel contribuidor o superior, más aprobación de editor/admin para publicar.
  • Solución: actualizar a la versión 1.7.2 o superior desde el panel de WordPress.
  • Severidad CVSS v3.1: 6.4 MEDIUM — real pero acotado por los requisitos de acceso.

CVE-2026-9022: qué es y por qué importa para tu sitio WordPress

CVE-2026-9022 es el identificador oficial de una vulnerabilidad de Cross-Site Scripting almacenado (Stored XSS) en el plugin Splide Carousel Block para WordPress, catalogada bajo CWE-79 (neutralización incorrecta de entrada durante la generación de página web). Wordfence la documentó dentro de su reporte semanal de vulnerabilidades de la semana del 30 de marzo al 5 de abril de 2026, y INCIBE-CERT la registró en su base de alertas tempranas.

El vector CVSS es AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N, lo que se traduce en: acceso por red, complejidad baja, privilegios bajos requeridos, sin interacción de usuario necesaria (una vez publicado el contenido), y con impacto que cruza el alcance del componente vulnerable. La puntuación base queda en 6.4.

No es un cero-day explotado masivamente. Pero tampoco es algo que se pueda ignorar si tu WordPress tiene contribuidores externos.

Plugin afectado: Splide Carousel Block para WordPress

Splide Carousel Block es un plugin que permite crear sliders y carruseles de imágenes o contenido directamente desde el editor de bloques de WordPress (Gutenberg). Es un plugin legítimo, con presencia en el repositorio oficial de WordPress.org, usado para mostrar galerías, testimonios, productos o cualquier contenido deslizable.

El problema está en cómo el plugin maneja el atributo url dentro del bloque de ítem de carrusel. Según el análisis del código fuente disponible en el repositorio de plugins (index.js tag 1.7.1 y view.js tag 1.7.1), ese valor se escribe en el HTML de salida sin pasar por esc_url() ni ningún filtro equivalente. Ponele que alguien mete javascript:alert(document.cookie) como URL: el plugin lo acepta, lo guarda en la base de datos y lo renderiza tal cual en el frontend.

Todas las versiones hasta la 1.7.1 están afectadas.

Tipo de vulnerabilidad: XSS almacenado y por qué es distinto al reflejado

Hay dos variantes principales de XSS que aparecen seguido en vulnerabilidades de WordPress. El XSS reflejado (reflected) requiere que el atacante engañe al usuario para que haga clic en una URL manipulada: el payload viaja en la request y se ejecuta una sola vez. Molesto, pero acotado. Te puede servir nuestra comparativa de WAFs.

El XSS almacenado (stored) es otra historia. El atacante inyecta el script una sola vez, ese payload queda guardado en la base de datos, y después se ejecuta para cada visitante que accede a la página infectada. Sin que el usuario tenga que hacer nada especial. Sin URL rara que esquivar. La página se carga y el script corre.

En este caso concreto, el flujo es: contribuidor crea o edita un bloque Splide Carousel, introduce una URL maliciosa en el atributo url, el editor o administrador revisa y publica el post (sin necesariamente notar el payload en el HTML de fondo), y desde ese momento cualquier visitante que accede a esa página ejecuta el script. ¿Qué puede hacer ese script? Robar cookies de sesión, redirigir a sitios de phishing, inyectar formularios falsos, o descargar malware en segundo plano.

Quién está realmente en riesgo (y quién no)

Acá viene lo importante: este CVE requiere autenticación con nivel de acceso contribuidor o superior. No es un ataque anónimo desde internet. Eso limita bastante el vector de ataque, pero no lo elimina.

Los escenarios de riesgo real son estos:

  • Sitios con múltiples autores freelancers o colaboradores externos que tienen rol de contribuidor.
  • Blogs o revistas digitales donde varios redactores cargan contenido y un editor aprueba antes de publicar.
  • Sitios donde alguna cuenta de contribuidor fue comprometida (credential stuffing, phishing, contraseña reutilizada).
  • Instalaciones con registros abiertos donde los usuarios reciben rol de contribuidor automáticamente.

El detalle del flujo de publicación es clave: el payload no se ejecuta hasta que un editor o administrador aprueba y publica el contenido. Lo que significa que si tu sitio es personal y sos el único usuario con acceso, el riesgo es prácticamente cero. Pero si tenés contribuidores externos, cualquier cuenta comprometida o descuidada se convierte en vector de ataque.

Cómo parchear: actualizar Splide Carousel Block

La solución es directa. El equipo del plugin lanzó una versión corregida que implementa el escapado correcto del atributo url. Los pasos:

  • Entrá a tu panel de WordPress, sección Plugins > Plugins instalados.
  • Buscá «Splide Carousel Block» en la lista.
  • Si hay una actualización disponible, hacé clic en Actualizar ahora.
  • Verificá que la versión instalada sea superior a 1.7.1 (1.7.2 o mayor).
  • Revisá que los carruseles existentes sigan mostrándose correctamente.

Si preferís hacerlo de forma manual, podés descargar la versión actualizada directamente desde WordPress.org, eliminar el plugin actual y subir el nuevo. La funcionalidad visual del bloque no cambia, pero la salida HTML ya pasa por el filtro de escapado correcto.

Si por algún motivo no podés actualizar de inmediato (compatibilidad con el tema u otro plugin), la alternativa temporal es desactivar el plugin hasta tener tiempo de hacer la actualización. Dejar corriendo la versión vulnerable con contribuidores activos es el peor escenario posible. En nuestra comparativa de detectores profundizamos sobre esto.

Cómo detectar si tu sitio ya fue explotado

Primero, la pregunta incómoda: ¿alguien lo verificó de forma independiente antes de publicar este aviso? Todavía hay pocos reportes públicos de explotación activa. Pero eso no significa que no haya ocurrido en sitios específicos.

Para verificar si tu sitio tiene contenido comprometido:

  • Revisá todos los posts y páginas que contengan bloques Splide Carousel, especialmente los publicados o modificados desde principios de 2026.
  • En el editor de bloques, inspeccioná el atributo url de cada ítem del carrusel. Una URL legítima empieza con https:// o http://. Algo como javascript:, data:, o con onerror= es señal de problema.
  • Podés exportar el contenido del sitio (Herramientas > Exportar) y abrir el XML en un editor de texto para buscar patrones sospechosos en los atributos URL de los bloques.
  • Wordfence (si lo tenés instalado) tiene un escáner de archivos que puede detectar código malicioso conocido, aunque no siempre captura payloads en base de datos.
  • Revisá los logs de actividad de usuarios: quién creó o editó posts con Splide Carousel y cuándo.

Si encontrás un payload inyectado, limpialo directo en la base de datos o editando el bloque y reemplazando la URL maliciosa. Después cambiá las contraseñas de todos los contribuidores como precaución.

Tabla de contexto: CVE-2026-9022 de un vistazo

DatoValor
CVE IDCVE-2026-9022
TipoStored XSS (CWE-79)
Plugin afectadoSplide Carousel Block
Versiones vulnerablesHasta 1.7.1 inclusive
Versión corregida1.7.2 o superior
CVSS v3.16.4 MEDIUM
Acceso requeridoContribuidor autenticado o superior
Acción requerida para ejecuciónEditor/admin debe publicar el contenido
VectorAV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Reportado porWordfence Intelligence

Mejores prácticas para reducir este tipo de riesgo en WordPress

Más allá de parchear este plugin específico, hay cosas que reducen la superficie de ataque en cualquier WordPress con múltiples usuarios.

Primero, auditá los roles. ¿Quién realmente necesita tener acceso de contribuidor o editor? La tendencia natural es dar más permisos de los necesarios para no tener que gestionar aprobaciones. El resultado es una lista de cuentas con acceso mayor al que corresponde. Si alguien solo necesita leer reportes o subir imágenes, no necesita rol de contribuidor.

Segundo, activá las actualizaciones automáticas para plugins. WordPress permite configurarlas plugin por plugin o globalmente. Para plugins de contenido visual como sliders o carruseles, que raramente hacen cambios que rompan el diseño, las actualizaciones automáticas son razonables.

Tercero, seguí el reporte semanal de vulnerabilidades de Wordfence Intelligence. Cada semana publican el listado de vulnerabilidades confirmadas en el ecosistema WordPress, con niveles de severidad y versiones afectadas. Es la forma más directa de enterarte antes de que alguien lo explote.

Si tu sitio está en un hosting que da acceso SSH o WP-CLI, podés automatizar la actualización de plugins y recibir notificaciones cuando hay versiones disponibles. Para hostings gestionados en Argentina, donweb.com tiene planes con WordPress preconfigurado y mantenimiento básico incluido.

Contexto: los plugins de sliders y carruseles tienen historial de este tipo de fallo

Splide Carousel Block no es el primero ni va a ser el último.

Los plugins de sliders y carruseles para WordPress tienen un patrón recurrente en vulnerabilidades: manejan atributos de URL (imágenes, enlaces, slides) y cuando el desarrollador no implementa correctamente esc_url() o wp_kses() en la salida, ese atributo se convierte en vector de inyección. Slider Revolution (el plugin comercial de Envato, con más de 9 millones de licencias vendidas) tuvo múltiples vulnerabilidades críticas en versiones anteriores, incluyendo file disclosure y remote code execution, que fueron ampliamente explotadas. Ultimate Carousel for Elementor también tuvo reportes similares de XSS en atributos de enlace. Ya lo cubrimos antes en nuestro reporte de vulnerabilidades.

El patrón no es falta de intención sino falta de proceso de revisión de seguridad. Un desarrollador independiente crea un plugin útil, lo publica, crece en instalaciones, y en algún momento alguien con ojo de seguridad lo audita y encuentra que los atributos de URL nunca tuvieron el tratamiento correcto.

La lección práctica: priorizá plugins mantenidos con releases regulares y con historial de respuesta rápida a reportes de seguridad. Un plugin que publica un fix en menos de una semana del reporte (como parece ser el caso acá) es mejor señal que uno con 50.000 instalaciones pero sin actualización desde hace 18 meses.

Qué está confirmado / Qué todavía no

  • Confirmado: La vulnerabilidad existe en versiones hasta 1.7.1, fue reportada y documentada por Wordfence Intelligence y INCIBE-CERT, y el código fuente en el repositorio de WordPress.org lo corrobora.
  • Confirmado: El fallo está en el atributo url del bloque, sin escapado correcto en la salida.
  • Confirmado: Requiere acceso autenticado de nivel contribuidor y que un editor publique el contenido.
  • No confirmado públicamente: Explotación activa masiva en sitios reales. No hay reportes verificados de campañas usando este CVE al momento de publicación.
  • No confirmado: La cantidad exacta de instalaciones activas del plugin al momento del reporte (los datos de WordPress.org se actualizan con cierto delay).

Errores comunes al gestionar este tipo de vulnerabilidad

Error 1: «El plugin tiene pocas instalaciones, no lo van a atacar.» Falso. Los scanners automatizados no discriminan por popularidad. Buscan la presencia del plugin y el número de versión. Si tu sitio tiene Splide Carousel 1.7.1 instalado y el scanner lo detecta, esa información puede terminar en una lista de targets independientemente de cuántos sitios más lo tengan. Lo complementamos en nuestro laboratorio de reproducción.

Error 2: Desactivar el plugin sin actualizar. Desactivar elimina el riesgo de ejecución de nuevos payloads, pero si ya hubo inyección antes de desactivar, el contenido malicioso sigue en la base de datos. La solución correcta es actualizar y revisar el contenido existente.

Error 3: Asumir que Wordfence o Sucuri detectan todo. Los plugins de seguridad son una capa de defensa, no un escudo completo. Un payload XSS almacenado en la base de datos como atributo de bloque puede no coincidir con las firmas de malware conocidas. La actualización del plugin sigue siendo el paso obligatorio.

Mirá también nuestro análisis sobre CVE-2026-9022.

Preguntas Frecuentes

¿Qué es CVE-2026-9022 y afecta mi sitio WordPress?

CVE-2026-9022 es una vulnerabilidad de XSS almacenado en el plugin Splide Carousel Block para WordPress, confirmada en versiones hasta 1.7.1. Afecta tu sitio si tenés ese plugin instalado en esas versiones y tenés usuarios con rol de contribuidor o superior. Si usás el plugin y no lo actualizaste, sí estás expuesto. Lo explicamos a fondo en nuestra guía de defensas adicionales contra DDoS.

¿Cómo actualizar Splide Carousel Block para solucionar la vulnerabilidad?

Desde el panel de WordPress, entrá a Plugins > Plugins instalados, buscá Splide Carousel Block y hacé clic en «Actualizar ahora» si hay una versión disponible. Verificá que la versión instalada sea 1.7.2 o superior. Si el plugin no aparece con actualización disponible, podés descargarlo manualmente desde WordPress.org y subirlo.

¿Qué riesgos tiene una vulnerabilidad XSS almacenada en WordPress?

Un XSS almacenado permite que un atacante inyecte código JavaScript que se ejecuta en el navegador de cada visitante que accede a la página infectada. Eso puede traducirse en robo de cookies de sesión (incluyendo la del admin), redirección a sitios de phishing, inyección de formularios falsos, o descarga de malware. El impacto depende de qué hace el script inyectado.

¿Cómo verificar si el plugin Splide fue explotado en mi sitio?

Revisá todos los posts y páginas con bloques Splide Carousel e inspeccioná el atributo url de cada ítem: debe comenzar con https:// o http:// apuntando a una URL legítima. Cualquier valor con javascript:, data:, o parámetros como onerror= es señal de inyección. También podés exportar el contenido como XML y buscar esos patrones en el archivo.

¿Debo desactivar Splide Carousel Block o alcanza con actualizar?

Si podés actualizar a 1.7.2 o superior de inmediato, la desactivación no es necesaria. La actualización corrige el fallo en la sanitización y elimina el vector de ataque. Solo tiene sentido desactivar si no podés actualizar en ese momento y querés eliminar el riesgo mientras tanto, pero recordá revisar igualmente el contenido existente por si ya hubo inyección previa.

Conclusión

CVE-2026-9022 es una vulnerabilidad real, con clasificación MEDIUM y vector técnico claro: atributo url sin escapado en Splide Carousel Block hasta versión 1.7.1. No es catastrófica porque requiere autenticación de contribuidor y aprobación de editor para que el payload se ejecute. Pero en cualquier sitio con más de un usuario con acceso de edición, ese umbral de riesgo es perfectamente alcanzable.

La acción concreta es simple: actualizar el plugin a la versión corregida y revisar el contenido publicado que use bloques Splide Carousel. Si no tenés ese plugin instalado, no hay nada que hacer. Si lo tenés, hacelo ahora.

Lo que muestra este caso, una vez más, es que los plugins de sliders y carruseles son una categoría con historial de fallos en manejo de URLs. No es razón para no usarlos, sino para tenerlos en la lista de plugins que requieren seguimiento activo de actualizaciones de seguridad.

Fuentes

Categorizado en: