Base de datos corrupta tras ataque: cómo recuperar wp_users y wp_options sin perder datos
Cuando analizo un sitio WordPress comprometido, una de las situaciones más críticas que encuentro es la corrupción de la base de datos. No es solo un problema técnico: es la puerta de entrada a perder acceso administrativo, credenciales de usuarios y configuraciones vitales. En mi experiencia, la mayoría de empresas no tienen plan de recuperación y pierden horas valiosas intentando restaurar sin método.
La corrupción de wp_users y wp_options suele ser consecuencia directa de ataques de inyección SQL, backdoors mal desinstalados o intentos de fuerza bruta que generan inconsistencias en la integridad de datos. Te voy a enseñar cómo actuar cuando te encuentres con este escenario, desde el diagnóstico inicial hasta la recuperación segura.
¿Por qué se corrompen wp_users y wp_options en un ataque?
Las tablas wp_users y wp_options son el corazón de cualquier instalación WordPress. La primera almacena credenciales, roles y metadatos de usuarios; la segunda guarda configuraciones críticas como URLs, claves de seguridad y datos de plugins. Cuando un atacante ejecuta inyección SQL mal codificada o deja un backdoor que manipula datos, estas tablas son frecuentemente el objetivo.
Lo que veo en mis auditorías es que muchas veces el daño es parcial: registros huérfanos, caracteres corruptos en campos, relaciones rotas entre tablas. Esto genera errores como el famoso «error estableciendo conexión a la base de datos» o loops de redirección infinita.
Vectores de ataque comunes contra la base de datos
- Inyección SQL en plugins desactualizados: Un plugin vulnerable permite al atacante ejecutar consultas arbitrarias que modifican o borran registros.
- Backdoors que inyectan código: Scripts maliciosos que se ejecutan en cada carga de página y manipulan wp_options para insertar datos maliciosos.
- Explotación de credenciales débiles: Acceso directo al servidor de BD mediante phpMyAdmin sin protección o credenciales por defecto.
- Corrupción por falta de espacio en disco: Cuando el servidor se queda sin almacenamiento, MySQL no puede escribir correctamente y genera inconsistencias.
- Desactivación incorrecta de plugins: Código malicioso que borra datos antes de ser eliminado.
Diagnóstico inicial: cómo saber si tu base de datos está realmente corrupta
Antes de empezar a tocar nada, necesito que confirmes el estado real de la BD. Los síntomas pueden engañar. He visto casos donde el usuario creía que tenía corrupción cuando era simplemente un plugin activo malicioso.
Paso 1: Accede a phpMyAdmin o a la línea de comandos
Si tienes acceso al hosting, ingresa en phpMyAdmin (generalmente en tudominio.com/phpmyadmin). Si prefieres terminal SSH:
mysql -u tu_usuario -p tu_base_datos
Introduce tu contraseña cuando te lo pida.
Paso 2: Ejecuta una búsqueda de integridad
En la consola MySQL, ejecuta:
CHECK TABLE wp_users, wp_options, wp_usermeta;
WordPress depende también de wp_usermeta para metadatos de usuario. Si el resultado es «OK» en las tres, la corrupción física no es grave. Si ves «error» o «warning», estamos hablando de corrupción real.
Paso 3: Verifica los datos visibles
En phpMyAdmin, abre la pestaña «Explorar» de wp_users y wp_options. Busca:
- Caracteres extraños o símbolos rotos en campos de usuario o configuración.
- Registros duplicados o valores NULL inesperados.
- Opciones con claves que no reconoces (típico de malware: «malicious_option», «backdoor_settings»).
Te recomiendo hacer capturas de pantalla antes de cualquier modificación. Es tu evidencia de incidente.
Recuperación segura de wp_users sin perder acceso administrativo
La prioridad número uno es restaurar acceso administrativo legítimo. Si pierdes esto, quedarás bloqueado fuera de tu propio sitio.
Opción A: Restaurar desde backup limpio (la mejor)
Si tienes un backup de antes del ataque, este es tu camino. No intentes parches. Restaura desde cero:
- Descarga el backup completo de la BD desde tu panel de hosting o servicio de respaldo (Backwpup, UpdraftPlus, etc.).
- Crea un usuario temporal en la BD actual para tener acceso de prueba.
- Importa el backup en un entorno de prueba (staging) para verificar que funciona.
- Una vez confirmado, restaura en producción.
- Cambia todas las contraseñas de acceso FTP, MySQL y WordPress.
- Audita plugins y temas para identificar qué fue explotado.
Cuando no tengo backup disponible, que es lamentablemente común, paso a la opción B.
Opción B: Reparación de integridad con herramientas WordPress
Si la corrupción es parcial y tienes acceso al panel, usa plugins de reparación de BD certificados. Pero déjame ser claro: esto no es una solución definitiva.
En línea de comandos SSH, si tienes acceso:
wp db repair –allow-root
Este comando de WP-CLI intenta reparar inconsistencias. Luego:
wp db optimize –allow-root
Optimiza el espacio ocupado después de la reparación.
Opción C: Extrae usuarios válidos y reconstruye wp_users
Este es el método más controlado cuando la corrupción es severa. Lo que hago es:
1. Exporta los datos válidos: En phpMyAdmin, ve a wp_users, selecciona los registros de usuario legítimos (normalmente puedes identificarlos por email corporativo o antigüedad), y exporta como SQL.
2. Valida el SQL: Abre el archivo en un editor de texto. Busca caracteres rotos o líneas incompletas. Algunos editores como Sublime Text te muestran encoding issues.
3. Crea una tabla temporal limpia: En la consola MySQL:
CREATE TABLE wp_users_backup AS SELECT * FROM wp_users;
TRUNCATE TABLE wp_users;
Esto respalda los datos y vacía la tabla original.
4. Reconstruye la estructura: Elimina wp_users y crea desde zero con la definición original. Luego importa solo los registros válidos.
La clave aquí es que estás limpiando malware mientras preservas identidades de usuario legítimas.
Recuperación de wp_options: eliminar opciones maliciosas sin romper el sitio
Esta tabla es donde viven los backdoors. Un atacante suele insertar opciones como «fake_admin_user», «redirect_urls», «malware_config». Si las eliminas mal, el sitio revienta.
Identifica opciones maliciosas de forma segura
En phpMyAdmin, ordena wp_options por «option_id» descendente. Las opciones insertadas recientemente (IDs altos) suelen ser sospechosas. Busca en particular:
- option_name con palabras clave: «shell», «backdoor», «remote», «exec», «bot», «spam», «redirects».
- option_value que contenga código PHP serializado sospechoso o URLs externas.
- Opciones de plugins desinstalados que aún existen en la BD.
Cuando hago auditorías, uso una búsqueda como:
SELECT * FROM wp_options WHERE option_name LIKE ‘%shell%’ OR option_name LIKE ‘%backdoor%’ OR option_name LIKE ‘%redirect%’;
Esto te lista los sospechosos directos.
Opciones críticas que NUNCA debes tocar
Incluso si parecen extrañas, estas opciones son vitales:
- siteurl y home: URLs del sitio.
- blogname, blogdescription: Título y descripción.
- users_can_register, default_role: Configuración de usuarios.
- db_version: Versión de base de datos de WordPress.
- Cualquier opción que comience con un nombre de plugin instalado.
Mi regla: si no sabes para qué es, no la toques sin buscar primero en la documentación oficial de WordPress.
Procedimiento de limpieza de wp_options
Paso 1: Haz un backup de la tabla completa antes de empezar.
mysqldump -u tu_usuario -p tu_base_datos wp_options > wp_options_backup.sql
Paso 2: Identifica cada opción maliciosa individualmente y crea una lista.
Paso 3: Elimina una opción a la vez y verifica que el sitio siga funcionando:
DELETE FROM wp_options WHERE option_name = ‘nombre_sospechoso’;
Paso 4: Después de cada eliminación, accede al front-end de tu sitio y al admin. Si algo revienta, restaura desde el backup de opciones.
Es lento, pero seguro. Prefiero 30 minutos de cuidado a 4 horas arreglando un desastre.
Pasos posteriores a la recuperación: hardening post-ataque
Recuperar la BD es solo el primer 40% del trabajo. El otro 60% es prevenir que vuelva a pasar.
Auditoría de plugins y temas
El 85% de compromisos WordPress vienen de código de terceros desactualizado. Usando WP-CLI:
wp plugin list –allow-root
wp theme list –allow-root
Identifica qué estaba activo en el momento del ataque. Disabilitalo todo temporalmente mientras investigas. Luego:
- Actualiza a la última versión segura.
- Si no hay actualización disponible, desinstala y reemplaza por alternativa mantenida.
- Si es código custom, audítalo en busca de inyección SQL, RFI/LFI, ejecución de código.
Protege wp-config.php y el prefijo de tablas
Aunque tu BD ya esté limpia, un atacante puede volver si encuentra wp-config.php o adivina el prefijo «wp_».
Mueve wp-config.php un nivel arriba del directorio WordPress (fuera de public_html si es posible). Luego, en la parte final de wp-config.php:
$table_prefix = ‘sgx7k8_’;
Cambia a un prefijo aleatorio de 6-8 caracteres. Luego en phpMyAdmin, rebautiza todas las tablas de wp_* a sgx7k8_*. WordPress detectará el nuevo prefijo automáticamente.
Activar WordPress Security API y 2FA
En wp-config.php, añade:
define(‘FORCE_SSL_ADMIN’, true);
define(‘DISALLOW_FILE_EDIT’, true);
El segundo deshabilita la edición de archivos desde el panel, bloqueando un vector de persistencia común.
Para 2FA, instala Wordfence o iThemes Security. Ambos permiten autenticación de dos factores en wp-login.php y protegen contra fuerza bruta.
Implementa reglas .htaccess robustas
En tu archivo .htaccess raíz, añade estas líneas para bloquear acceso directo a archivos peligrosos:
# Bloquea acceso a wp-config.php
<Files wp-config.php>
order allow,deny
deny from all
</Files>
# Bloquea acceso a wp-admin excepto desde panel
<Directory ~ «^/.*wp-admin»>
order allow,deny
allow from 127.0.0.1
deny from all
</Directory>
Monitoreo continuo: detecta futuras incidencias antes de que se conviertan en corrupción
Lo que recomiendo siempre a mis clientes es monitoreo proactivo. No esperes a que explote.
Vigila cambios en wp_users y wp_options
Usa Wordfence o Sucuri para alertas de:
- Nuevos usuarios administrativos creados sin tu consentimiento.
- Cambios en URLs (siteurl, home).
- Activación de plugins maliciosos.
- Cambios en permisos de archivos.
Logs de base de datos
Si tu hosting lo permite, habilita query logging en MySQL. Esto crea un log de todas las consultas SQL ejecutadas. Cuando investigues un incidente, consultas las últimas horas y ves exactamente qué se modificó.
SET GLOBAL general_log = ‘ON’;
Advertencia: Esto consume recursos. Úsalo temporalmente durante auditorías, no en producción de forma permanente.
Backups frecuentes y verificados
No basta con tener backup. Necesitas saber que funciona. Mi protocolo:
- Backup diario de BD y files (plugin UpdraftPlus con almacenamiento en Google Drive o S3).
- Restauración de prueba semanal en staging para verificar integridad.
- Backup manual antes de cambios críticos (actualizaciones, cambios de plugins).
- Retención mínima de 30 días para poder restaurar si descubres ataque con retraso.
Cuándo llamar a un profesional de seguridad
Hay momentos donde la bricolaje se vuelve arriesgada. Si te encuentras con cualquiera de estos, contacta a un experto:
- Corrupción en múltiples tablas, no solo wp_users y wp_options.
- Inyección SQL activa: cada vez que reparas algo, vuelve a aparecer malware.
- No tienes acceso SSH o phpMyAdmin: solo panel de hosting limitado.
- El sitio genera errores PHP que no sabes interpretar.
- Sospechas que el servidor completo (no solo WordPress) está comprometido.
- Necesitas evidencia forense para reclamación a aseguradora o acción legal.
En estos casos, lo que hacemos en ManuelFolgar.com es acceso directo con análisis forense, herramientas especializadas de detección y un informe completo de qué pasó, cuándo y cómo remediarlo. Te evitamos horas de prueba-error que podrían empeorar las cosas.
Resumen: tu checklist de recuperación de BD corrupta
- Diagnostica con CHECK TABLE en MySQL.
- Si hay backup limpio, restaura en staging y verifica antes de producción.
- Si no: repara con wp db repair –allow-root o extrae usuarios válidos a tabla nueva.
- En wp_options, identifica y elimina una opción maliciosa a la vez, verificando funcionalidad cada vez.
- Audita plugins/temas y desactiva los sospechosos.
- Implementa hardening: FORCE_SSL_ADMIN, DISALLOW_FILE_EDIT, prefijo aleatorio, .htaccess restrictivo.
- Activa monitoreo y alertas (Wordfence, Sucuri).
- Establece política de backups diarios con restauración de prueba semanal.
- Planifica auditoría de seguridad completa para identificar vector de ataque original.
La corrupción de base de datos es seria, pero recuperable si actúas con método y paciencia. Lo peor que puedes hacer es entrar en pánico y ejecutar comandos sin saber qué hacen. Cada paso documentado es un paso hacia atrás en el ataque.
¿Necesitas ayuda profesional para recuperar tu WordPress tras un ataque? En ManuelFolgar.com ofrecemos análisis forense, reparación de BD y auditorías de seguridad integral. Contacta aquí para una valoración sin compromiso y te indicaré exactamente qué está pasando en tu sitio y cómo arreglarlo de forma segura.