JetEngine, el plugin de Crocoblock para contenido dinámico en WordPress, tiene dos vulnerabilidades críticas de inyección SQL que permiten a atacantes sin autenticación extraer datos de la base de datos. Los CVEs fueron reportados en el NVD el 24 de marzo y 14 de abril de 2026 respectivamente. La actualización a 3.8.6.2 o superior es la única solución confirmada.
En 30 segundos
- Dos CVEs críticos (CVE-2026-4662 y CVE-2026-4352) afectan JetEngine hasta la versión 3.8.6.1 con CVSS 9.3.
- Ambas permiten inyección SQL sin autenticación: un atacante con acceso HTTP puede extraer credenciales, emails y datos privados de la base.
- CVE-2026-4662 explota el AJAX action de Listing Grid con Load More; CVE-2026-4352 apunta al endpoint REST API de Custom Content Types.
- La solución es actualizar a JetEngine 3.8.6.2 o superior. Sin parche alternativo documentado.
- Si usás JetEngine con CCT públicos o Listing Grid con Load More, tu sitio estuvo expuesto. Revisá los logs.
Crocoblock es una empresa desarrolladora de plugins de WordPress especializada en herramientas de builder visual; JetEngine es su producto principal para crear contenido dinámico, vistas personalizadas y formularios sin código.
Qué es JetEngine y por qué importa en WordPress
JetEngine es el plugin de Crocoblock que te permite crear contenido dinámico en WordPress: Custom Post Types, Custom Content Types, Listing Grids, relaciones entre entidades, y constructores de queries SQL propios. Si trabajaste con directorios de negocios, portales de propiedades o e-commerce con catálogos personalizados, probablemente lo viste. Es el motor detrás de sitios que van más allá de las capacidades nativas de WordPress, y justamente por eso lo usa tanta gente: conecta con Elementor, Bricks y Gutenberg, y le da superpoderes de datos a cualquier instalación.
El problema con ser popular y poderoso es que también te convierte en blanco. Un plugin que tiene acceso directo al SQL Query Builder, maneja endpoints REST API públicos y procesa queries AJAX sin restricciones de rol es exactamente lo que un atacante busca cuando escanea sitios WordPress.
Dos vulnerabilidades críticas de inyección SQL en JetEngine: CVE-2026-4662 y CVE-2026-4352
No es uno, son dos agujeros distintos. Crocoblock los parcheó en el mismo ciclo, pero tienen vectores de ataque diferentes y aparecieron en el NVD en fechas separadas.
CVE-2026-4662: AJAX, HMAC bypass y el SQL Query Builder
Publicado el 24 de marzo de 2026, este CVE vive en el AJAX action que maneja el «Load More» de los Listing Grids. La arquitectura del plugin usa una firma HMAC para validar que los parámetros de la query no fueron manipulados por el cliente. El problema es que el parámetro filtered_query quedó afuera de esa validación. Resultado: podés modificarlo sin romper la firma, y el plugin lo acepta como válido.
Ahí entra el segundo problema. El método prepare_where_clause() del SQL Query Builder toma el parámetro operator y lo concatena directo en la sentencia SQL sin sanitizarlo. Combinás el HMAC bypass con la falta de sanitización, y tenés inyección SQL no autenticada. Cualquiera que llegue al endpoint AJAX puede construir un payload que se appenda a la query existente, según el análisis de SentinelOne.
CVE-2026-4352: REST API pública y Custom Content Types
Este apareció en el NVD el 14 de abril de 2026 y es más directo. El endpoint REST GET del módulo Custom Content Types acepta un parámetro search que se interpola directamente en la query SQL sin pasar por ningún mecanismo de sanitización. Si tu sitio tiene Custom Content Types con el endpoint público habilitado, cualquier persona con acceso HTTP puede mandar una solicitud GET con SQL embebido.
¿Y qué pasó cuando lo reportaron? Crocoblock soltó el parche. El tiempo que transcurre entre el descubrimiento de una vulnerabilidad y la actualización de los sitios es, en promedio, de varias semanas. Durante ese tiempo, los scanners automáticos ya están probando los payloads.
El flujo técnico de un ataque: cómo se explota
Para entender por qué esto es crítico, vale ver cómo funciona el ataque en la práctica (sin proveer código ejecutable, pero con el concepto claro).
En CVE-2026-4662, el atacante primero identifica un Listing Grid con Load More habilitado. Realiza una solicitud legítima para capturar la firma HMAC, modifica el parámetro filtered_query en el cuerpo de la solicitud AJAX, e inyecta una cláusula tipo UNION SELECT que apunta a tablas como wp_users o wp_usermeta. La respuesta del servidor devuelve los datos como si fuera contenido normal del Listing Grid (spoiler: no es contenido normal).
En CVE-2026-4352 es todavía más simple: una solicitud GET al endpoint REST de CCT con el parámetro search armado como x' UNION SELECT user_login, user_pass FROM wp_users-- - basta para extraer la tabla de usuarios completa. Sin autenticación, sin tokens, sin nada.
Lo que hace que ambas sean especialmente peligrosas es que no dejan rastros obvios en los logs de WordPress. Aparecen como requests HTTP normales al REST API o a admin-ajax.php.
Qué datos están en riesgo
Ponele que alguien explota CVE-2026-4352 contra tu sitio. ¿Qué puede llevarse?
- Credenciales de usuario:
user_loginyuser_pass(el hash bcrypt). Con el hash, se puede intentar crackeo offline. - Emails registrados: todos los
user_emailde la tablawp_users. - Metadatos de usuario: todo lo que esté en
wp_usermeta, incluyendo roles, datos de perfil, configuraciones de plugins. - Datos privados de Custom Content Types: si usás CCT para almacenar información de clientes, transacciones o formularios, eso también es accesible.
- Tokens y secrets de plugins: muchos plugins guardan tokens de API y claves en
wp_optionsowp_postmeta.
Eso sí: según el análisis técnico, la vuln es read-only. El atacante no puede modificar datos ni ejecutar comandos. Pero extraer los hashes de contraseñas y los emails ya es suficiente para comprometer una cuenta de admin si el hash es débil o si se usa la misma contraseña en otro servicio.
Cómo saber si tu sitio está afectado por la JetEngine vulnerabilidad WordPress
Versiones vulnerables: todas hasta JetEngine 3.8.6.1 inclusive. Si tenés cualquier versión anterior a 3.8.6.2, estás expuesto.
Para confirmar la versión, andá a Plugins en el dashboard de WordPress y buscá JetEngine. La versión aparece debajo del nombre del plugin. También podés revisar el archivo jet-engine/jet-engine.php directamente en el servidor.
Ahora, ¿cómo sabés si alguien ya lo explotó? Buscá en los logs de acceso (generalmente en /var/log/nginx/access.log o en cPanel) requests al endpoint REST /wp-json/jet-engine/v1/cct-search o al admin-ajax.php con action jet_engine_load_more_listing. Si ves requests con parámetros raros o con caracteres como comillas, guiones dobles o UNION en la URL o en el body, hay que investigar.
El plugin WPVulnerability que tenés instalado también debería mostrar esta vuln en el dashboard si las definiciones están actualizadas.
Guía paso a paso para actualizar JetEngine
Antes de actualizar: backup
Backup completo de base de datos y archivos. Con WPVivid, que ya tenés instalado, podés hacer una snapshot manual en dos minutos. No actualices sin backup, punto.
El proceso de actualización
- Andá a Plugins > Actualizaciones disponibles en el dashboard.
- Buscá JetEngine y actualizá a 3.8.6.2 o la versión más reciente disponible.
- Si JetEngine se actualiza por el panel de Crocoblock (licencia activa), asegurate de que el updater esté conectado correctamente.
- Después de actualizar, probá un Listing Grid con Load More y un Custom Content Type con búsqueda pública para confirmar que siguen funcionando.
- Revisá los logs de acceso del servidor para el período anterior a la actualización en busca de actividad sospechosa.
Si encontrás evidencia de explotación, el paso siguiente es resetear todas las contraseñas de usuarios (especialmente admins), revocar tokens de API de plugins conectados, y notificar a los usuarios registrados si sus emails podrían haber sido expuestos.
Medidas de seguridad más allá de la actualización
Actualizar es necesario, pero no suficiente si el sitio ya fue comprometido o si querés reducir la superficie de ataque para el futuro.
Restringir el acceso a la REST API
Si no necesitás que los endpoints de JetEngine sean públicos (accesibles sin autenticación), podés restringir el acceso con un snippet en functions.php o con un plugin de gestión de REST API. La idea es que solo usuarios autenticados puedan consultar los endpoints de CCT. Eso mata de raíz el vector de CVE-2026-4352.
Activar las reglas SQLi en Wordfence
Wordfence tiene reglas específicas para detectar patrones de inyección SQL en requests entrantes. Con la versión gratuita las reglas tienen un delay de 30 días, pero con la versión Premium las tenés en tiempo real. Si usás JetEngine en un sitio de e-commerce o con datos sensibles, vale la pena. Sucuri también tiene WAF con reglas SQLi, aunque es un servicio separado.
Monitoreo de cambios en la base de datos
Plugins como WP Activity Log o el propio log de Wordfence pueden alertarte si hay cambios en usuarios o si se crean admins inesperados. Es el indicador post-explotación más claro: si alguien extrajo credenciales y las crackeó, el siguiente movimiento es crear un usuario admin.
Para el hosting, si estás en un servidor con acceso a logs en tiempo real, configurar alertas sobre requests al REST API con payloads sospechosos es una capa extra que vale el tiempo de configuración. Si tu hosting no tiene esa opción, considerá moverse a infraestructura con más visibilidad, como los planes de donweb.com que incluyen acceso a logs de servidor.
Tabla comparativa: CVE-2026-4662 vs CVE-2026-4352
| Aspecto | CVE-2026-4662 | CVE-2026-4352 |
|---|---|---|
| Vector de ataque | AJAX action (admin-ajax.php) | REST API GET endpoint |
| Módulo afectado | Listing Grid con Load More + SQL Query Builder | Custom Content Types (CCT) |
| Condición de explotación | Listing Grid con Load More habilitado y SQL Query Builder activo | CCT con endpoint REST público |
| Técnica | HMAC bypass + operator sin sanitizar en prepare_where_clause() | Parámetro search interpolado directamente en SQL |
| Autenticación requerida | No | No |
| Publicado en NVD | 24 de marzo de 2026 | 14 de abril de 2026 |
| Versiones afectadas | Hasta 3.8.6.1 | Hasta 3.8.6.1 |
| Impacto | Lectura de datos de la BD | Lectura de datos de la BD |
Errores comunes al responder a este tipo de vulnerabilidad
Error 1: Asumir que el sitio está seguro porque no tiene datos «importantes». La tabla wp_users siempre tiene datos importantes: contraseñas hasheadas, emails, roles. Con eso alcanza para un ataque de phishing dirigido o para intentar acceso a otros servicios donde se reuse la contraseña.
Error 2: Actualizar el plugin sin revisar si ya hubo explotación. Si actualizás y no revisás los logs de las semanas anteriores, cerrás la puerta pero no sabés si alguien ya entró. La actualización cierra la vuln, no revierte el daño.
Error 3: Desactivar JetEngine como «medida preventiva» sin actualizar. Desactivar el plugin mientras el sitio sigue corriendo no es suficiente si hay caché de endpoints REST activa (LiteSpeed Cache, que tenés instalado, puede servir respuestas cacheadas). La solución correcta es actualizar y limpiar el caché.
Preguntas Frecuentes
¿Qué es la vulnerabilidad de inyección SQL en JetEngine?
Son dos fallas (CVE-2026-4662 y CVE-2026-4352) en el plugin JetEngine de Crocoblock que permiten a atacantes no autenticados insertar código SQL malicioso en las queries de la base de datos. El resultado es que pueden extraer cualquier información almacenada en la BD de WordPress, incluyendo usuarios, contraseñas hasheadas y datos de plugins. Afectan todas las versiones hasta la 3.8.6.1.
¿Está mi sitio WordPress afectado por CVE-2026-4662?
Tu sitio está afectado si usás JetEngine versión 3.8.6.1 o anterior, tenés un Listing Grid con «Load More» habilitado, y ese Listing Grid usa SQL Query Builder como fuente de datos. Si alguna de esas tres condiciones no se cumple, CVE-2026-4662 específicamente no aplica, aunque CVE-2026-4352 puede aplicar igual si tenés Custom Content Types públicos.
¿Cuál es la diferencia entre CVE-2026-4662 y CVE-2026-4352?
CVE-2026-4662 explota el sistema AJAX de Listing Grid mediante un bypass de validación HMAC que permite modificar parámetros de query sin ser detectado. CVE-2026-4352 apunta al endpoint REST API de Custom Content Types, donde el parámetro de búsqueda se concatena directo en SQL sin sanitizar. Diferentes vectores, mismo resultado: lectura no autorizada de la base de datos.
¿Es urgente actualizar JetEngine ahora?
Sí. Ambas CVEs tienen CVSS 9.3 (crítico) y no requieren autenticación, lo que significa que cualquier scanner automático puede detectar y explotar sitios vulnerables. Desde que se publicaron en el NVD (marzo y abril de 2026), los scripts de explotación circulan en comunidades de seguridad ofensiva. La actualización a 3.8.6.2 o superior es inmediata y no debería romper funcionalidad.
Cómo proteger JetEngine de ataques SQL injection más allá de la actualización
Con el plugin actualizado, el siguiente nivel es restringir los endpoints REST API de CCT a usuarios autenticados si no necesitás acceso público, y activar las reglas WAF de Wordfence con detección de SQLi. Monitorear los logs de acceso para requests al endpoint /wp-json/jet-engine/ con parámetros inusuales te permite detectar intentos de explotación a futuro.
Conclusión
Dos CVEs críticos en JetEngine, ambos no autenticados, ambos con CVSS 9.3. La «innovación» de tener un SQL Query Builder propio dentro de un plugin WordPress tiene este costo: cuando hay un error de sanitización, la superficie de ataque es enorme porque el plugin tiene acceso directo a la base de datos por diseño.
Lo que cambió con esta divulgación es que los sitios con JetEngine 3.8.6.1 o anterior quedaron marcados. Los scanners automáticos ya están probando estos endpoints. Si todavía no actualizaste, hacelo hoy: backup, actualización a 3.8.6.2+, verificación de funcionalidad, revisión de logs. En ese orden.
¿Alguien verificó de forma independiente el alcance real de la explotación en la vida real? Todavía no hay números públicos de sitios comprometidos, pero con CVEs de este calibre y esta popularidad del plugin, la pregunta no es si alguien lo explotó sino cuántos.