Si varias contraseñas conocidas fallan a la vez, puede haber compromiso, sustitución de la base, fallo de autenticación o conexión a otra instalación. Restablecer una cuenta solo sirve cuando web y canales de control son confiables.
Recupera mediante evidencias del hosting y base desde un dispositivo limpio.
Descarta otra instalación
Comprueba host canónico, URL WordPress, nombre de base y prefijo. Un cambio DNS o despliegue puede mostrar staging o una restauración con usuarios distintos.
Registra cuándo empezó y migraciones, restores, PHP o plugins recientes. No repitas contraseñas hasta bloquear cuentas. Confirma certificado y dominio antes de introducir credenciales.
Compara el ID de instalación, versiones y una muestra de usuarios con la copia esperada. Si el sitio apunta a otra base, no resetees allí cuentas creyendo reparar producción. Corrige DNS o wp-config.php mediante el despliegue autorizado y conserva ambos estados para reconciliar contenido creado durante el desvío.
Protege email y hosting
Desde otro equipo verifica email del propietario, registrar/DNS y panel. Cambia credenciales expuestas, revoca sesiones y activa MFA.
Un atacante con email puede repetir resets; con hosting puede reemplazar archivos o datos después de reparar WordPress. No uses enlaces recibidos en un buzón no verificado.
Revisa reglas de reenvío, direcciones de recuperación y eventos del email. Quien conserva recuperación puede deshacer cada cambio.
Comprueba también tokens OAuth, contraseñas de aplicación del correo, dispositivos recordados y delegaciones. Cambiar la contraseña principal no siempre revoca esos accesos. Registra y elimina solo los no autorizados conforme al proceso del proveedor.
Conserva evidencia de cuentas
Guarda IDs, roles, emails, metadatos de application passwords y logs de acceso. Registra logins correctos/fallidos alrededor del incidente.
No exportes hashes ni toda la tabla a un ticket. Toma snapshot protegido antes de cambios directos y comprueba si aparecieron administradores desconocidos.
Inspecciona autenticación
Plugins de seguridad, SSO, LDAP o login propio pueden cambiar autenticación sin alterar hashes. Revisa updates, errores PHP y logs.
En staging protegido, aísla la capa manteniendo archivos originales. No renombres todos los plugins en producción cuando checkout y seguridad dependen de ellos. Mantén una cuenta propietaria fuera del SSO cuando la política lo permita.
Determina si el formulario llega al autenticador y qué error devuelve sin registrar la contraseña. Un WAF, rate limit o bloqueo por IP puede presentar «credenciales incorrectas» a todos. Compara el login estándar, SSO y WP-CLI autorizado para separar transporte, plugin y datos.
Comprueba la base
Confirma que WordPress lee users/usermeta previstos. Busca emails administrativos cambiados, capabilities, hashes actualizados masivamente y actividad del usuario MySQL.
Usa lecturas precisas y compara con backup conocido. Una diferencia masiva es evidencia, no motivo para copiar hashes antiguos. Revisa si credenciales MySQL quedaron en backups públicos.
Verifica fecha y origen de la copia de comparación. Un backup posterior al incidente no es estado limpio y uno demasiado antiguo puede carecer de usuarios legítimos. Compara IDs, emails, roles y patrón de cambio de hashes sin exportar sus valores.
Recupera un propietario verificado
Usa hosting, WP-CLI o método de base acotado para resetear un administrador previamente verificado. Registra la acción.
No crees un administrador oculto ni envíes contraseña en claro. Usa secreto temporal único, entra una vez desde navegador limpio, establece contraseña fuerte y MFA. Revoca todas las sesiones.
Después de recuperar, genera nuevos salts/keys solo cuando hayas evaluado el impacto y estés preparado para cerrar todas las sesiones. Actualiza también integraciones que usen application passwords de forma legítima mediante secretos individuales y documentados.
Busca persistencia
Inspecciona checksums, mu-plugins, tareas, wp-config.php, uploads/caché ejecutables y cron. Código malicioso puede resetear contraseñas o recrear cuentas.
Revisa DNS, correo y usuarios del hosting como el mismo incidente. Preserva antes de retirar y reconstruye código no confiable en lugar de editar el payload visible.
Verifica funciones
Confirma administradores, roles, application passwords y emails aprobados. Prueba login/logout, reset, formularios, checkout y correo transaccional.
Monitoriza cambios privilegiados y fallos tras abrir. Concilia pedidos/leads del periodo.
Prueba durante al menos un ciclo de cron y varias peticiones que la contraseña y el email no vuelven a cambiar. Alerta sobre resets masivos, edición de propietarios y nuevas application passwords.
Solicita recuperación urgente si email, hosting y WordPress no coinciden. Acredita propiedad por el proceso del host, nunca con dumps, hashes o tokens públicos.