¿Tu WordPress es vulnerable a inyección SQL? Descubrilo

La inyección SQL en WordPress es la técnica de ataque que permite a un atacante manipular las consultas a la base de datos de un sitio, accediendo a información sensible o tomando control total del sistema. Solo en los primeros meses de 2026, se reportaron vulnerabilidades críticas de SQL injection en plugins con más de 400.000 instalaciones activas, lo que confirma que este vector sigue siendo uno de los más explotados contra sitios WordPress.

Qué es la inyección SQL y por qué WordPress es un blanco frecuente

Una inyección SQL es un tipo de ataque donde un actor malicioso inserta código SQL dentro de un campo de entrada (un formulario, un parámetro de URL, un endpoint de la REST API) que la aplicación procesa sin validar. Cuando ese input llega a la base de datos sin sanitización, el atacante puede leer, modificar o borrar cualquier dato almacenado.

WordPress es un objetivo particularmente atractivo por varias razones estructurales. El código es open source, lo que significa que cualquiera puede estudiar el esquema de la base de datos. Las tablas tienen nombres predecibles: wp_users, wp_options, wp_posts. Un atacante que conoce WordPress ya sabe dónde buscar las credenciales de administrador sin necesidad de explorar.

Pero el core de WordPress no es el problema principal. El equipo de desarrollo de WordPress mantiene el núcleo razonablemente seguro. El verdadero riesgo está en los plugins de terceros. Según el análisis de Patchstack sobre SQL injection, la gran mayoría de las vulnerabilidades SQLi reportadas en el ecosistema WordPress provienen de plugins y themes, no del core. Con más de 60.000 plugins en el repositorio oficial, la superficie de ataque es enorme. Y SQL injection se mantiene firme en el OWASP Top 10 como una de las vulnerabilidades más críticas y explotadas a nivel global.

Tipos de inyección SQL que afectan a WordPress

No todas las inyecciones SQL funcionan igual. Dependiendo de cómo responda la aplicación, el atacante elige una técnica distinta. Conocer los tipos te ayuda a entender qué buscar en tus logs y qué reglas de firewall priorizar.

In-band (clásica)

Es la más directa. El atacante inyecta SQL y obtiene el resultado en la misma respuesta HTTP. Por ejemplo, si un plugin muestra resultados de búsqueda sin sanitizar el parámetro, el atacante puede hacer que la query devuelva el contenido de wp_users directamente en la página. Es rápida de explotar y fácil de detectar en logs porque las respuestas cambian visiblemente.

Union-based

Variante de la in-band que usa UNION SELECT para combinar la consulta original con una consulta del atacante. Si un plugin hace SELECT nombre FROM productos WHERE id = $_GET['id'], el atacante puede inyectar 1 UNION SELECT user_pass FROM wp_users y obtener hashes de contraseñas junto con los resultados legítimos. Requiere que el atacante conozca la cantidad de columnas de la query original.

Ciega booleana (boolean-based blind)

Acá el atacante no ve datos directamente, pero puede hacer preguntas de sí o no. Inyecta condiciones como AND 1=1 (verdadero) o AND 1=2 (falso) y observa si la página cambia. Letra por letra, puede reconstruir contraseñas y emails. Es más lenta pero funciona incluso cuando la aplicación no muestra errores SQL.

Ciega basada en tiempo (time-based blind)

Cuando ni siquiera hay diferencia visual entre verdadero y falso, el atacante usa SLEEP(5). Si la página tarda 5 segundos más en responder, la condición era verdadera. Es el tipo más lento de explotar, pero el más difícil de detectar porque no deja rastro visible. El CVE-2025-9807 en The Events Calendar fue exactamente este tipo: una inyección time-based blind que permitía extraer datos sin generar errores.

Vulnerabilidades de inyección SQL recientes en plugins WordPress (2025-2026)

Los primeros meses de 2026 trajeron una ola preocupante de CVEs de SQL injection en plugins con bases de usuarios masivas. No son plugins oscuros con 200 instalaciones: estamos hablando de herramientas que usan cientos de miles de sitios en producción.

