# Qué hacer si hackean tu PrestaShop: la primera hora

> Qué hacer si hackean tu PrestaShop: cortar el skimmer, comandos para encontrar archivos modificados, revisar ps_configuration y hooks, CVE reales y RGPD.

URL: https://webintacta.com/guias/prestashop-hackeado-que-hacer
Última actualización: 2026-10-17

**En resumen:** Si hackean tu PrestaShop, en la primera hora hay que probar el pago (un skimmer puede estar robando tarjetas) y desactivar ese método si hay dudas, copiar archivos, base de datos y logs tal como están y cambiar las contraseñas, sin borrar nada a ciegas. Después se buscan archivos modificados, overrides, hooks y valores de ps_configuration, y el módulo por el que entraron. Si hay datos de clientes afectados, hay 72 horas para notificarlo a la AEPD.


Por Jose Soriano (WebIntacta) · publicada el 2026-10-07

Trabajo a diario con PrestaShop y casi todas las tiendas hackeadas que veo tienen dos cosas en común: un módulo de terceros sin actualizar y nadie revisando qué archivos cambian. Esta guía es lo que haría yo, en orden, si la tienda fuera mía.

## La primera hora

1. **Comprueba el pago.** Haz una compra de prueba y fíjate en el paso de pago: ¿aparece un formulario de tarjeta en tu propia página cuando tu pasarela normalmente redirige o muestra el suyo? ¿Hay un paso de más, o un error tras meter la tarjeta y después el pago «bueno»? Si sospechas de un skimmer, **desactiva ese método de pago** mientras lo investigas. Cada pedido con el skimmer activo es una tarjeta robada.
2. **Haz una copia completa** de archivos y base de datos tal como están. Guarda también los **logs de acceso** del servidor: algunos hostings solo conservan unos días. Es tu prueba y tu vuelta atrás.
3. **Cambia las contraseñas**: hosting, FTP, base de datos, empleados del back-office y la cuenta de la pasarela de pago. Desde un ordenador limpio. Si cambias la de la base de datos, actualízala en `app/config/parameters.php` (1.7, 8 y 9) para que la tienda no se caiga.
4. **No borres nada todavía.** Lo que encuentres te dice por dónde entraron.
5. **Anota fechas**: cuándo empezaron las quejas o los cargos fraudulentos. Te harán falta para el banco y, si aplica, para el RGPD.

## Cómo suelen entrar: casos reales

Conviene conocer los patrones documentados, porque se repiten. Todos los que cito tienen aviso público y enlace a la fuente.

### La campaña de blm.php (2022)

