🛒Cómo proteger tu tienda WooCommerce de hackers en 2026: guía completa

Un jueves a las 3 de la mañana, el sitio de Ana — una tienda de ropa infantil en Bogotá — dejó de procesar pagos. A las 7 de la mañana, cuando abrió el negocio, su pantalla de WooCommerce mostraba productos con precios cambiados, usuarios administradores que ella nunca creó, y una carpeta uploads/ con archivos PHP que no tendrían que estar ahí. Ana tardó 14 horas en entender qué pasó, 3 días en limpiar el sitio, y 2 semanas en recuperar la confianza de los clientes que vieron cargos extraños en sus tarjetas. Pérdida estimada: seis semanas de ventas.

No es un caso aislado. WooCommerce es la plataforma de e-commerce más usada del mundo, lo que la vuelve el blanco preferido de ataques automatizados que escanean miles de sitios por hora buscando la misma puerta abierta. Y la puerta abierta no suele ser un zero-day sofisticado: suele ser un plugin desactualizado, una contraseña débil, un archivo PHP olvidado en uploads/, o un permiso mal configurado.

Esta guía te muestra los 7 vectores reales de ataque que afectan a tiendas WooCommerce en 2026, cómo cerrarlos uno por uno, y qué hacer en las primeras 30 minutos si detectás que algo raro está pasando.

El panorama real: qué ataca tu tienda todos los días

Hay una imagen romántica del hacker — un tipo encapuchado, persiguiendo tu negocio específicamente, horas de trabajo manual para entrar. La realidad es más aburrida y más peligrosa: la mayoría de los ataques son automatizados. Bots que corren 24/7 escaneando millones de sitios, probando los mismos exploits de siempre, entrando al primero que tenga la puerta abierta.

Según los reportes anuales de Sucuri y Wordfence, los vectores más comunes contra WooCommerce son:

• Plugins vulnerables desactualizados. Entre el 55% y 60% de los sitios WordPress hackeados tenían al menos un plugin con vulnerabilidad pública conocida y sin parchear.
• Fuerza bruta contra /wp-admin. Un sitio nuevo recibe en promedio 50-200 intentos de login por día desde IPs distribuidas globalmente.
• Webshells subidos a wp-content/uploads/. Archivos PHP disfrazados de imágenes que dan acceso remoto al servidor.
• Skimmers tipo Magecart inyectados en el checkout para robar tarjetas de crédito silenciosamente.
• Credential stuffing reutilizando contraseñas filtradas de otras brechas.
• SQL injection en formularios mal validados (menos común pero más destructivo).
• Supply chain attacks — un plugin legítimo que alguien compró, lo comprometió, y actualizó con código malicioso.

Ninguno de estos vectores requiere un atacante genial. Requieren que vos no cierres la puerta.

Los 5 errores que dejan la puerta abierta

Antes de hablar de soluciones, hablemos de las causas. En el 90% de los sitios hackeados que revisamos, uno (o varios) de estos cinco errores estaban presentes.

1. Plugins y themes desactualizados

WordPress y los plugins populares sacan actualizaciones de seguridad cada pocas semanas. Cuando aparece una vulnerabilidad pública (CVE), los bots empiezan a escanear sitios con esa versión vulnerable dentro de las 24 horas. Si tu tienda tarda 2 semanas en actualizar, hay una ventana donde estás expuesto a algo que ya se sabe cómo explotar.

Qué hacer: activá actualizaciones automáticas para parches menores. Para mayores (que pueden romper compatibilidad), programá revisiones mensuales y actualizá en ventana de bajo tráfico con backup previo.

2. Contraseñas débiles o reutilizadas

La contraseña del admin de tu tienda es la llave maestra. Si es administrador2024, ana123, o la misma que usás en Gmail (que ya fue filtrada en alguna brecha), no importa cuántos plugins de seguridad tengas — el atacante entra con la puerta principal y con permisos completos.

Qué hacer: contraseña única de 16+ caracteres para cada sitio, generada por un gestor de contraseñas (Bitwarden, 1Password). 2FA activado para el admin. Usuarios de staff sin permisos de manage_options a menos que los necesiten.

3. Permisos de archivos incorrectos

