BetterDocs Pro sufre una inyección SQL sin autenticación (CVE-2026-4348): todas las versiones hasta la 3.7.0 del plugin están expuestas a una vulnerabilidad crítica que permite a cualquier atacante, sin credenciales, extraer datos sensibles de la base de datos WordPress a través del parámetro limit en dos acciones AJAX del módulo Encyclopedia.
En 30 segundos
- Plugin afectado: BetterDocs Pro ≤ 3.7.0 — actualizar a 3.7.1 o superior es la única solución definitiva.
- Sin credenciales: el atacante no necesita estar logueado; basta con acceso HTTP al sitio.
- Condición de explotación: la feature «Encyclopedia» debe estar habilitada en los settings de BetterDocs Pro.
- Datos en riesgo: usuarios, hashes de contraseñas, emails, tokens y cualquier dato en la base de datos WordPress.
- CVSS 7.5: calificación alta según CIRCL Vulnerability Lookup, con impacto en confidencialidad.
BetterDocs es un plugin de WordPress desarrollado por wpsuperiors para crear y organizar documentación de productos. Proporciona funcionalidades para gestionar bases de conocimiento interactivas con búsqueda y categorización en sitios WordPress.
¿Qué es BetterDocs Pro y por qué actualizar importa?
BetterDocs Pro es un plugin premium para WordPress que permite crear bases de conocimiento y sistemas de documentación interna o pública. Lo usan sitios de producto, SaaS, y cualquier empresa que quiera tener una sección de ayuda organizada sin depender de servicios externos. Con más de 40.000 instalaciones activas, no es un plugin marginal.
El problema con plugins de esta escala es simple: cuantos más sitios lo usan, más atractivo es el objetivo. Una vulnerabilidad en BetterDocs Pro no afecta a un sitio puntual sino a decenas de miles. Y cuando esa vulnerabilidad es de SQL injection sin autenticación, el panorama se complica bastante.
CVE-2026-4348: inyección SQL sin autenticación en BetterDocs Pro
SQL injection es una de las vulnerabilidades más antiguas del desarrollo web y sigue siendo una de las más peligrosas. Básicamente, ocurre cuando el código toma un dato que viene del usuario y lo mete directamente en una consulta SQL, sin validarlo ni sanitizarlo. El resultado: el atacante puede «romper» la estructura de la query original y agregarle sus propias instrucciones.
En BetterDocs Pro, el problema está en cómo se maneja el parámetro limit dentro de dos acciones AJAX: get_current_letter_docs y docs_sort_by_letter. Según la ficha oficial del CVE, este parámetro POST se interpola directamente en la cadena SQL antes de ser pasado a $wpdb->prepare(). Ese «antes» es todo el problema: $wpdb->prepare() solo parametriza las variables que recibe explícitamente, no lo que ya está incrustado en el string. Entonces el limit llega a la query sin ningún tipo de escape.
El CVSS asignado es 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Traducido: acceso remoto, sin complejidad especial, sin privilegios, sin interacción del usuario, con impacto alto en confidencialidad. No toca integridad ni disponibilidad, pero robar datos ya es suficientemente grave.
¿Quién corre riesgo? Requisitos técnicos para ser explotable
Tres condiciones tienen que darse al mismo tiempo:
- BetterDocs Pro instalado y activo en versión 3.7.0 o anterior.
- La feature «Encyclopedia» habilitada en los settings del plugin.
- El sitio accesible por HTTP/HTTPS (osea, cualquier sitio en producción).
La condición de la Encyclopedia es un matiz importante. No todos los usuarios activan esa feature, pero es una funcionalidad estándar del plugin que muchos habilitan para organizar la documentación por letra. No es una opción avanzada ni experimental. Eso significa que el porcentaje de sitios realmente vulnerables dentro del universo de instalaciones activas probablemente sea alto.
¿Y qué pasó cuando lo probaron en producción con la feature deshabilitada? En ese caso la vulnerabilidad no es explotable. Pero deshabilitar la Encyclopedia es un workaround, no una solución.
Cómo funciona el ataque: el flujo técnico
El flujo de explotación es directo. Ponele que tenés un sitio con BetterDocs Pro 3.7.0 y la Encyclopedia activada. Un atacante manda una request POST a /wp-admin/admin-ajax.php con estos parámetros:
action=get_current_letter_docslimit=999 UNION SELECT user_login, user_pass, user_email FROM wp_users--
El plugin toma ese valor de limit y lo pega directamente en la query SQL original. Sin sanitización previa, la query resultante ya no es la que escribió el desarrollador de BetterDocs sino una query híbrida que incluye un UNION SELECT que el atacante controló. La respuesta devuelve los datos del UNION: nombres de usuario, hashes de contraseñas, emails.
No requiere sesión activa. No requiere conocer el prefijo de las tablas (se puede descubrir por otras técnicas). No requiere nada más que acceso HTTP al sitio.
También es posible usar técnicas basadas en tiempo (time-based blind SQLi) para extraer datos incluso si la respuesta no devuelve resultados directamente, aunque el vector de UNION SELECT es más simple y rápido si funciona.
Qué datos están en riesgo real
Con acceso a la base de datos vía SQL injection, un atacante puede extraer prácticamente cualquier cosa que esté almacenada ahí. Lo más obvio y valioso:
- wp_users: nombres de usuario y hashes de contraseñas (MD5 o bcrypt según la configuración). Con un hash débil y rainbow tables, recuperar la contraseña original no lleva más de unas horas.
- Emails de todos los usuarios, incluyendo administradores, editores y suscriptores.
- wp_usermeta: roles de usuario, preferencias, tokens de sesión.
- Datos de WooCommerce si está instalado: direcciones, historial de pedidos, datos de clientes.
- wp_options: configuraciones del sitio, claves de API guardadas en la base de datos (muchos plugins las guardan ahí), secretos de autenticación de WordPress.
Eso sí: la explotación exitosa depende de que el atacante pueda leer la respuesta AJAX. Si hay algún tipo de restricción en las respuestas (rate limiting, WAF), el proceso se complica. Pero sin protecciones adicionales, una base de datos WordPress entera puede vaciarse en minutos.
Cómo verificar si tu sitio está vulnerable
Cuatro pasos, en orden:
- Revisar la versión del plugin: en el panel de WordPress, ir a Plugins y buscar BetterDocs Pro. Si la versión es 3.7.0 o anterior, el sitio es vulnerable. 3.7.1 o superior significa que ya está parcheado.
- Verificar si Encyclopedia está habilitada: en el dashboard de WordPress, ir a BetterDocs > Settings > Documentation y buscar la opción «Encyclopedia» o «Letter Archive». Si está activa y el plugin está sin actualizar, el riesgo es inmediato.
- Revisar logs de acceso: buscar en los logs de Apache o Nginx requests a
/wp-admin/admin-ajax.phpque contengan patrones comoUNION,SELECT,OR 1=1, o--. Si aparecen esos patrones, alguien ya lo intentó (o lo probó). - Escanear con Wordfence: si tenés Wordfence instalado, correr un scan manual desde Wordfence > Scan puede detectar versiones de plugins con vulnerabilidades conocidas.
Solución definitiva: actualizar a BetterDocs Pro 3.7.1
La solución es actualizar. No hay debate. Paso a paso:
- Backup primero: antes de tocar cualquier plugin, hacer un backup completo de base de datos y archivos. WPVivid, UpdraftPlus, o cualquier herramienta que uses habitualmente.
- Actualizar el plugin: ir a Dashboard > Plugins > Actualizaciones disponibles y actualizar BetterDocs Pro a 3.7.1 o superior. La versión 3.7.1 incluye el fix según el changelog oficial del plugin.
- Verificar que la actualización completó sin errores: WordPress avisa si algo falló durante la actualización. Si todo salió bien, confirmar que la versión en el listado de plugins dice 3.7.1.
- Probar funcionalidad: revisar que la base de conocimiento sigue funcionando correctamente, especialmente el módulo de Encyclopedia si lo usabas activo.
Si usás un hosting con panel de control que gestiona actualizaciones de WordPress, como los planes gestionados de donweb.com, revisá si tienen actualizaciones automáticas de plugins habilitadas. En casos como este, esa feature paga el costo de instancia en un solo incidente prevenido.
Medidas de protección temporal mientras esperás actualizar
Si por alguna razón no podés actualizar de inmediato (freeze de cambios, entorno de staging, pruebas de regresión), hay opciones intermedias:
| Medida | Efecto | Complejidad |
|---|---|---|
| Deshabilitar Encyclopedia en settings | Elimina el vector de explotación | Baja |
| WAF (Cloudflare, Sucuri) | Bloquea patrones SQLi en requests | Media |
| Desactivar BetterDocs Pro temporalmente | Elimina toda la superficie de ataque | Baja (si el sitio lo tolera) |
| Rate limiting en admin-ajax.php | Dificulta ataques automatizados | Media-Alta |
La opción más efectiva sin tocar el plugin: deshabilitar la Encyclopedia. Si tu sitio no la usa activamente o si podés prescindir de ella por 24-48 horas mientras organizás la actualización, es el workaround más limpio.
Un WAF con reglas de SQL injection (Cloudflare tiene esto en el plan gratuito para patrones básicos) agrega una capa de defensa adicional que vale independientemente de esta vulnerabilidad puntual. No es el sustituto de actualizar, pero compra tiempo.
Errores comunes al responder a este tipo de vulnerabilidad
Pensar que «si no está explotado todavía, puedo esperar»
Desde que se publica un CVE con CVSS 7.5 y vectores técnicos detallados, los scripts automatizados que escanean sitios buscando ese patrón específico empiezan a circular en horas. No días. El tiempo entre «publicación del CVE» y «primers intentos de explotación masiva» se redujo dramáticamente. Esperá y aumentás la ventana de riesgo sin ningún beneficio concreto.
Creer que deshabilitar la Encyclopedia es suficiente a largo plazo
Es un workaround válido para ganar tiempo, pero el código vulnerable sigue instalado. Si en algún momento volvés a habilitar la Encyclopedia sin haber actualizado, el riesgo reaparece. Y si alguien más en el equipo activa la feature sin saber del CVE, el workaround se cae solo. La única solución real es actualizar a 3.7.1.
No revisar los logs después de parchear
Si tu sitio estuvo expuesto por días o semanas antes de que te enteraras del CVE, actualizar el plugin cierra la puerta pero no te dice si alguien ya entró. Después de parchear, revisá los logs de admin-ajax.php buscando patrones de SQLi y, si encontrás algo sospechoso, hacé una auditoría de la base de datos. Cambiá credenciales de administrador y regenerá los secretos de WordPress si hay dudas.
Preguntas Frecuentes
¿Cómo afecta CVE-2026-4348 a mi sitio WordPress con BetterDocs?
Si tenés BetterDocs Pro en versión 3.7.0 o anterior con la Encyclopedia habilitada, cualquier visitante del sitio (sin necesitar login) puede explotar la vulnerabilidad para extraer datos de tu base de datos WordPress. Esto incluye usuarios, contraseñas hasheadas, emails y cualquier dato almacenado en la BD. Actualizando a 3.7.1, la vulnerabilidad queda corregida.
¿Estoy vulnerable si uso BetterDocs Pro 3.7.0?
Sí, si además tenés la feature «Encyclopedia» activa en los settings del plugin. Podés verificarlo en BetterDocs > Settings > Documentation dentro de tu panel de WordPress. Si la Encyclopedia está deshabilitada, el vector de explotación específico de este CVE no es alcanzable, aunque lo más seguro igual es actualizar a 3.7.1.
¿Qué datos pueden robar con inyección SQL en BetterDocs?
Un atacante que explota CVE-2026-4348 puede acceder a toda la base de datos de WordPress: nombres de usuario y hashes de contraseñas de la tabla wp_users, emails, datos de clientes WooCommerce si está instalado, y valores de wp_options que suelen incluir claves de API y configuraciones sensibles de plugins.
¿Cómo actualizar BetterDocs Pro a la versión 3.7.1?
Desde el panel de WordPress, ir a Plugins > Actualizaciones disponibles y actualizar BetterDocs Pro. Antes de actualizar, hacé un backup completo de base de datos y archivos. La versión 3.7.1 incluye el parche para este CVE según el changelog oficial del plugin en betterdocs.co.
¿Qué hago mientras no puedo actualizar BetterDocs Pro?
La medida más efectiva es deshabilitar la Encyclopedia en los settings de BetterDocs Pro, lo que elimina el vector de explotación puntual de este CVE. Como capa adicional, activar un WAF (Cloudflare en su plan gratuito incluye reglas básicas contra SQLi) bloquea muchos intentos automatizados. Ninguna de estas opciones reemplaza actualizar a 3.7.1.
Conclusión
CVE-2026-4348 es un recordatorio de por qué mantener los plugins actualizados no es una recomendación opcional sino una práctica de seguridad básica. BetterDocs Pro falló en un punto de validación específico: interpolar datos del usuario en una query SQL antes de sanitizarlos, un error que existe desde los primeros años del desarrollo web y que sigue apareciendo en código de plugins con decenas de miles de instalaciones.
La escala aquí importa. Con 40.000+ sitios usando el plugin, incluso si solo una fracción tiene la Encyclopedia habilitada, el número absoluto de sitios vulnerables es significativo. Y con un CVSS de 7.5 publicado con detalles técnicos completos, los intentos de explotación automatizada empiezan a aparecer rápido.
La acción concreta es una: actualizar a BetterDocs Pro 3.7.1 hoy. Si no podés hacerlo de inmediato, deshabilitar la Encyclopedia y activar un WAF compra tiempo. Pero solo tiempo.