En julio de 2022, el equipo de PrestaShop [alertó de una campaña](https://build.prestashop-project.org/news/2022/major-security-vulnerability-on-prestashop-websites/) que encadenaba una inyección SQL (en un módulo o en el propio núcleo) con la función de caché de Smarty en MySQL para ejecutar código. El patrón en los logs era una petición `POST` al punto vulnerable, un `GET /` un segundo después y, a continuación, peticiones a un archivo nuevo, `blm.php`, en la raíz. Con ese control, los atacantes **inyectaban un formulario de pago falso en el checkout**. Se corrigió en PrestaShop 1.7.8.7 con el identificador [CVE-2022-31181](https://github.com/PrestaShop/PrestaShop/security/advisories/GHSA-hrgx-p36p-89q4) (crítico, 9,8).

> Verás citado también CVE-2022-36408 para este ataque. Ese identificador está rechazado: el NVD lo marca como duplicado de CVE-2022-31181 por un error tipográfico. El bueno es CVE-2022-31181.

El mismo aviso señalaba que las versiones 2.0.0 a 2.1.0 del módulo de lista de deseos `blockwishlist` eran vulnerables a inyección SQL ([CVE-2022-31101](https://security.friendsofpresta.org/modules/2022/06/24/blockwishlist.html)).

### Módulos de terceros con inyección SQL o subida de archivos

La asociación Friends of Presta publica avisos de seguridad de módulos, y en varios indica expresamente que el fallo **se está usando para instalar skimmers**: por ejemplo, el módulo de pago con Stripe `stripejs` antes de 4.5.5 ([CVE-2023-23315](https://security.friendsofpresta.org/modules/2023/03/01/stripejs.html)), el importador `simpleimportproduct` hasta 6.7.0 ([CVE-2024-25846](https://security.friendsofpresta.org/modules/2024/02/27/simpleimportproduct.html)) o el checkout de una página `supercheckout` hasta 6.0.6 ([CVE-2023-45384](https://security.friendsofpresta.org/modules/2023/10/17/supercheckout.html)). Tengo la lista ampliada en [módulos de PrestaShop con vulnerabilidades conocidas](https://webintacta.com/guias/modulos-prestashop-vulnerables).

Un detalle importante de esos avisos: muchos ataques usan un controlador de módulo y **ocultan la ruta**, así que en el log normal solo verás `POST /`. Que no aparezca el nombre del módulo no descarta nada.

## Dónde buscar

### Archivos modificados recientemente

Con acceso SSH, desde la raíz de la tienda. Estos comandos solo leen, no cambian nada:

```
# PHP modificados en los últimos 15 días (sin contar la caché)
find . -name "*.php" -mtime -15 -not -path "./var/cache/*" -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort -r | head -50

# PHP en carpetas que no deberían tenerlo (salvo los index.php de protección)
find img upload download -name "*.php" ! -name "index.php"

# Funciones típicas del código ofuscado
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" --include=*.php . | grep -vE "^\./(vendor|var/cache)/"
```

El último comando da falsos positivos: hay librerías legítimas que usan esas funciones. Lo que buscas son archivos de la tienda o de módulos que no las usaban, o con líneas larguísimas sin sentido. Las fechas de modificación también se pueden falsear, así que no te fíes solo de ellas.

### Archivos del núcleo modificados

Los skimmers de PrestaShop suelen tocar archivos que intervienen en el pedido: `classes/Cart.php`, `classes/PaymentModule.php`, controladores del checkout o la plantilla del paso de pago. La forma fiable de encontrarlos es comparar cada archivo con el original de **tu versión exacta** de PrestaShop (descargada de la web oficial o de su repositorio de GitHub). El [conector de solo lectura](https://webintacta.com/conector) hace esa comparación archivo por archivo.

### La carpeta override/

Los overrides permiten que un módulo o un desarrollador cambie el comportamiento del núcleo sin tocarlo. Son legítimos, pero también un buen escondite. Revisa cada archivo de `override/classes/` y `override/controllers/`: deberías saber qué módulo o qué desarrollador lo creó. Después de cambiar algo ahí, borra `var/cache/` (o `cache/class_index.php` en 1.6) para que PrestaShop lo vuelva a leer.

### Módulos

Revisa en `modules/` las carpetas que no reconozcas y las fechas de modificación recientes. Y, sobre todo, la **versión** de cada módulo de terceros frente a los avisos publicados: un módulo con un fallo conocido es la entrada más habitual. Un módulo desactivado sigue en el servidor y sus archivos siguen respondiendo, así que también cuenta.

### Base de datos: configuración, hooks y empleados

Desde phpMyAdmin o la consola de MySQL. Cambia `ps_` por tu prefijo si es otro (está en `app/config/parameters.php`):

```
-- Scripts guardados en la configuración
SELECT name, LEFT(value, 120) FROM ps_configuration
WHERE value LIKE '%<script%' OR value LIKE '%eval(%' OR value LIKE '%atob(%';

-- Tipo de caché de Smarty: si vale 'mysql' y no lo pusiste tú, mala señal
SELECT name, value FROM ps_configuration WHERE name = 'PS_SMARTY_CACHING_TYPE';

-- Qué módulos se cuelgan de la cabecera, el pie y el pago
SELECT h.name AS hook, m.name AS modulo, m.version, m.active
FROM ps_hook_module hm
JOIN ps_hook h ON h.id_hook = hm.id_hook
JOIN ps_module m ON m.id_module = hm.id_module
WHERE h.name IN ('displayHeader', 'actionFrontControllerSetMedia',
                 'displayBeforeBodyClosingTag', 'paymentOptions', 'displayPaymentTop')
ORDER BY h.name, hm.position;

-- Empleados del back-office
SELECT id_employee, email, firstname, lastname, active FROM ps_employee;
```

En la consulta de hooks, cualquier módulo que no reconozcas enganchado a `displayHeader` o al pago merece una visita a su carpeta. Busca también `<script` en las páginas CMS (`ps_cms_lang`) y en los módulos de bloques HTML personalizados.

### Tareas programadas y accesos al servidor

Mira las tareas `cron` del usuario del hosting (`crontab -l` o la sección Cron del panel) y las del propio PrestaShop si usas un módulo de tareas programadas. Una tarea que descarga un archivo de un dominio desconocido o ejecuta un PHP con nombre raro es la forma típica de que la infección vuelva. Revisa también las cuentas FTP del panel y las claves de `~/.ssh/authorized_keys`: cualquier acceso que nadie sepa explicar, fuera.

### Logs de acceso

Busca peticiones `POST` a archivos dentro de `modules/` o a archivos PHP de la raíz que no conoces, y los accesos inmediatamente posteriores:

```
grep -E "POST /modules/|POST /[a-z0-9_-]+\.php|blm\.php" access.log | tail -50
```

### Configuración peligrosa

- `_PS_MODE_DEV_` en `true` en producción (`config/defines.inc.php`): muestra errores con rutas y datos internos.
- La carpeta de administración con un nombre fácil de adivinar.
- La carpeta `install/` sin borrar tras la instalación.
- Copias de seguridad `.zip` o `.sql` en la raíz o en carpetas públicas.

## Antes de volver a abrir

Cuando creas que está limpia, compruébalo como lo haría un cliente y no como administrador: una compra de prueba completa desde un navegador sin sesión, con las herramientas del navegador abiertas en la pestaña **Network** para ver a qué dominios se conecta el pago. Repite las búsquedas de archivos y de base de datos de arriba: no debe salir nada nuevo. Y deja activa alguna forma de vigilar los cambios de archivos durante las semanas siguientes, porque si quedó una puerta trasera se notará pronto.

## Si hay datos de clientes afectados

Si el ataque ha podido exponer datos personales (nombres, direcciones, emails, y no digamos tarjetas), el RGPD obliga al responsable del tratamiento, es decir, a ti, a **notificarlo a la Agencia Española de Protección de Datos sin dilación indebida y, si es posible, en un máximo de 72 horas** desde que lo sabes, salvo que sea improbable que suponga un riesgo para las personas. Si el riesgo es alto, también hay que informar a los afectados. Lo explico con detalle en [brecha de datos en tu tienda online](https://webintacta.com/guias/brecha-datos-tienda-online-rgpd).

Si hubo robo de tarjetas, avisa también a tu pasarela de pago o a tu banco: tienen procedimientos para estos casos. Consulta la parte legal con tu asesor; la parte técnica (qué datos, desde cuándo, cómo entraron) es lo que debe contar el informe de la limpieza. Cómo se detecta un skimmer y dónde se esconde, en [robo de tarjetas en tu tienda](https://webintacta.com/guias/robo-de-tarjetas-tienda-online).

> Fuera de España, la obligación de notificar depende de la ley de cada país (en Latinoamérica varía mucho). Consulta con un profesional local.

## Cómo evitar que vuelva a pasar

1. **Actualiza el núcleo y los módulos.** PrestaShop 1.7 dejó de recibir parches cuando salió la versión 9.0; si sigues en 1.7 o en 1.6, planifica el salto. Te lo explico en [actualizar PrestaShop](https://webintacta.com/guias/actualizar-prestashop).
2. **Quita los módulos que no usas**, aunque estén desactivados: sus archivos siguen en el servidor y pueden ser explotables.
3. **Vigila la integridad de los archivos.** Saber al día siguiente que alguien ha tocado `classes/Cart.php` es la diferencia entre un susto y meses de tarjetas robadas. Es lo que hace cada día el [mantenimiento de PrestaShop](https://webintacta.com/mantenimiento-prestashop) con el conector.
4. **Revisa los empleados** del back-office y usa contraseñas largas y distintas para cada uno. El resto de comprobaciones de una tienda, en [seguridad PrestaShop](https://webintacta.com/seguridad-prestashop).
5. **Haz copias de seguridad** fuera del servidor y comprueba de vez en cuando que se pueden restaurar.

## Si prefieres que lo haga yo

La limpieza de una tienda PrestaShop cuesta 349 € (IVA no incluido). Empiezo por cortar la fuga en el pago, reviso núcleo, overrides, módulos y base de datos, cierro la entrada y te entrego un informe técnico que sirve para el banco y para el RGPD. Tiene 90 días de garantía. Si necesitas que tenga prioridad sobre el resto de trabajos, la prioridad se añade por +100 € (IVA no incluido). Más detalles en [PrestaShop hackeado](https://webintacta.com/prestashop-hackeado).

## Fuentes

- [PrestaShop: aviso de la campaña de julio de 2022](https://build.prestashop-project.org/news/2022/major-security-vulnerability-on-prestashop-websites/) (cadena de inyección SQL y caché de Smarty en MySQL, `blm.php`, formulario de pago falso, `blockwishlist` 2.0.0 a 2.1.0 y corrección en 1.7.8.7).
- [Aviso GHSA-hrgx-p36p-89q4 del núcleo de PrestaShop](https://github.com/PrestaShop/PrestaShop/security/advisories/GHSA-hrgx-p36p-89q4) (CVE-2022-31181, crítico, 9,8, corregido en 1.7.8.7).
- [NVD: CVE-2022-36408](https://nvd.nist.gov/vuln/detail/CVE-2022-36408) (rechazado como duplicado de CVE-2022-31181 por un error tipográfico).
- Friends of Presta: avisos de [stripejs](https://security.friendsofpresta.org/modules/2023/03/01/stripejs.html), [simpleimportproduct](https://security.friendsofpresta.org/modules/2024/02/27/simpleimportproduct.html) y [supercheckout](https://security.friendsofpresta.org/modules/2023/10/17/supercheckout.html) (módulos usados para instalar skimmers).
- [PrestaShop 1.7.8 en soporte extendido](https://build.prestashop-project.org/news/2023/178-in-extended-support-phase/) (el mantenimiento de seguridad de 1.7.8 termina con la salida de PrestaShop 9.0.0).
- [Reglamento (UE) 2016/679, RGPD, artículos 33 y 34](https://www.boe.es/buscar/doc.php?id=DOUE-L-2016-80807) (BOE) y [AEPD: notificación de brechas de datos personales](https://www.aepd.es/derechos-y-deberes/cumple-tus-deberes/medidas-de-cumplimiento/brechas-de-datos-personales-notificacion) (plazo de 72 horas).

## Preguntas frecuentes

### ¿Sirve restaurar una copia anterior?

Solo si sabes que la copia es anterior a la intrusión y corriges después el fallo por el que entraron. Si no, vuelve a pasar.

### ¿Tengo que avisar a mis clientes?

Si la brecha supone un alto riesgo para ellos (por ejemplo, tarjetas o contraseñas expuestas), el RGPD exige informarles. Decídelo con tu asesor con el informe técnico delante.

### ¿Qué es blm.php en PrestaShop?

Es el nombre del archivo que dejaban en la raíz de la tienda los atacantes de la campaña de julio de 2022 (CVE-2022-31181) para ejecutar código y meter un formulario de pago falso. Si lo encuentras, la tienda está comprometida aunque ya hayas actualizado.

### ¿Cómo sé por qué módulo entraron?

Cruzando la versión de cada módulo con los avisos publicados y mirando los logs de acceso en las fechas del ataque. Si los logs solo muestran «POST /», el atacante ha ocultado la ruta y hace falta revisar los módulos uno a uno.

## Sobre el autor

[Jose Soriano](https://webintacta.com/quien-soy): Desarrollador fullstack especializado en PrestaShop, WordPress y WooCommerce, con el curso y el examen oficiales de PrestaShop aprobados. Desarrolla tiendas online y módulos desde 2023 y es el fundador de WebIntacta, el servicio de seguridad web con el que analiza, limpia y mantiene él mismo webs de pymes y tiendas online, en remoto desde Ibi (Alicante). Datos de WebIntacta: https://webintacta.com/quien-soy#datos