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

Copias Restauracion Verificacion

¿Esta copia de WordPress es suficientemente antigua para estar limpia?

Evalúa una copia anterior mediante cronología, versiones, usuarios, persistencia, registros y pruebas aisladas antes de restaurarla.

Una copia anterior a la redirección o al spam visible no está limpia automáticamente. El atacante puede permanecer silencioso, y el plugin vulnerable, la cuenta robada o la tarea maliciosa existir días antes del síntoma.

Trátala como candidata y pruébala en aislamiento.

Construye la cronología

Registra primer síntoma, login, petición, archivo o cambio MySQL sospechoso más antiguo, último evento empresarial fiable y hora de la copia. Utiliza una zona horaria.

Incluye actualizaciones, migraciones, administradores, restablecimientos y alertas. No elijas por un nombre de archivo «pre-hack». Señala los huecos de retención.

Verifica origen e integridad

Confirma qué sistema creó los archivos y la base, qué web cubre y si terminó correctamente. Registra tamaño, fecha y checksum si existe.

Guárdala fuera del webroot y limita acceso; contiene credenciales y clientes. No confíes en una copia creada por una tarea desconocida después de robarse el hosting.

Revisa componentes vulnerables

Inventaría versiones de WordPress, PHP, plugins y temas. Compáralas con requisitos y cronología de la vulnerabilidad sospechosa.

Una copia más antigua suele contener software aún más vulnerable. Puede conservar la entrada aunque no muestre payload. Reconstruye código mantenido desde paquetes actuales fiables, no ejecutes el archivo tal cual.

Inspecciona usuarios y credenciales

Revisa administradores, contraseñas de aplicación, correos, roles y cuentas de hosting o despliegue existentes en esa fecha. Busca usuarios desconocidos y recuperaciones cambiadas.

No copies hashes a informes. Considera que MySQL y APIs embebidas requerirán rotación. Contrasta con el inventario del propietario.

Busca indicadores de persistencia

Inspecciona mu-plugins, PHP en uploads o caché, wp-config.php, reglas raíz, cron, opciones y contenido de constructores.

Usa indicadores conocidos sin limitarte a un filename: puede contener un loader anterior. No ejecutes código sospechoso. Comprueba enlaces a staging y webs hermanas.

Compara además listas de archivos y hashes entre varias copias fechadas. La primera aparición de un archivo, usuario u opción ayuda a acotar el intervalo, aunque no demuestra por sí sola cuándo se explotó. Revisa también elementos que desaparecen de copias posteriores: una limpieza anterior puede haber ocultado evidencia sin cerrar la entrada.

Restaura en aislamiento

Levanta la candidata en un entorno no público sin SMTP, pagos ni webhooks reales. Bloquea callbacks e indexación.

Instala el código fiable por separado e importa base y uploads evaluados. Si debes arrancar el archivo para analizar, aplica aislamiento estricto. Nunca apuntes DNS real como primera prueba.

Revisa automatización y retención

Inspecciona la tarea, cuenta de almacenamiento e historial de restauraciones. Un hosting comprometido puede alterar calendarios, incluir archivos maliciosos o borrar copias limpias.

Verifica usuarios y tokens externos y rota accesos expuestos. Un estado «correcto» del panel no demuestra limpieza. Conserva varias candidatas fechadas mientras comparas.

Reconcilia datos posteriores

Calcula pedidos, usuarios, formularios, stock y contenido creados después. Identifica fuentes independientes como el proveedor de pagos.

No sobrescribas WooCommerce con una base vieja sin plan. Importa selectivamente datos validados y protege información personal durante la comparación.

Define criterios de aceptación

Una copia útil tiene origen fiable, precede al compromiso más antiguo plausible, permite reconstruir código, no contiene persistencia conocida y puede reconciliarse con el negocio actual.

Si no puedes demostrarlo, crea WordPress desde software fiable e importa contenido validado en vez de elegir otra copia antigua a ciegas. Documenta confianza e incertidumbre.

Define por escrito quién acepta la candidata y qué hallazgo la descartaría: un administrador desconocido, un callback externo, un componente sin soporte o discrepancias en el inventario. Así se evita seguir usando una copia solo porque restaurarla resulta más rápida.

Verifica después de recuperar

Prueba usuarios, cron, redirecciones, formularios, checkout sandbox, correo y uploads. Rota secretos y cierra la entrada antes de abrir.

Monitoriza indicadores y privilegios, y conserva evidencias según política. Si copias y pedidos se contradicen, solicita evaluación urgente compartiendo fechas e inventarios censurados, nunca archivos ni volcados 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