El código desconocido en el checkout, las cuentas de administración alteradas o los pedidos ausentes tras una restauración urgente requieren un plan que cubra tanto el ataque como los registros de venta. Que cargue la home solo resuelve una parte de la evaluación.
Contener el ataque antes de aceptar más pedidos
Si el checkout puede exponer a clientes a código desconocido, valora pausar ese recorrido de venta mientras se conservan las pruebas. Anota el primer aviso, las URL afectadas, los cambios recientes de acceso y cualquier restauración ya realizada. No repitas pagos con tarjeta real para comprobar si ha desaparecido el síntoma.
La investigación puede incluir archivos, contenido de la base, cuentas con privilegios, tareas programadas y accesos relevantes al hosting o al despliegue. Las capas afectadas determinan el alcance; vaciar la caché no permite dar por eliminado un ataque.
Recuperar la tienda sin rebobinar pedidos a ciegas
Antes de elegir una copia, compara su fecha con el incidente y la actividad comercial reciente. Identifica qué almacenamiento de pedidos estaba activo, qué capturas posteriores existen y qué registros de pago o entrega pueden apoyar la conciliación.
Una base antigua puede omitir pedidos nuevos. Un cargo no conserva necesariamente toda la cesta. La recuperación debe distinguir registros validados de datos desconocidos y evitar cobrar otra vez, descontar stock dos veces o repetir avisos al cliente.
Comprobar pagos y pedidos como partes distintas del recorrido
Un pago capturado con un pedido pendiente o ausente puede deberse a la entrega del callback, errores al procesarlo, un cambio de almacenamiento o una restauración. El estado del pedido no identifica por sí solo la causa. Contrasta pruebas de la pasarela y de la aplicación antes de modificarlo.
Si la pasarela lo permite, acuerda una prueba en sandbox que cubra creación del pedido, confirmación del pago, stock, entrega a logística y correo transaccional. Si hace falta una comprobación real, concreta antes sus límites y autorización; las compras de clientes no deben convertirse en una prueba sin control.
Acordar qué debe entregar la recuperación
La propuesta debe concretar contención, conservación de pruebas, reparación justificada, conciliación de pedidos si procede y comprobaciones antes de reabrir. Restaurar una copia e importar pedidos son operaciones distintas y tienen riesgos diferentes.
El cierre documenta lo encontrado, lo cambiado, los recorridos probados y lo que queda sin resolver. La falta de registros puede limitar la recuperación. Disponibilidad, plazos y presupuesto se confirman tras evaluar; esta página no promete recuperar todos los pedidos ni evitar cualquier ataque futuro.
Solicitar una evaluación con el periodo afectado
Envía la URL, las horas del primer aviso y de la restauración con su zona horaria, el recorrido afectado, una estimación de pedidos ausentes y si el checkout está pausado. Describe qué capturas y pruebas de la pasarela o de logística existen, sin adjuntar esos registros.
Empieza con una descripción, no con accesos. No envíes exportaciones de clientes, tarjetas, contraseñas ni bases comprometidas por el formulario público. Si hace falta evidencia detallada, se acordará un canal seguro una vez definido el alcance.
Solicitar una evaluación de WooCommerce hackeado
- Qué hacer si una restauración elimina pedidos recientes de WooCommerce
- Restaurar WordPress sin reintroducir la intrusión
RECUPERACIÓN WORDPRESS BASADA EN EVIDENCIA
Pruebas y criterios de aceptación de la recuperación
La evaluación relaciona el posible ataque con las funciones y los registros de la tienda que están en riesgo. El alcance acordado determina qué capas e integraciones se revisan.
Qué comprobamos
- Cronología del incidente y la restauración, URL afectadas y contención aplicada
- Código, cuentas y persistencia relevantes dentro del alcance acordado
- Capturas de pedidos y pruebas de pago o entrega disponibles
- Pruebas controladas de checkout, callbacks, stock y notificaciones
- Hallazgos documentados, registros sin resolver y responsables de reapertura
Qué significa un resultado verificado
El cierre distingue contención, correcciones realizadas y pruebas que apoyan el recorrido de venta comprobado. Quedan explícitos los pedidos sin resolver, las dependencias de acceso y las tareas posteriores. Superar una prueba no demuestra haber recuperado todos los pedidos históricos.
ANTES DE LA EVALUACIÓN
Preguntas frecuentes sobre esta incidencia
¿Restaurar una copia recupera todos los pedidos pagados?+
No necesariamente. Una copia anterior puede omitir pedidos recientes y los registros de pago pueden carecer del detalle de la cesta o la entrega. Primero se evalúan las capturas y las pruebas independientes para acordar qué se puede recuperar.
¿Un pedido pendiente demuestra que ha fallado el webhook de pago?+
No. Puede haber problemas de entrega del callback, errores al procesarlo, cambios de almacenamiento o una restauración de la base. Hay que contrastar los registros de la pasarela y la aplicación antes de cambiar el estado o repetir el pago.
¿Se puede verificar el checkout sin un cargo real?+
Se prefiere un sandbox compatible para las pruebas controladas. Si una comprobación exige una transacción real, se acuerdan antes el alcance y la autorización. La prueba en sandbox tiene límites y no demuestra todos los recorridos de producción.
¿Cuándo puede empezar el trabajo y cuánto costará?+
La evaluación inicial concreta urgencia, pruebas disponibles, accesos necesarios y trabajo propuesto. Disponibilidad, plazos y presupuesto se confirman antes de intervenir; enviar la solicitud no autoriza por sí solo un cargo.