Introducción
Hace escasas 48 horas, PrestaShop nos informó a través de un escueto comunicado enviado por correo electrónico de un nuevo «problema de seguridad» en su ecosistema.
El correo nos habla de un script malicioso que puede inyectar código reemplazando los botones de pago genéricos del checkout de nuestras tiendas para robar información relacionada con tarjetas de nuestros clientes.
Así mismo, nos recomiendan ponernos en contacto con nuestra “Agencia experta en PrestaShop” o directamente con PrestaShop a través de su servicio de soporte lo antes posible a fin de realizar un análisis de seguridad.
¿Qué versiones están afectadas?
¿Cuál es el vector de ataque?
¿Desde cuándo se conoce esta vulnerabilidad?
Estas y algunas otras importantes preguntas son las que nos hacemos leyendo este correo.
Muchas más son las que van a surgir en el desarrollo de este artículo, porque sí querido lector, aludiendo al título – que no es clickbait – los chicos de PrestaShop, en esta ocasión, no te lo está contando todo.
Descifrando el enigma
En el correo que probablemente has recibido, como imagino que te habrás dado cuenta, hay un enlace a una página de la propia PrestaShop donde amplían la información.
Para que no tengas que buscarlo de nuevo te lo dejo aquí
En esta página, básicamente, hay dos cosas que me llaman poderosamente la atención:
- No informan prácticamente de nada en materia de seguridad (algo que vamos a desgranar a continuación)
- Misteriosamente aparece siempre como actualizada cuando su contenido es el mismo desde el momento de la publicación.
Lo que vamos a hacer a continuación es un ejercicio de comprensión de la información que nos da PrestaShop en este artículo y luego lo compararemos con los patrones habituales que, en ciberseguridad se suelen seguir para informar de una vulnerabilidad crítica, como es el caso.
Iré citando párrafos de este artículo original para poder comentarlos
“Recientemente hemos identificado una amenaza de seguridad que afecta a algunas tiendas en línea del ecosistema PrestaShop. Se ha detectado un script malicioso (“digital skimmer”) que podría haber provocado el robo de la información de pago de algunos de sus clientes.”
Quiero subrayar como altamente importante dos partes de este párrafo
- “Recientemente hemos identificado una amenaza de seguridad…”
- “Se ha detectado un script malicioso (“digital skimmer”)
Podrás pensar que me he vuelto loco por ignorar la parte de que puede que hayan robado la información de tus clientes, pero ahora mismo eso no es importante (no es el objetivo de este post).
Estas dos frases son importantes, como veremos a continuación, porque tendrían todo el sentido del mundo si viniesen acompañadas de más información que ayudase a identificar algo que en seguridad llamamos “vector de ataque”, sin embargo no hallaremos tal información en este post y de ahí su relevancia.
Lo que quiero decir, es que PrestaShop nos “informa” de un fallo de seguridad de nivel crítico, pero no nos da más información al respecto.
Es como si la DGT informara de un socavón en la A-3, una de las vías de circulación más importantes de España pero no avisara en qué punto kilométrico está situada: la misma estupidez.
¿Qué es un vector de ataque?
En ciberseguridad, un vector de ataque es el método, ruta o “camino” que un atacante usa para obtener acceso no autorizado a un sistema, como por ejemplo a un PrestaShop.
Sigamos analizando la entrada de PrestaShop
“Este malware funciona sustituyendo los botones de pago legítimos en la página de pedido por botones fraudulentos. Cuando un cliente hace clic en uno de estos falsos botones, es redirigido a un formulario de pago falsificado destinado a capturar su información de pago.
El skimmer simplemente se carga mediante una etiqueta <script>, escrita directamente en el archivo _partials/head.tpl del tema activo de la tienda. Esto significa que el atacante pudo modificar un archivo de la tienda.”
Lo que nos cuentan en este párrafo es sobre la naturaleza del ataque.
Explican qué es un “digital skimmer” y cómo actúa en una tienda infectada, pero no aportan datos acerca de cómo logran infectarla.
Quiero resaltar como relevante el apartado de “El skimmer simplemente se carga mediante una etiqueta <script> en el archivo _partials/head.tpl del tema activo de la tienda”
Lo que esto nos indica es que el atacante ha logrado elevar privilegios de escritura y/o ejecución en el código de la tienda (en el hosting o servidor donde se está ejecutando).
Por esto lo considero muy importante, pues de nuevo siguen sin darnos información acerca de cómo se produce.
A continuación, los buenos amigos de PrestaShop nos indican en los dos párrafos siguientes cómo podemos verificar si nuestra tienda está afectada (¡todo un detalle!) revisando desde el inspector de código del navegador o desde los archivos.
Y por último, la guinda del pastel, lo que creo que está generando toda la controversia de este asunto.
En el último párrafo, nos responden a la gran pregunta: “¿Qué hacer si mi tienda está infectada?”
Y la respuesta es cambiar las claves, todas: ftp, backoffice, base de datos, SSH, etc
¿En serio?
Mi opinión al respecto
A partir de aquí, querido lector, te voy a explicar cuál es mi opinión y mi razonamiento sobre la misma.
Vaya por delante que no tengo información privilegiada como tampoco estoy en posesión de la verdad absoluta: esto puede ser así o no.
Creo sinceramente que no ha habido una vulnerabilidad en el código de PrestaShop, sino que PrestaShop ha sufrido un ataque y como consecuencia de éste, los atacantes robaron determinados datos de la base de datos de PrestaShop, entre ellos datos de conexión a tiendas.
Ya sé, te estarás preguntando que cómo es posible esto.
Bueno, déjame decirte antes de nada que esto lo reflexionamos muy en profundidad en la agencia cuando recibimos el correo y comenzamos a investigar todo el asunto.
Voy a contarte algunas cosas muy interesantes que creo que no sabes, presta atención.
Cuando compras un módulo en PrestaShop y necesitas soporte de su desarrollador, sabes que puedes solicitarlo a través de tu perfil de PrestaShop Addons, enviando una consulta técnica.
En este formulario de consulta al desarrollador, PrestaShop incluye una serie de campos para colocar la URL del backoffice de tu tienda, usuario y contraseña así como credenciales de FTP.
Ahora ata cabos: Si roban esos datos nadie necesita “vulnerar el código” de PrestaShop para inyectar un skimmer ¿cierto?
Bastaría con conectarse vía FTP o desarrollar un sencillo plugin que puedas instalar desde el backoffice de la tienda y que contenga el skimmer.
Simple y limpio: sin rastros.
Cuando enuncié esta posibilidad, reconozco que era todo una conjetura, es decir: no tenía prueba alguna de que podía haber sucedido de esta forma, sin embargo tenía la intuición, muy probablemente porque uno peina ya algunas canas en estas situaciones y mehuele todo a chamusquina desde el principio.
¿Qué me hizo sospechar?
Varias cosas que ya hemos visto a lo largo de este post.
En primer lugar, lo más sospechoso de todo es que nos informen de una “vulnerabilidad” en el código de PrestaShop no “mencionada”, es decir: Vulnerabilidad, como tal, es un fallo en el código, sin embargo PrestaShop no ha empleado esta definición. Ellos han usado “amenaza de seguridad”, o lo que es lo mismo: no han admitido que el código haya sido vulnerado.
Luego tenemos el hecho de que saben muy bien cuál es el ataque que se ha realizado pero no nos dicen cómo se ha realizado, lo cual contradice todos los principios profesionales, éticos y morales de la ciberseguridad.
Por último tenemos el hecho de que, aún sabiendo qué ataque se ha realizado, no nos indican otro método para solucionarlo que el cambio de contraseñas.
Si me atacan y como experto me dices que lo que tengo que hacer es cambiar la contraseña, está claro que el problema no ha sido el código, sino que el atacante tiene mi contraseña.
Y si yo no le he dado nunca (conscientemente) al atacante mi contraseña, la gran pregunta es: ¿de dónde leches se la ha sacado?
Esto no acaba aquí
Pues no, esto no acaba aquí.
Resulta que tras investigar, desarrollar un script para enchufarlo en todas las webs de nuestros clientes y respirar brevemente al saber que ninguno de ellos se había visto vulnerado, me he puesto a investigar un poco más sobre el asunto.
Y, como dicen los franceses.. Voilà ! encontré este interesante hilo en el foro de PrestaShop internacional (puedes verlo aquí)
https://www.prestashop.com/forums/topic/1105466-recent-prestashop-securtity-alert/
En este hilo se discute ampliamente sobre lo inútil que resulta el comunicado de PrestaShop en relación al problema, la ausencia de información adicional o vectores de ataque, en conclusión, nada que no sepamos ya.
Sin embargo, es especialmente importante el mensaje del usuario “venditdevs”
Lo que este usuario nos cuenta es que es desarrollador de PrestaShop (vende módulos en el marketplace de PrestaShop addons).
Como desarrolladores, detectaron este problema en una tienda que mantenían y analizando el problema, se dieron cuenta rápidamente de que para infectar la tienda se dieron dos circunstancias muy concretas:
- Se accedió al backoffice a través de la URL del mismo con credenciales correctas
- Las credenciales que se usaron procedían de las almacenadas en el área de soporte de PrestaShop Addons
Esto último es fácilmente identificable para nosotros dado que cuando tenemos que dar un acceso a un desarrollador, por protocolo siempre creamos un usuario “ad-hoc” para ellos, de tal forma que sus accesos queden reflejados en los logs de PrestaShop y además podamos restringir dicho acceso inmediatamente cuando el técnico haya concluido su trabajo
Con todo esto, se pusieron a investigar cómo era posible que alguien tuviese acceso a esas credenciales si no las habían compartido con nadie.
Entonces llegaron rápidamente a la conclusión de que era PrestaShop (la empresa, no el código) el que había sufrido un robo de datos al encontrarse estas dos fuentes de información:
https://socradar.io/prestashop-data-panorabanques-new-fraud-services/
Además, nuestro buen amigo nos indica que en noviembre de 2025 (hace ya casi 4 meses) se pusieron en contacto con PrestaShop para indicarles este incidente, sin embargo jamás recibieron una respuesta formal por parte de PrestaShop.
Cansados de ver cómo importantes filtraciones de seguridad se producen sin que se gestionen adecuadamente ni tan siquiera se informe a los usuarios, decidieron publicar hace escasas horas esta información que hoy te traemos en este post antes de que desaparezca en extrañas circunstancias.
¿Se podía haber hecho otra cosa?
Sí, por supuesto.
Ante todo PrestaShop es una empresa con unas obligaciones legales.
Custodia datos muy sensibles, como ya hemos podido observar y por tanto, debería de haber informado lo primero de todo a sus clientes de forma clara, inequívoca y precisa sobre la filtración de datos.
Dado que esta filtración se produjo, como muy tarde, en Agosto de 2025 (a tenor de lo publicado en una de las fuentes que te puse más arriba), cualquier empresa medianamente decente debería de haber avisado de todo esto en el momento fueron conscientes.
A saber cuántos desarrolladores más se dieron cuenta e informaron a tiempo con la esperanza de que PrestaShop tomase cartas en el asunto.
Un matiz importante
Antes he mencionado que el comunicado de PrestaShop se ha mantenido con el estatus de “actualizado” en su web pero no había sido modificado, sin embargo no es del todo cierto.
Hace 7 horas (desde mi reloj) que PrestaShop actualizó el post para agregar el último párrafo donde hablan de qué hacer si tu tienda ha sido afectada (cambiar las contraseñas).
Esto es más relevante si cabe y no hace sino reforzar esta teoría de que el origen del problema orbita en torno a una fuga de datos en los servicios de la propia PrestaShop porque, de no ser así, querido lector ¿por qué la solución sino, sería únicamente cambiar las contraseñas?
Mi conclusión
PrestaShop no es un “mal” software. Lo que hace grande a este ecosistema no es la propia PrestaShop, sino la comunidad y sus desarrolladores.
PrestaShop ha demostrado con el tiempo de forma totalmente sobrada que es un gran CMS para Ecommerce y que es altamente competente, especialmente en sus últimas versiones 8 y 9 donde han implementado una gran cantidad de avances técnicos.
Sin embargo, las decisiones empresariales y el rumbo que está tomando como empresa está exponiendo al modelo a riesgos innecesarios.
No voy a ponerme a enumerar los fallos impresionantes de seguridad que ha tenido a lo largo de sus respectivas historias otros sistemas como WordPress, Joomla o Drupal.
Con esto quiero decir que todos los sistemas sean o no de código abierto tienen tarde o temprano fallos de seguridad.
Es normal, es lógico y se solucionan de una forma u otra, pero esto no es un fallo de seguridad del código: esto es un fallo de seguridad de una empresa que ha afectado a 21,5 millones de registros (que no de cuentas).
Poca broma.
2 respuestas
¿21,5 millones de cuentas? Se referirá a registros, posiblemente conversaciones de los tickets.
¡Toda la razón! Gracias por la corrección José, quería referirme a registros y no a cuentas como tal (dudo que tengan 21,5M de cuentas jejejeje)
Un saludo