Intrusiones en PrestaShop: análisis técnico y soluciones

PrestaShop no suele comprometerse por un único fallo del núcleo. La cadena habitual combina un módulo o tema desactualizado, un panel de administración expuesto, credenciales reutilizadas o un skimmer inyectado en una plantilla. Este análisis técnico desglosa la superficie de ataque, los avisos recientes, los indicadores de compromiso y las medidas de contención y endurecimiento.

Este artículo es la versión técnica. Si buscas una introducción menos detallada, consulta la guía introductoria sobre intrusiones en PrestaShop.

1. Superficie de ataque y modelo de amenaza

Una tienda PrestaShop combina el núcleo, los módulos, el tema, el panel de administración, el webservice, la base de datos y el entorno PHP. A esto se suma la cadena de suministro: módulos de terceros, temas comerciales y credenciales del ecosistema. La mayoría de los incidentes documentados se origina en componentes añadidos o en accesos comprometidos, no en una vulnerabilidad desconocida del núcleo.

PrestaShop supera las 300.000 tiendas. Turaco Labs identificó 327 tiendas comprometidas en febrero de 2026 y 1.068 a principios de junio; su telemetría muestra un crecimiento del código malicioso de aproximadamente 8 veces entre octubre de 2025 y julio de 2026. La alerta oficial de PrestaShop de febrero de 2026 confirmó skimmers inyectados en plantillas de tema.

2. Panel de administración y autenticación

El panel de administración es el objetivo de mayor valor: permite gestionar pedidos, clientes, precios, módulos y pagos. Los vectores habituales son contraseñas débiles o reutilizadas, uso de credenciales filtradas, cuentas de antiguos empleados que siguen activas y ausencia de segundo factor. PrestaShop no incluye autenticación en dos pasos de forma nativa; se implanta con un módulo de confianza.

La enumeración de usuarios también facilita el ataque. En 2026 se corrigió una vulnerabilidad de enumeración por tiempos en el acceso de clientes (CVE-2026-25597), parcheada en 8.2.4 y 9.0.3. Un atacante puede combinar esa información con credenciales filtradas para lanzar un ataque de pulverización de contraseñas.

Detección: revisa empleados nuevos, cambios de perfil, accesos desde ubicaciones desconocidas y actividad reciente en el registro de acciones. Comprueba la tabla de empleados, los perfiles, la última conexión y los permisos. El perfil de superadministrador suele ser el identificador 1. Mitigación:

• Renombra la carpeta de administración y no la publiques en el archivo de rastreo de buscadores; prueba antes en un entorno de pruebas.
• Contraseñas únicas y largas, con gestor de contraseñas.
• Autenticación en dos pasos para todos los administradores.
• Mínimo privilegio: cada empleado solo con las secciones que necesita.
• Límite de intentos, bloqueo progresivo y restricción por dirección IP o firewall.
• Desactiva o elimina cuentas inactivas y de antiguos proveedores.

3. Módulos y temas: vulnerabilidades y avisos

Los módulos amplían la funcionalidad, pero también la superficie. Un complemento abandonado, descargado de una fuente no oficial o sin parchear puede permitir inyección de consultas, carga arbitraria de archivos, recorrido de rutas o creación de administradores. Los temas son igual de sensibles: una plantilla modificada puede inyectar un skimmer sin tocar el núcleo.

No es una lista exhaustiva. Otros avisos recientes afectan a módulos de listas de deseos, marketing y navegación por facetas. Estrategia:

• Actualiza el núcleo a 8.2.8 o 9.1.5 como mínimo y aplica versiones posteriores cuando existan.
• Actualiza módulos y tema; elimina lo abandonado o que no uses.
• Descarga solo desde el marketplace oficial o proveedores verificados.
• Revisa diferencias antes de actualizar componentes sensibles (pago, clientes, autenticación).
• Aplica reglas de mitigación en el firewall de aplicaciones web mientras pruebas la actualización.
• Prueba en un entorno de pruebas y verifica el proceso de compra tras cada cambio.

