¿Cómo saber si tu WooCommerce fue hackeado?
La mayoría de los hackeos a WooCommerce no se anuncian con una pantalla negra. Empiezan silenciosos, y para cuando son evidentes ya llevan días o semanas activos. Estas son las señales más comunes:
- Google marca tu sitio como peligroso en el navegador o en Search Console ("sitio pirateado" o "software malicioso detectado").
- Redirecciones extrañas: tus visitantes (o tú mismo) terminan en páginas de casinos, farmacia online o phishing sin haber hecho clic en nada.
- Cuentas administrador que no reconoces en Usuarios de WordPress, o accesos a horas en que nadie de tu equipo estaba trabajando.
- Errores fatales nuevos en el sitio o en la tienda (checkout caído, páginas en blanco) sin que nadie haya tocado el código.
- Contenido inyectado: texto o enlaces en idiomas raros al final de tus páginas, o archivos nuevos con nombres sin sentido en
wp-content/. - Pedidos o movimientos que no cuadran: ventas fantasma, cambios de precio o de datos de pago que nadie autorizó.
Si notas una sola de estas señales, asume que es un incidente real hasta demostrar lo contrario. Esperar "a ver si se repite" es la forma más común de dejar que un hackeo menor se convierta en uno grave.
Lo primero: qué hacer en la primera hora
🚨 Antes de llamar a nadie, haz esto
- No borres nada todavía. Si eliminas archivos o reinstalas WordPress de inmediato, puedes destruir la evidencia que explica cómo entraron — y sin eso, la vulnerabilidad real puede seguir abierta aunque "limpies" el sitio.
- Cambia la contraseña del hosting/panel de control (no solo la de WordPress) desde un equipo que sepas que está limpio.
- Revisa Usuarios → Todos los usuarios en wp-admin: si ves cuentas administrador que no reconoces, no las borres aún, solo anótalas.
- Activa modo mantenimiento si el sitio está activamente sirviendo contenido malicioso a tus visitantes (redirecciones, malware) — es peor tener el sitio arriba infectando visitas que tenerlo caído unas horas.
- Avisa a tu equipo de soporte técnico o a un especialista en seguridad WooCommerce. Cuanto antes se contenga, menor el daño.
El protocolo de respuesta a incidentes, paso a paso
Una vez contenido lo urgente, la limpieza real sigue un protocolo de 6 pasos. Saltarse alguno es la razón más común de que un sitio "limpiado" se vuelva a hackear a los pocos días:
Diagnóstico forense
Revisar los logs de acceso reales del servidor para identificar el vector de entrada exacto —credenciales filtradas, vulnerabilidad de plugin/tema/core, o falla de configuración— en vez de asumir que fue fuerza bruta. La mayoría de los hackeos a WordPress no empiezan con miles de intentos de contraseña: empiezan con una falla conocida que ya tenía parche.
Contención inmediata
Revocar credenciales y accesos comprometidos (incluyendo tokens de aplicación, no solo contraseñas) y cerrar la vía de entrada usada por el atacante, para que no pueda volver a entrar mientras se hace la limpieza.
Limpieza quirúrgica
Remover el código malicioso —backdoors, redirecciones, cuentas administrador falsas— archivo por archivo, sin reescribir el sitio completo, preservando tu configuración y tu trabajo.
Restauración verificada
Cuando hay que recuperar archivos completos, hacerlo desde un respaldo limpio confirmado —anterior a la infección— revisando cada archivo antes de subirlo a producción.
Cierre de la causa raíz
Actualizar el CMS, plugin o tema que tenía la vulnerabilidad explotada. Este paso es el que más se salta, y es el más importante: sin él, la misma puerta sigue abierta aunque el sitio se vea limpio.
Verificación final
Confirmar que el sitio funciona sin errores y sin rastros del atacante —incluyendo backdoors ocultos que no se activaron todavía— antes de dar el caso por cerrado.
Errores que empeoran un hackeo
Restaurar un backup sin verificarlo
Si el respaldo es posterior a la infección, restauras el malware junto con el sitio. Hay que confirmar la fecha real de entrada antes de elegir qué backup usar.
Limpiar solo los síntomas visibles
Borrar la redirección o el texto inyectado sin encontrar el backdoor que lo generó significa que va a volver a aparecer en días.
No actualizar la causa real
Cambiar contraseñas sin cerrar la vulnerabilidad de origen deja la puerta abierta para el mismo ataque, o para el siguiente que la encuentre.
Reinstalar todo "para estar seguro"
Sin diagnóstico previo, se pierde la evidencia de cómo entraron —y sin saber eso, no hay forma de estar seguro de que no vuelva a pasar.
Qué informe deberías exigir a quien te ayude
Una intervención de seguridad seria termina en un informe técnico, no solo en un "listo, ya quedó". Como mínimo debería incluir:
- Línea de tiempo completa del ataque, desde el primer indicio hasta la detección.
- El vector de entrada identificado, con evidencia real de los logs —no una suposición genérica de "fuerza bruta".
- El alcance exacto de lo comprometido: qué archivos, cuentas o datos fueron afectados.
- Cada acción de contención y limpieza tomada, con su verificación técnica (no solo "se limpió", sino cómo se confirmó).
- El estado de las tareas pendientes, incluyendo actualizaciones que requieren tu aprobación por su posible impacto en la operación.
Si quien te ayudó no puede explicarte cómo entraron ni mostrarte evidencia, hay una alta probabilidad de que la vulnerabilidad real siga abierta.
Buenas prácticas para que no vuelva a pasar
Checklist de prevención
- Mantener siempre actualizados el core de WordPress/WooCommerce, el tema y los plugins —la mayoría de los hackeos explota vulnerabilidades públicas que ya tienen parche disponible, no ataques sofisticados.
- Respaldos automáticos frecuentes y verificados, idealmente con control de versiones del código para detectar cualquier modificación no autorizada por fecha exacta.
- Rotación periódica de credenciales y revisión de las cuentas administrador existentes —un atacante con acceso no siempre entra con fuerza bruta, a veces basta una sesión o token robado.
- Monitoreo activo de logs de acceso y de errores, para detectar actividad anómala antes de que escale.
- Principio de mínimo privilegio: no todos los usuarios necesitan rol administrador en WordPress.
Ninguna de estas medidas es cara ni compleja. Lo que sí es costoso —en ventas, en reputación y en tiempo— es reaccionar recién cuando Google ya marcó tu sitio como peligroso.
Si necesitas ayuda ahora mismo, revisa nuestro soporte de emergencia para WooCommerce en Chile. Para una visión más amplia del soporte técnico continuo de una tienda WooCommerce, incluyendo mantención preventiva, revisa también soporte web para WooCommerce en Chile.