El caso de Ally es particularmente grave: según Security Affairs, la vulnerabilidad permitía a un atacante no autenticado ejecutar consultas arbitrarias en la base de datos, comprometiendo potencialmente los 400.000 sitios que lo tenían instalado. El de Profile Builder Pro (CVE-2026-27413) y el de WowStore (CVE-2026-2579) siguen el mismo patrón: inputs de usuario que llegan a queries SQL sin pasar por prepare().

Lo que me preocupa de esta tendencia es que son errores básicos. No estamos hablando de vulnerabilidades sofisticadas de race condition o deserialización. Es falta de sanitización elemental en 2026. Eso habla de un problema sistémico en cómo se desarrollan plugins para WordPress.

Cómo funciona un ataque de inyección SQL paso a paso

Sin entrar en territorio de tutorial de explotación, es importante que entiendas el flujo para poder defenderte. Un ataque típico de SQLi contra WordPress sigue estas etapas:

Reconocimiento: el atacante identifica que el sitio usa WordPress (es trivial: basta ver /wp-login.php o el meta tag generator). Luego enumera plugins activos usando herramientas como WPScan o simplemente revisando el código fuente en busca de rutas como /wp-content/plugins/nombre-plugin/.

Identificación del punto de entrada: busca formularios, parámetros GET/POST y endpoints de la REST API que interactúen con la base de datos. Un parámetro como ?order_id=123 en un plugin de ecommerce es candidato inmediato.