4. Persistencia: archivos no autorizados y accesos

El atacante busca quedarse. En PrestaShop los lugares habituales son:

• Módulos: archivos PHP nuevos o modificados dentro de un módulo legítimo.
• Temas, especialmente la plantilla de cabecera y el código del navegador.
• Directorios de carga, imágenes, caché y descargas: archivos PHP donde no debería ejecutarse código.
• Sobrescrituras de clases que alteran el comportamiento del núcleo.
• La carpeta del panel de administración y archivos sueltos en la raíz del sitio.
• El archivo de configuración, si el atacante busca credenciales.
• Empleados nuevos, claves de webservice y tareas programadas.
• Reglas del servidor web para redirigir, ocultar o servir contenido.

Patrones de ofuscación frecuentes: funciones de ejecución, decodificación y compresión; funciones variables y cadenas hexadecimales.

Detección: busca archivos PHP modificados en los últimos días, revisa las sobrescrituras de clases y los directorios de datos, y comprueba los registros del servidor y de la aplicación.

5. Skimmers y robo de datos de pago

En febrero de 2026, PrestaShop emitió una alerta de seguridad por un digital skimmer que sustituía los botones de pago legítimos por botones fraudulentos y redirigía a los clientes a formularios falsos. El código se cargaba mediante una etiqueta de código escrita directamente en la plantilla de cabecera del tema activo.

Sansec documentó un caso en una gran cadena de supermercados con un esquema de doble captura: el skimmer se integra con PrestaShop y muestra un formulario falso que el usuario completa dos veces. Turaco Labs observó un aumento de 327 tiendas comprometidas en febrero a 1.068 en junio de 2026, con componentes que incluyen skimmers, minería de criptomonedas, software no deseado y descargadores.

Detección:

• Compara la plantilla de cabecera y el resto del tema con una copia limpia.
• Busca etiquetas de código externas, funciones de decodificación y código del navegador ofuscado.
• Revisa los botones de pago y el flujo de compra en distintos dispositivos y navegadores.
• Comprueba las peticiones salientes del navegador y los dominios de destino.
• Contrasta pedidos y transacciones con el proveedor de pagos.
• Revisa el contenido del gestor de contenidos, las descripciones de productos y la configuración en busca de etiquetas de código y enlaces externos.

Mitigación: pasarelas con campos alojados, política de seguridad de contenido, verificación de integridad de recursos, firewall de aplicaciones web, escáner específico de comercio electrónico, monitorización de integridad del tema y restricción de accesos al panel y al hosting. Si hay exposición de tarjetas, activa el protocolo de seguridad de tarjetas y contacta con el proveedor de pagos.

6. Contenido inyectado y manipulación de la base de datos

El atacante puede inyectar contenido oculto en el gestor de contenidos, las descripciones de productos, las categorías, los metadatos o la configuración. A menudo sirve el contenido solo a buscadores mediante ocultación por agente de usuario, por lo que el visitante no ve nada anómalo.

• Busca en Google site:tudominio.com términos ajenos al catálogo.
• Revisa los sitemaps, el archivo de rastreo y las reglas de reescritura.
• Audita campos de contenido y configuración en busca de código o enlaces externos.
• Compara el tráfico y las direcciones indexadas con el catálogo real.
• Tras limpiar, solicita revisión en Search Console.

7. Núcleo, motor PHP y ramas sin soporte

La rama 1.7 dejó de recibir parches tras la salida de PrestaShop 9 en junio de 2025; 1.7.8.11 fue su última versión y 1.6 también está fuera de soporte. La rama 8.2.x entró en soporte extendido y 9.x es la rama actual. A fecha de este análisis, 8.2.8 y 9.1.5 (agosto de 2026) corrigen inyección de fórmulas en exportaciones (severidad 8,3/10), peticiones del servidor a direcciones arbitrarias en la importación (severidad 8,2/10) y suplantación de la dirección IP del cliente mediante cabeceras (severidad 7,3/10).