En un servidor Linux, los permisos de archivos controlan quién puede leer, escribir o ejecutar. Si tu wp-config.php tiene permiso 777 (cualquiera lee y escribe), cualquier proceso comprometido puede robar tus credenciales de base de datos y adueñarse de la tienda.

Qué hacer: directorios en 755, archivos en 644, wp-config.php en 600. La mayoría de hostings decentes lo hacen bien, pero siempre vale verificar. Drako audita esto al activarse.

4. No monitorear cambios

Si un atacante inyecta código en tu functions.php o sube un webshell en uploads/, tu sitio puede seguir funcionando aparentemente normal durante semanas. Vos no tenés forma de saberlo sin un sistema que compare los archivos contra una línea base confiable.

Qué hacer: monitoreo de integridad con hashes SHA-256. Cuando un archivo cambia sin tu autorización, recibís alerta inmediata. Drako lo hace cada 6 horas por default, ajustable a cada hora.

5. Backups sin verificar

Tener backup es bueno. Tener backup funcional y limpio es lo que importa. Muchos dueños de tienda descubren a la mitad de una crisis que: a) el backup está corrupto, b) el backup tiene malware que estaba en el sitio hace días, c) nadie probó nunca restaurar y no saben cómo.

Qué hacer: backup automático diario (UpdraftPlus, Backuply, el que tengas), con verificación mensual — restaurás en un staging y comprobás que funcione. Hashes del backup para verificar integridad. Retención de al menos 30 días.

Hardening en 7 capas: qué hacer exactamente

Un sitio razonablemente protegido no depende de un solo muro alto — depende de 7 capas superpuestas, cada una cerrando un tipo específico de ataque.

Capa 1: Security headers HTTP

Los headers HTTP le dicen al navegador cómo comportarse. Bien configurados, previenen XSS, clickjacking, y fuga de referrers.

Los esenciales: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy restrictivo, y Content-Security-Policy permisiva (CSP estricta rompe plugins; empezá permisiva y ajustá).

Capa 2: .htaccess restringido

El archivo .htaccess controla Apache/LiteSpeed a nivel servidor. Tres reglas críticas:

• Deshabilitar listing de directorios: Options -Indexes.
• Bloquear acceso directo a wp-config.php: con <Files wp-config.php> Deny from all </Files>.
• Bloquear ejecución de PHP en /wp-content/uploads/: regla crítica, cierra el vector más común de webshells.

Capa 3: Protección de login

Limitar intentos fallidos a 5 en 15 minutos bloquea fuerza bruta automatizada. Renombrar /wp-login.php a una URL custom (opcional) reduce el ruido de bots. 2FA obligatorio para admins.

Capa 4: Desactivar XML-RPC

XML-RPC es un protocolo viejo que WordPress dejó prendido por compatibilidad. En 2026, casi nadie lo usa legítimamente, pero sigue siendo vector de ataques de amplificación y brute force distribuido. Desactivalo — si tu app móvil lo rompe, lo re-activás selectivamente.

Capa 5: Monitoreo de integridad

SHA-256 de cada archivo crítico, comparado cada N horas contra la línea base. Si alguien modifica functions.php sin que vos lo hayas actualizado, te enterás. Si aparece un archivo nuevo en uploads/ con extensión .php, lo sabés.

Capa 6: Análisis con IA

Las capas 1-5 son hardening tradicional — funcionan, pero solo contra amenazas conocidas. Un malware nuevo sin firma pública puede pasar inadvertido por Wordfence, Sucuri o iThemes. Un motor de IA especializado en código — Drokio Colmillo, auto-hosteado en la infraestructura de Drokio con prompts y knowledge base propios — lee el código y entiende si parece un backdoor, un skimmer o una actualización legítima.

Capa 7: Cuarentena automática

Detectar no alcanza. Cuando el análisis confirma malware con alta confianza, el archivo debe quedar aislado inmediatamente — antes de que se ejecute, antes de que comprometa más archivos, antes de que vos leas el email. La cuarentena mueve el archivo a una carpeta no ejecutable y guarda metadata para revisión.

Cómo detectar si ya te hackearon (y la tienda parece normal)

La mayoría de los sitios comprometidos no tienen síntomas visibles en el front público. El atacante no quiere llamar la atención — quiere usar tu sitio como infraestructura: enviar spam, minar criptomonedas, servir malware a otros, o esperar el pico de tráfico para robar tarjetas en el checkout.

Señales que indican posible compromiso:

• Usuarios administradores que no recordás haber creado (revisá /wp-admin/users.php).
• Posts o páginas nuevas que no escribiste, en muchos casos escondidos como "privados".
• Picos raros de tráfico a archivos específicos en uploads/ (revisá logs de Apache/Nginx).
• Emails salientes desde tu dominio que no mandaste (chequeá con tu hosting).
• Lentitud inexplicable — minería de criptomonedas consume CPU.
• Google Search Console marca el sitio como "engañoso" o "con malware".
• Tu checkout tiene dominios de terceros cargando scripts que vos no agregaste (revisá con DevTools → Network en una compra de prueba).

Drako detecta automáticamente la mayoría de estos patrones: usuarios nuevos, archivos PHP en uploads/, cambios sin autorización, y código sospechoso en archivos del core.

Tu plan de 30 minutos

Si estás empezando de cero, podés pasar de "sitio completamente expuesto" a "razonablemente protegido" en media hora. Orden recomendado:

Minutos 0-5: Backup limpio

Antes de tocar nada, un backup completo. Si el sitio ya está comprometido (cosa que vas a saber en los próximos 25 minutos), necesitás un punto de referencia. UpdraftPlus, Backuply, WP Vivid — cualquiera sirve, pero que sea reciente y completo.

Minutos 5-15: Contraseñas y 2FA

Cambiá la contraseña del admin principal. Contraseña nueva de 16+ caracteres, única, guardada en gestor. Activá 2FA (plugin Two Factor o similar). Revisá la lista de usuarios — si hay alguno que no reconocés, sospechá y borralo (después de confirmar que no es legítimo).

Minutos 15-25: Hardening automático

Instalá Drako (o tu plugin de preferencia) y activalo. Las 7 capas se aplican por default. Configurá tu email y número de WhatsApp para alertas. Ejecutá el scan inicial.

Minutos 25-30: Verificación

Revisá que el sitio funciona normalmente en el front. Hacé una compra de prueba para validar que el checkout no rompió. Confirmá que recibiste el email de bienvenida del plugin. Si todo OK, tenés una línea base.

Esto es el 80% del trabajo de seguridad. El 20% restante es mantener la disciplina: revisar alertas cuando lleguen, actualizar plugins cuando salga la notificación, rotar contraseñas cada 6 meses.

Qué hacer si Drako (u otro sistema) detecta algo sospechoso

Llegó el mensaje. "Archivo modificado en wp-content/themes/tu-theme/functions.php". Respirá. No entres en pánico, pero tampoco lo ignores por una semana.

Si Drako ya puso el archivo en cuarentena (severidad crítica, confianza alta): verificá el sitio — si funciona normal, la cuarentena te salvó. Revisá el archivo en cuarentena desde el dashboard, confirmá que es malicioso, y marcá como resuelto.

Si es una alerta de sospechoso pero no cuarentena (confianza media): revisá el archivo. ¿Vos lo modificaste? ¿Hubo actualización reciente de theme/plugin que lo tocó? Si sí, aprobá el cambio. Si no — ese archivo no debería haber cambiado — tratalo como incidente real.

Si es patrón de ataque (fuerza bruta, escaneo agresivo): no hay que hacer nada urgente; Drako ya bloqueó la IP. Revisá logs al día siguiente para ver si es campaña dirigida (mismas IPs + patrones específicos contra tu sitio) o ruido de fondo (IPs distintas, patrones genéricos).

Cierre

La seguridad perfecta no existe — cualquier plugin que te la prometa está mintiendo. Lo que sí existe es seguridad razonable: cerrar las 7 puertas que los bots usan para entrar el 95% de las veces. Eso lo podés lograr con disciplina manual (2 horas por semana) o con una herramienta que lo automatice y agregue una capa de IA para amenazas nuevas.

WooCommerce es una plataforma fantástica para vender online, pero viene con responsabilidad: cada día que tu tienda está online sin hardening, estás apostando. La apuesta suele salir bien — hasta que no.