Prueba de inyección: inserta un carácter como comilla simple (') y observa si la respuesta cambia o muestra un error SQL. Si la página devuelve algo como You have an error in your SQL syntax, el punto es vulnerable.

Explotación: dependiendo del tipo de SQLi disponible, extrae datos de wp_users (usuario admin + hash de contraseña), modifica wp_options para cambiar la URL del sitio o el email del admin, o directamente inserta un usuario administrador nuevo. Con acceso admin a WordPress, subir una webshell es cuestión de segundos.

Un ejemplo concreto y simplificado: imaginá un plugin de membresía que hace SELECT * FROM wp_users WHERE user_login = '$input'. Si alguien ingresa admin' OR '1'='1 en el campo de login, la query se convierte en SELECT * FROM wp_users WHERE user_login = 'admin' OR '1'='1', que siempre es verdadera. Bypass de autenticación instantáneo.

7 medidas para prevenir inyecciones SQL en WordPress

La prevención no es un solo paso, es una combinación de capas. Si una falla, la siguiente debería frenar el ataque. Estas son las medidas concretas que funcionan:

• Usá wpdb->prepare() en toda query con input externo. Es la defensa número uno. Si desarrollás plugins o themes, esta función parametriza las consultas y escapa los valores automáticamente. No hay excusa para no usarla.
• Validá y sanitizá cada input. sanitize_text_field() para texto, intval() para números, absint() para IDs. Si esperás un número y recibís una string con comillas, algo anda mal.
• Mantené plugins y core actualizados. El 90% de las vulnerabilidades SQLi de la tabla anterior ya tienen parche disponible. El problema es que miles de sitios nunca actualizan.
• Usá un Web Application Firewall (WAF). Wordfence, Sucuri o Cloudflare filtran patrones conocidos de SQLi antes de que lleguen a PHP. No es infalible, pero frena ataques automatizados.
• Aplicá el principio de mínimo privilegio en la base de datos. El usuario MySQL de WordPress no necesita permisos de DROP, CREATE o GRANT. Limitá los permisos a SELECT, INSERT, UPDATE, DELETE sobre su propia base.
• Desactivá y borrá plugins que no usés. Un plugin desactivado pero presente en el servidor sigue siendo accesible. Si no lo usás, eliminalo.
• Monitoreá logs de queries sospechosas. Activá el query log de MySQL temporalmente o usá un plugin de auditoría. Buscá patrones como UNION SELECT, SLEEP(, OR 1=1 en las queries registradas.

wpdb->prepare(): la defensa nativa de WordPress contra SQLi

WordPress incluye desde hace años una función diseñada específicamente para prevenir inyecciones SQL, y es sorprendente cuántos desarrolladores de plugins la ignoran. $wpdb->prepare() funciona como un sistema de consultas parametrizadas: separás la estructura SQL de los datos.

Así se ve el código incorrecto (vulnerable):

$wpdb->query("SELECT * FROM wp_users WHERE ID = " . $_GET['user_id']);

Y así se ve la versión correcta:

$wpdb->query($wpdb->prepare("SELECT * FROM wp_users WHERE ID = %d", $_GET['user_id'])); Si te interesa, podés leer más sobre el ataque a Trivy en GitHub Actions.

Los placeholders %d (entero), %s (string) y %f (float) le dicen a WordPress qué tipo de dato esperar. La función escapa automáticamente cualquier carácter peligroso. Si alguien manda 1 OR 1=1 como user_id, %d lo convierte a 1 y descarta el resto.

El problema, como señala el equipo de Wordfence en su guía para encontrar vulnerabilidades SQLi, es que muchos desarrolladores de plugins construyen queries concatenando strings directamente, especialmente en funciones de búsqueda, filtros y ordenamiento. A veces lo hacen por desconocimiento, a veces por apuro. El resultado es siempre el mismo: una puerta abierta.

Si mantenés un plugin o theme custom, hacé un grep de tu código buscando $wpdb->query y $wpdb->get_results que no estén envueltos en $wpdb->prepare(). Cada instancia que encuentres es una vulnerabilidad potencial.

Plugins de seguridad que detectan y bloquean inyecciones SQL

Un WAF a nivel de aplicación es la capa de defensa más efectiva después del código seguro. Estos son los plugins que ofrecen protección específica contra SQLi:

Wordfence

El firewall de Wordfence incluye reglas específicas para detectar patrones de SQL injection en parámetros GET, POST y cookies. La versión premium recibe actualizaciones de reglas en tiempo real cuando se descubre un nuevo CVE. La versión gratuita recibe las mismas reglas con 30 días de delay. Además, el módulo de escaneo revisa el código de plugins instalados en busca de funciones vulnerables.

Sucuri Security

Sucuri opera como un WAF a nivel de DNS (reverse proxy), lo que significa que el tráfico malicioso ni siquiera llega a tu servidor. Esto es una ventaja frente a Wordfence, que filtra a nivel de PHP (el request ya llegó al servidor). Para sitios con mucho tráfico o ataques frecuentes, esa diferencia importa. El plan de firewall incluye virtual patching: cuando se publica un CVE, Sucuri puede bloquear la explotación antes de que el plugin publique el parche.

Patchstack

Patchstack se enfoca específicamente en vulnerabilidades de plugins y themes. Mantiene la base de datos de CVEs de WordPress más completa que conozco y ofrece virtual patching automático. Cuando se reporta un SQLi en un plugin que tenés instalado, Patchstack aplica una regla de firewall temporal mientras esperás el parche oficial. Para agencias que manejan muchos sitios WordPress, es una herramienta imprescindible.

WP-Firewall

Opción más liviana, enfocada exclusivamente en firewall. Filtra patrones de SQLi, XSS y path traversal. No tiene la profundidad de escaneo de Wordfence ni la red de Sucuri, pero si buscás algo que consuma pocos recursos y haga bien una sola cosa, cumple.

Qué hacer si tu WordPress ya fue comprometido por SQL injection

Si sospechás o confirmás que tu sitio fue víctima de SQLi, estos son los pasos en orden de prioridad:

• Poné el sitio en modo mantenimiento inmediatamente. No lo dejés online mientras investigás. Cada minuto que pasa es un minuto donde el atacante puede profundizar el acceso.
• Revisá la tabla wp_users. Buscá usuarios con rol administrator que no reconozcas. Si hay alguno nuevo, el atacante ya tiene acceso al panel. Eliminalo y cambiá todas las contraseñas de admin.
• Revisá los logs de acceso del servidor (access.log y error.log de Apache/Nginx). Buscá requests con patrones sospechosos: comillas simples, UNION, SELECT, SLEEP en parámetros de URL.
• Verificá la integridad de archivos. Compará los archivos de tu instalación con los originales de WordPress usando wp core verify-checksums de WP-CLI. Cualquier archivo modificado en wp-includes o wp-admin es sospechoso.
• Cambiá las credenciales de la base de datos (usuario y contraseña MySQL en wp-config.php). Si el atacante exfiltró la base, ya tiene las credenciales viejas.
• Restaurá desde un backup limpio que sea anterior a la fecha del ataque. Verificá que el backup no esté también comprometido revisando las tablas de usuarios.
• Actualizá todo: core, plugins, themes. El vector de entrada original probablemente fue un plugin desactualizado.
• Notificá a tus usuarios si la tabla wp_users fue comprometida y contiene datos personales. Dependiendo de la jurisdicción, podés tener obligación legal de hacerlo.

Si tu sitio está alojado en un hosting que ofrece backups automáticos (en Donweb, por ejemplo, los planes incluyen backups diarios), la restauración es mucho más rápida. Sin backup, la limpieza manual puede llevar horas y nunca tenés 100% de certeza de que quedó limpio.

Si querés ahondar en esto, revisá Building a Vulnerability Knowledge Base — Would Love Feedbac.

Qué significa para empresas y equipos en Latinoamérica

En la región, una parte importante de los sitios WordPress corren en hosting compartido con configuraciones por defecto. Los usuarios de MySQL suelen tener todos los permisos habilitados, los plugins se actualizan con delay (o nunca), y muchos sitios no tienen ningún WAF activo. Eso convierte a los sitios latinoamericanos en objetivos fáciles para ataques automatizados de SQLi que barren internet buscando plugins vulnerables conocidos.

Para agencias y freelancers que manejan sitios de clientes, la recomendación es clara: implementá un WAF, automatizá las actualizaciones de seguridad y auditá cualquier plugin custom que uses. El costo de prevenir es insignificante comparado con el de limpiar un sitio comprometido y explicarle al cliente que su base de datos fue exfiltrada.

Errores comunes

«Mi sitio es chico, nadie me va a atacar». Los ataques de SQLi son automatizados. Un bot no distingue entre un sitio con 100 visitas y uno con 100.000. Si tenés un plugin vulnerable, te van a encontrar. Las herramientas de escaneo masivo como SQLMap recorren millones de sitios buscando patrones vulnerables sin discriminar por tamaño.

«Tengo Wordfence, así que estoy protegido al 100%». Un WAF reduce enormemente el riesgo, pero no lo elimina. Las reglas de firewall se basan en patrones conocidos. Un atacante que descubra un zero-day en un plugin puede usar técnicas de evasión que el WAF todavía no reconoce. El WAF es una capa, no la solución completa. Necesitás código seguro, actualizaciones y monitoreo.

«Uso prepared statements en algunas queries, con eso alcanza». Si tenés 50 queries en tu plugin y solo 45 usan prepare(), las 5 restantes son 5 vulnerabilidades. Un atacante necesita un solo punto de entrada. La consistencia es clave: todas las queries que reciben input externo, sin excepción, deben usar prepare() o equivalente.

«Escapar comillas con addslashes() es lo mismo que prepare()». No. addslashes() tiene problemas conocidos con encodings multibyte (como UTF-8 mal configurado) que permiten bypasear el escape. wpdb->prepare() usa mysqli_real_escape_string() internamente, que respeta el charset de la conexión. No son equivalentes y addslashes() no debería usarse para prevenir SQLi.

Preguntas Frecuentes

¿Qué es una inyección SQL y cómo afecta a un sitio WordPress?

Una inyección SQL es un ataque donde se inserta código SQL malicioso en campos de entrada de una aplicación web para manipular su base de datos. En WordPress, permite a un atacante leer la tabla wp_users (con emails y hashes de contraseñas), crear usuarios administradores falsos, modificar contenido publicado o borrar la base de datos completa. La mayoría de los ataques SQLi en WordPress explotan vulnerabilidades en plugins, no en el core.

¿Cómo puedo proteger mi WordPress contra inyecciones SQL?

Las tres medidas más efectivas son: mantener todos los plugins y el core actualizados (la mayoría de los CVEs tienen parche disponible en días), instalar un WAF como Wordfence o Sucuri que filtre patrones de SQLi, y asegurarte de que cualquier código custom use $wpdb->prepare() para todas las consultas con input de usuario. Complementá con permisos mínimos en el usuario MySQL y eliminación de plugins que no uses.

¿Cómo saber si mi WordPress fue víctima de una inyección SQL?

Las señales más claras son: usuarios administradores que no creaste en la tabla wp_users, contenido modificado sin tu intervención, redirecciones a sitios externos y requests sospechosos en los logs de acceso con patrones como UNION SELECT, comillas simples o SLEEP( en parámetros de URL. Herramientas como Wordfence Scan o Sucuri SiteCheck pueden hacer una verificación automatizada.

¿Qué hace wpdb->prepare() y por qué es clave contra SQL injection?

$wpdb->prepare() es la función nativa de WordPress para crear consultas SQL parametrizadas. Separa la estructura de la query de los datos usando placeholders (%s para strings, %d para enteros), y escapa automáticamente cualquier carácter peligroso antes de ejecutar la consulta. Esto hace que sea técnicamente imposible inyectar SQL a través de un valor procesado por prepare(), siempre que se use correctamente.

Conclusión

La inyección SQL sigue siendo, en 2026, una de las formas más efectivas de comprometer un sitio WordPress. Los CVEs recientes en plugins como Ally, Profile Builder Pro y WowStore demuestran que el problema no es teórico: son vulnerabilidades reales en plugins que usan cientos de miles de sitios. Y el patrón se repite siempre: queries SQL construidas con concatenación directa en lugar de usar prepare().

La buena noticia es que defenderse no requiere conocimientos avanzados. Actualizá plugins, usá un WAF, y si desarrollás código custom, usá wpdb->prepare() en cada query que toque input de usuario. Si administrás sitios de clientes, agregá monitoreo de la tabla wp_users como rutina. El próximo CVE crítico de SQLi es cuestión de semanas, no de meses. La pregunta no es si va a aparecer, sino si tu sitio va a estar preparado cuando lo haga.

¿Cómo detectar si mi WordPress es vulnerable a inyección SQL?

El primer signo es un error SQL en la página o en los logs. También podés revisar si los plugins tienen actualizaciones de seguridad pendientes, usar herramientas como WPScan para escanear vulnerabilidades conocidas, y habilitar logs de base de datos para ver consultas sospechosas.

¿Cuál es la mejor forma de prevenir inyecciones SQL en WordPress?

Usá siempre wpdb->prepare() con placeholders en tus queries. Si no escribís código, mantené los plugins y WordPress actualizados, usa un firewall como Wordfence o Sucuri, y realiza auditorías periódicas del código de plugins sospechosos.

¿Qué hago si mi WordPress fue comprometido por inyección SQL?

Lo primero es aislar el sitio (tomar offline si es necesario). Revisa la tabla wp_users para detectar usuarios no autorizados, restaura desde un backup anterior al ataque verificado, cambia todas las contraseñas, y audita los plugins instalados para encontrar la vulnerabilidad explotada.

¿Cómo puedo proteger mi sitio WordPress contra inyección SQL?

La defensa principal es usar wpdb->prepare() con placeholders en toda query que reciba input del usuario. Además, instalá un firewall como Wordfence o Sucuri que bloquee patrones maliciosos, actualiza plugins regularmente y validá/sanitizá todo input en formularios y endpoints de API.

¿Mi WordPress está vulnerable a ataques SQL injection?

El core de WordPress es relativamente seguro, pero plugins y themes de terceros pueden introducir vulnerabilidades. Revisá los CVEs de tus plugins, mantené todo actualizado y usá herramientas como WPScan para auditorías. Si ya fuiste comprometido, restaurá desde un backup limpio verificado.

¿Qué plugins de seguridad protegen contra SQL injection?

Wordfence, Sucuri y Patchstack ofrecen firewalls con reglas específicas contra inyección SQL, detectando y bloqueando patrones maliciosos antes de que lleguen a tu base de datos. Tu hosting también puede proporcionar WAF como LiteSpeed o CloudFlare como capas de defensa adicionales.

Fuentes

• Security Affairs – Vulnerabilidad crítica de SQL injection en plugin Ally que afecta a 400.000 sitios WordPress
• Patchstack – Guía completa sobre SQL injection en WordPress
• Wordfence – Cómo encontrar vulnerabilidades de SQL injection en plugins y themes de WordPress
• OWASP – SQL Injection Prevention Cheat Sheet (referencia técnica)
• Kinsta – Guía sobre SQL injection y WordPress