No todo depende de PrestaShop. En octubre de 2026 se publicaron correcciones para vulnerabilidades críticas del motor PHP. Afectan a PHP, no al código de la tienda, y actualizar solo PrestaShop o los módulos no las corrige. La versión de PHP debe estar soportada y parcheada; PrestaShop 9.1 admite PHP 8.1–8.5, mientras que 1.7 queda en PHP 7.2–7.4, fuera de soporte.

• Migra 1.6/1.7 a 8.2.x o 9.x con un plan de pruebas.
• Mantén el núcleo en la última versión de seguridad de tu rama.
• Actualiza PHP en coordinación con el hosting y verifica módulos y tema.
• Usa un firewall de aplicaciones web con reglas para los vectores conocidos mientras actualizas.
• Monitoriza los avisos de PrestaShop, GitHub y del motor PHP.

8. Cadena de suministro y credenciales

Los módulos pirateados incluyen accesos no autorizados de fábrica. Los módulos abandonados no reciben parches. Y las credenciales del ecosistema —marketplace, hosting, FTP, correo— son un objetivo directo. En 2026 se reportó un supuesto leak de más de 21 millones de registros del marketplace de PrestaShop; aunque no está confirmado, refuerza la necesidad de rotar credenciales y vigilar el uso de credenciales filtradas.

• Instala solo módulos oficiales o de proveedores verificados.
• Revisa el historial y los cambios de propiedad del proveedor.
• Rota credenciales de marketplace, hosting, FTP/SFTP, SSH, base de datos y correo.
• Activa autenticación en dos pasos en hosting y correo; usa claves SSH en lugar de contraseñas.
• Busca secretos expuestos en repositorios, archivos de entorno, copias de seguridad y volcados de base de datos.
• Desactiva el webservice si no lo usas y rota sus claves si lo usas.

En PrestaShop 1.7+ las credenciales de base de datos y las claves de cookie están en el archivo de configuración; en 1.6, en el archivo de configuración correspondiente. Tras un incidente, cambia la contraseña de la base de datos, actualiza la configuración y rota las claves de cookie para invalidar sesiones.

9. Endurecimiento técnico de PrestaShop

Actualización y ciclo de vida

• Núcleo en 8.2.8 o 9.1.5 como mínimo (o posterior), módulos y tema actualizados.
• Elimina módulos y temas que no uses; desactivar no es suficiente.
• Prueba cada actualización en un entorno de pruebas y verifica el proceso de compra.
• No uses ramas sin soporte (1.6/1.7).

Panel de administración

• Renombra la carpeta de administración y protégela con restricción por dirección IP, firewall o autenticación adicional.
• Autenticación en dos pasos para todos los administradores.
• Mínimo privilegio y revisión periódica de empleados y perfiles.
• Límite de intentos y bloqueo progresivo.

Archivos, permisos y secretos

• Directorios 755 y archivos 644; el archivo de configuración en 600.
• Escritura solo donde sea necesaria (caché, carga de archivos, imágenes y descargas).
• Evita permisos 777 y propietarios incorrectos.
• Elimina o bloquea la carpeta de instalación tras la instalación.
• Protege el archivo de configuración, los registros y las copias de seguridad.
• No guardes copias de seguridad ni volcados de base de datos en el directorio público.

Bloquea la ejecución de PHP en los directorios de carga, imágenes, caché y descargas mediante reglas del servidor web.

Servidor web y cabeceras

• Usa conexión segura en toda la tienda y redirige las peticiones no seguras.
• Activa cabeceras de seguridad: tipo de contenido, marco, política de referencia y permisos del navegador.
• Desactiva el listado de directorios.
• Añade una capa de autenticación al panel de administración si tu infraestructura lo permite.
• Mantén actualizado el software del servidor web y el panel del hosting.

PHP, webservice y configuración

