Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Confirmar Contener Incidente

El login WordPress funciona pero todas las contraseñas han cambiado

Recupera acceso revisando cambios de cuentas, propiedad del email, integridad de base, sesiones y control del hosting.

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.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia