PrestaShop hackeado: qué hacer en la primera hora (y cómo evitar que vuelva)

Tu tienda manda a otras webs, Google o el navegador la marcan como peligrosa, tu alojamiento te avisa de un virus o un cliente te dice que el pago «le salió raro». Esto es lo que hay que hacer, en este orden, para proteger a tus clientes y que no vuelvan a entrar.

Señales de que tu PrestaShop está hackeado

• Redirecciones a otras webs, a veces solo en el móvil o solo cuando se llega desde Google, para que tú no lo veas desde tu ordenador.
• Avisos de Google o del navegador: «Este sitio puede haber sido pirateado» en los resultados, o una pantalla roja antes de entrar. En Search Console aparece en el informe Problemas de seguridad.
• Un formulario de pago distinto o un paso de más al pagar. Es el ataque más caro: en 2022, PrestaShop avisó de que se estaba usando un fallo para colocar un formulario de pago falso en el proceso de compra y quedarse con los datos de las tarjetas.
• Ficheros que no son tuyos: PHP con nombres raros en la carpeta principal (en ese ataque se llamaba blm.php), o en carpetas donde solo debería haber imágenes.
• Empleados o módulos que no has creado en el panel.
• Correos de spam enviados desde tu servidor, o tu alojamiento suspende la cuenta.
• La tienda en blanco o con error 500 de repente, sin que nadie haya tocado nada.

Si lo que ves son clientes nuevos que nunca compran, suscriptores raros o mensajes basura en el formulario de contacto, no suele ser un hackeo: son bots que rellenan los formularios. Lo tienes en cómo parar el spam y los registros falsos.

Qué hacer en la primera hora

1. Protege a tus clientes. Pon la tienda en modo mantenimiento para que nadie compre (ni meta su tarjeta) mientras se revisa. Si sospechas del pago, avisa a tu banco o a tu pasarela de pago.
2. Guarda una copia de cómo está ahora: ficheros, base de datos y los registros de acceso del servidor (los pide tu alojamiento). No es para restaurarla: es la prueba de por dónde entraron. Guárdala fuera del servidor.
3. Cambia todas las contraseñas, desde un ordenador limpio: las de todos los empleados del panel, la del alojamiento, la del FTP o SFTP, la de la base de datos y la del correo de la tienda.
4. Revisa los empleados del panel (Parámetros avanzados → Equipo) y elimina los que no reconozcas.
5. Mira si hay datos personales afectados. Si los hay, el RGPD obliga a notificarlo a la Agencia Española de Protección de Datos sin dilación y, si es posible, en 72 horas desde que lo sabes (artículo 33), salvo que sea improbable que suponga un riesgo para las personas. Y si el riesgo es alto, también hay que avisar a los clientes afectados (artículo 34).

Por qué restaurar una copia antigua no basta

Es lo primero que se le ocurre a todo el mundo, y deja la tienda limpia unos días. Pero una copia de antes del ataque tiene el mismo agujero por el que entraron: si no se cierra, vuelven. Y si la copia es de hace semanas, pierdes los pedidos y los clientes de esas semanas. La copia sirve, pero dentro de una limpieza, no en lugar de ella.

Cómo se limpia de verdad

1. Encontrar la puerta. En los registros de acceso del servidor suele verse el patrón: una petición a un módulo y, segundos después, un fichero nuevo al que el atacante empieza a llamar. Es justo el patrón que describió PrestaShop en el ataque de 2022.
2. Comparar los ficheros con los originales. Se descarga la versión exacta de tu PrestaShop y de tus módulos y se compara fichero a fichero: lo que no coincide y no es tuyo, sobra. PrestaShop pone un index.php en casi cada carpeta para que no se pueda ver su contenido; cualquier otro PHP en carpetas de imágenes o de subidas es sospechoso.
3. Revisar la base de datos, no solo los ficheros: código insertado en descripciones, en páginas de contenido o en la configuración, empleados creados por el atacante y ajustes cambiados. En el ataque de 2022 se usaba la caché de plantillas en la base de datos, una opción que casi nadie usa y que el atacante podía activar.
4. Cerrar el agujero. Actualizar PrestaShop y todos los módulos, y quitar (borrar la carpeta, no solo desactivarlo) cualquier módulo que no uses o que ya no tenga quien lo mantenga.
5. Vigilar las semanas siguientes por si queda algo: ficheros nuevos, empleados nuevos o cambios en el proceso de pago.

Por qué entran en un PrestaShop

• Versiones sin parches. PrestaShop publica sus avisos de seguridad en su repositorio oficial: 61 hasta hoy. La última versión de la 1.7, la 1.7.8.11, es de enero de 2024. Desde entonces se han publicado 13 avisos más, 2 de ellos críticos, y la 1.7 ya no recibe ninguna corrección. El último crítico, de mayo de 2026, permitía hacerse con el panel con un simple mensaje enviado desde el formulario de contacto, en cuanto un empleado lo abría. Solo se corrigió en la 8.2.6 y la 9.1.1.
• Módulos con fallos. Muchos ataques entran por un módulo de terceros, no por PrestaShop. La asociación Friends of Presta publica los fallos de seguridad de módulos que va encontrando, incluidos módulos cuyo fabricante ha desaparecido y que no tendrán arreglo.
• Contraseñas y accesos. Contraseñas repetidas, el FTP sin cifrar o accesos de antiguos proveedores que nadie quitó.
• Un PHP viejo. Si tu PrestaShop es antigua, tu PHP probablemente también, y tampoco recibe parches. Lo explicamos en qué versión de PHP necesita tu PrestaShop.

Si Google ha marcado tu tienda como peligrosa

Mientras el aviso esté puesto, casi nadie entra: Google lo enseña en los resultados y el navegador muestra una pantalla de advertencia. Para quitarlo:

1. Entra en Search Console, en Seguridad y acciones manuales → Problemas de seguridad, y mira qué ha detectado y en qué páginas.
2. Limpia todas las páginas afectadas, no solo las del ejemplo: Google pide que el problema esté resuelto en todo el sitio.
3. Pulsa Solicitar revisión y explica qué pasó, qué has hecho y cómo lo has comprobado.

Según Google, la revisión tarda de varios días a varias semanas. Si la pides antes de terminar la limpieza, la siguiente puede tardar más.

Cómo evitar que vuelva a pasar

• PrestaShop y módulos al día, probando las actualizaciones antes en una copia.
• Fuera los módulos que no usas, y revisar de vez en cuando los avisos de seguridad de los que sí.
• Copias de seguridad guardadas fuera del servidor y restauradas de prueba alguna vez.
• Una cuenta por persona en el panel, con contraseñas distintas, y quitar los accesos de quien ya no trabaja contigo.
• Alguien que mire los avisos de seguridad por ti. Es una de las cosas que hacemos en el mantenimiento PrestaShop.

Cuándo merece la pena que lo hagamos nosotros

• Rescate de tienda PrestaShop: limpieza, cierre del agujero y vuelta a vender. Desde 149 €, y entre 199 y 490 € según la gravedad. Empezamos el mismo día laborable.
• Migración a PrestaShop 9: si la tienda está en una versión sin parches, limpiarla y dejarla igual es comprar tiempo. Desde 390 €.
• Mantenimiento PrestaShop: actualizaciones probadas en una copia, copias de seguridad fuera del servidor y alguien vigilando los avisos de seguridad. Desde 79 €/mes.

Preguntas frecuentes

Fuentes, consultadas el 24 de octubre de 2026: avisos de seguridad de PrestaShop, aviso de PrestaShop sobre el ataque de julio de 2022, avisos de módulos de Friends of Presta, informe «Problemas de seguridad» de Google y Reglamento General de Protección de Datos, artículos 33 y 34.

← Volver al blog