• Desactiva el modo desarrollo, el perfilado y la visualización de errores en producción.
• Desactiva el webservice si no lo usas; si lo usas, limita direcciones, rota claves y aplica mínimo privilegio.
• Verifica la configuración de conexión segura y de dominios de la tienda.
• Si el hosting lo permite, restringe funciones peligrosas del sistema y prueba la tienda antes.
• Usa un usuario de base de datos dedicado, no el administrador de la base de datos.

Copias de seguridad y monitorización

• Copias 3-2-1 de archivos y base de datos, con una copia fuera del hosting e inmutable.
• Prueba la restauración; una copia no verificada no es una copia.
• Monitoriza la integridad de archivos, los registros, las cuentas de empleado y las claves de webservice.
• Vigila cambios en la plantilla de cabecera, los módulos, las sobrescrituras de clases y el archivo de configuración.
• Configura alertas ante conexiones salientes anómalas desde el proceso de compra.

10. Detección y respuesta a incidentes

1. Preserva evidencia: copia registros, una instantánea de la base de datos y los archivos antes de modificar nada.
2. Aísla: modo mantenimiento, firewall en bloqueo y restricción de salida si hay exfiltración.
3. Determina el alcance: revisa módulos, tema, sobrescrituras de clases, directorios de datos, empleados, webservice, registros y base de datos.
4. Contén y erradica: elimina archivos no autorizados y código inyectado; si el compromiso es profundo, reconstruye desde una versión limpia.
5. Rota credenciales: base de datos, panel, FTP/SFTP, SSH, hosting, webservice, marketplace y claves de cookie.
6. Restaura y verifica: vuelve a producción solo tras escaneos limpios, revisión del proceso de compra y una compra de prueba.
7. Post-mortem: documenta el vector, el alcance y las medidas correctivas.

Revisión técnica: comprueba empleados y perfiles, el registro de acciones, las claves de webservice, los módulos instalados, la configuración, el contenido del gestor de contenidos y las descripciones de productos. Verifica el proceso de compra con una compra de prueba.

Si se han comprometido datos de pago, activa el protocolo de seguridad de tarjetas, informa al proveedor de pagos y valora las obligaciones de notificación aplicables. En caso de duda, solicita asesoramiento legal especializado.

11. Herramientas recomendadas

12. Preguntas frecuentes sobre intrusiones en PrestaShop

¿Cuál es el vector de intrusión más común en PrestaShop?

Los módulos y temas desactualizados, el panel de administración expuesto y las credenciales comprometidas concentran la mayoría de los accesos iniciales. En 2026 los skimmers inyectados en plantillas de tema han sido especialmente relevantes.

¿Cómo detectar un skimmer en PrestaShop?

Revisa la plantilla de cabecera del tema, los códigos externos, los botones de pago y el flujo de compra. Compara el tema con una copia limpia y usa un escáner específico de comercio electrónico.

¿Qué archivos debo revisar tras una intrusión?

Los módulos, los temas, los directorios de carga, imágenes, caché y descargas, las sobrescrituras de clases, la carpeta del panel y el archivo de configuración. También revisa cuentas de empleado, claves de webservice y registros.

¿PrestaShop 1.7 sigue teniendo soporte?

No. La rama 1.7 dejó de recibir parches tras la salida de PrestaShop 9 en junio de 2025; 1.6 también está fuera de soporte. Migra a 8.2.x o 9.x.

¿Cómo proteger el panel de administración?

Renombra la carpeta de administración, usa contraseñas únicas, autenticación en dos pasos, mínimo privilegio, límite de intentos y restricción por dirección IP o firewall.

¿Basta con actualizar PrestaShop?

No. También hay que actualizar módulos, temas y PHP, revisar credenciales, proteger el archivo de configuración, limitar permisos y mantener copias de seguridad probadas.

Las versiones y CVE citados evolucionan. Verifica siempre el estado actual de tus componentes y el aviso oficial del proveedor antes de aplicar cambios en producción.