Vulnerabilidades y CVE de PrestaShop: qué está comprometiendo tiendas en 2026

PrestaShop es una de las plataformas de comercio electrónico más potentes y extendidas, pero la mayoría de las tiendas que se comprometen no caen por un fallo del núcleo: caen por un módulo de terceros desactualizado. Si tienes una tienda PrestaShop, entender de dónde vienen los CVE (las vulnerabilidades con identificador público) y cómo se explotan es la diferencia entre dormir tranquilo y descubrir un día que te están robando tarjetas o han secuestrado tu correo.

En esta guía repasamos las vulnerabilidades reales más recientes de PrestaShop, cómo funciona el ataque más habitual (la inyección SQL en un módulo), qué puede hacer un atacante cuando entra y —lo más importante— cómo proteger tu tienda de forma realista.

Dónde está de verdad el riesgo en PrestaShop

Conviene separar dos cosas que a menudo se mezclan:

• El núcleo de PrestaShop está razonablemente auditado y su equipo publica parches de seguridad con regularidad. Los fallos críticos en el core existen, pero son relativamente escasos y suelen corregirse rápido.
• Los módulos de terceros son otra historia. Una tienda media tiene decenas de módulos —de pago, de marketing, de logística, de diseño— desarrollados por autores muy distintos, con niveles de calidad muy diferentes y, en muchos casos, sin mantenimiento activo. Ahí es donde se concentra la inmensa mayoría de las vulnerabilidades explotadas.

Esto es importante porque cambia el enfoque de la defensa: no basta con tener «PrestaShop actualizado». Tienes que tener cada módulo actualizado y, sobre todo, eliminar los que ya no uses. Cada módulo instalado es una puerta; cada módulo abandonado por su autor es una puerta sin cerradura.

Anatomía del ataque más común: inyección SQL en un módulo

El patrón que se repite una y otra vez es la inyección SQL (SQLi) en el front controller de un módulo. Traducido: el módulo recibe un parámetro por la URL o por un formulario, y lo mete directamente en una consulta a la base de datos sin limpiarlo. Un atacante manipula ese parámetro para ejecutar sus propias consultas.

El caso perfecto de manual es CVE-2025-69633, una inyección SQL crítica (CVSS 9.8) en el módulo Advanced Popup Creator (advancedpopupcreator) de Idnovate, que afecta a todas las versiones anteriores a la 1.2.7. Permite a un atacante remoto y sin autenticar ejecutar consultas SQL arbitrarias a través del parámetro fromController del controlador del popup, con una simple petición HTTP por GET o POST.

Hay un detalle de este tipo de fallos que asusta especialmente y que conviene conocer: muchos exploits contra módulos PrestaShop ocultan la ruta del controlador, de modo que en tus registros de acceso solo verás un inofensivo POST /. Sin herramientas específicas (como el AuditEngine de mod_security o similar), ni siquiera sabrás que te están atacando. Este comportamiento se documentó ya en vulnerabilidades como CVE-2023-46350 (SQLi en el módulo idxrmanufacturer de InnovaDeluxe, también 9.8), donde los investigadores advertían de que el ataque pasa desapercibido en los logs convencionales.

CVE recientes de PrestaShop que deberías conocer

Estas son algunas de las vulnerabilidades reales publicadas recientemente en el ecosistema PrestaShop (núcleo y módulos). No es una lista exhaustiva, pero ilustra bien el tipo de fallos y su gravedad:

Fíjate en un detalle preocupante de CVE-2026-39079 (módulo UPS Shipping): el autor del módulo está inactivo y no habrá parche. Cuando un módulo queda abandonado, la única defensa es desinstalarlo y sustituirlo. Por eso insistimos tanto en auditar y limpiar el listado de módulos: hay puertas que ya no se pueden cerrar, solo tapiar.

Qué puede hacer un atacante cuando entra

Una inyección SQL en un módulo no es «un fallo menor». A partir de ahí, un atacante puede escalar hasta el control total de la tienda:

• Obtener acceso de administrador extrayendo o creando tokens y usuarios del back office.
• Robar datos sensibles: clientes, pedidos, direcciones y, en el peor de los casos, exponer información que debería estar protegida.
• Inyectar un skimmer (ataque Magecart) que roba los datos de tarjeta directamente del formulario de pago mientras el cliente los teclea.
• Secuestrar el correo reescribiendo la configuración SMTP de la tienda para interceptar comunicaciones, recuperar contraseñas de otros servicios o enviar spam desde tu dominio.
• Instalar puertas traseras para volver a entrar aunque actualices el módulo vulnerable.

Ese último punto es clave: parchear después de un compromiso no limpia la tienda. Si ya han entrado, hay que hacer una limpieza completa, rotar credenciales y restaurar desde una copia limpia.

Señales de que tu PrestaShop puede estar comprometido

• Usuarios administradores que no reconoces en el back office.
• Ficheros nuevos o modificados en modules/, override/ o en la raíz, con fechas raras.
• Cambios inesperados en la configuración SMTP o de correo.
• Picos de peticiones POST / en los logs sin ruta clara.
• Redirecciones extrañas, spam SEO en tu web o avisos del navegador a los visitantes.
• Tu pasarela o tus clientes reportan fraude con tarjetas usadas en tu tienda.

Cómo proteger tu PrestaShop (de forma realista)

1. Mantén el núcleo en una versión soportada. PrestaShop 8.x recibe correcciones; las versiones antiguas (1.6, ramas 1.7 sin soporte) son un riesgo creciente. Planifica la actualización si te has quedado atrás.
2. Actualiza TODOS los módulos, no solo el CMS. Y hazlo con criterio: revisa los avisos de seguridad de la comunidad (Friends-of-Presta publica advisories de módulos con regularidad).
3. Elimina lo que no uses. Cada módulo desinstalado es una puerta menos. Los módulos de autores inactivos, fuera.
4. Pon un WAF por delante. Un cortafuegos de aplicación bloquea patrones de inyección conocidos y te da margen mientras aplicas el parche. Es la única forma de aguantar la ventana entre que sale un CVE y que puedes actualizar.
5. Activa el registro de auditoría. El AuditEngine de mod_security (o equivalente) es lo que te permitirá ver ataques que de otro modo pasan como un simple POST /.
6. 2FA en el back office y contraseñas robustas para todos los administradores.
7. Backups verificados y frecuentes. Y prueba las restauraciones: una copia que no sabes restaurar no es una copia.
8. Monitorización continua. Integridad de ficheros, alertas ante nuevos usuarios admin y vigilancia de los CVE que afectan a tu stack.

Este tipo de disciplina es cada vez más urgente porque, como explicamos en nuestro artículo sobre la IA ofensiva contra tiendas online, la explotación de estos CVE está automatizada: el tiempo entre que se publica el fallo y llegan los bots se mide en horas.

Buenas prácticas para gestionar los módulos

Como el 90 % del riesgo real en PrestaShop vive en los módulos, merece la pena tener un pequeño «protocolo» de gestión:

• Inventaría lo que tienes. Haz una lista de todos los módulos instalados, su versión y su autor. No puedes proteger lo que no sabes que tienes.
• Compra en fuentes fiables. Prioriza módulos del marketplace oficial o de autores con mantenimiento activo y avisos de seguridad. Un módulo «gratis» descargado de cualquier sitio puede venir ya con puerta trasera.
• Vigila los avisos. La comunidad Friends-of-Presta publica advisories con regularidad. Suscribirte o hacer que alguien los siga por ti evita sorpresas.
• Prueba antes de actualizar en producción. Un entorno de staging te permite validar que la actualización del módulo no rompe la tienda, y así no tienes excusa para retrasar el parche.
• Da de baja lo abandonado. Si el autor de un módulo desapareció (como en el caso de CVE-2026-39079), no habrá parche jamás. Sustitúyelo por una alternativa mantenida.

Este trabajo es continuo y poco glamuroso, pero es exactamente lo que separa a una tienda que aguanta de una que acaba comprometida.

Cómo lo hacemos en Sysprovider

Mantener a raya los módulos de una tienda PrestaShop es un trabajo continuo que la mayoría de negocios no puede asumir en solitario. En Sysprovider lo integramos en nuestro hosting gestionado para PrestaShop: servidor endurecido, WAF, y actualizaciones supervisadas para que no dependas de acordarte tú.

Sobre esa base, SysSecure 360 aporta la vigilancia que estos fallos exigen: nuestro NOC con monitorización 24/7 y gestión de CVEs rastrea las vulnerabilidades que afectan a tu tienda y a sus módulos, y actuamos antes de que lleguen los ataques automatizados. Y con copias verificadas y Disaster Recovery tienes la red de seguridad para recuperar la tienda si algo se tuerce.

Si quieres seguir profundizando, tenemos una guía específica sobre seguridad en PrestaShop y Magento, y si estás valorando plataforma, te puede interesar nuestra comparativa PrestaShop vs WooCommerce.

Preguntas frecuentes

¿PrestaShop es inseguro?

No más que otras plataformas. El núcleo de PrestaShop está bien mantenido; la inmensa mayoría de incidentes vienen de módulos de terceros desactualizados o abandonados. Con una buena gestión de módulos y una capa de vigilancia, PrestaShop es perfectamente seguro para producción.

¿Con actualizar PrestaShop es suficiente?

No. Tienes que actualizar también todos los módulos y eliminar los que no uses. Muchas tiendas tienen el CMS al día pero un módulo de hace tres años con una inyección SQL crítica sin parchear.

¿Cómo sé si un módulo tiene una vulnerabilidad conocida?

Consultando las bases de datos de CVE y los avisos de la comunidad (como Friends-of-Presta). Si no quieres hacer ese seguimiento manualmente, nuestro NOC lo hace por ti y te avisa cuando algo te afecta.

Me han hackeado la tienda, ¿basta con actualizar el módulo?

No. Si ya entraron, seguramente dejaron una puerta trasera. Hay que hacer una limpieza completa, rotar credenciales y restaurar desde una copia limpia. Actualizar solo cierra la puerta original, no expulsa al que ya está dentro.

Conclusión

Las vulnerabilidades de PrestaShop no son motivo para huir de la plataforma —es un CMS sólido y muy capaz—, pero sí un recordatorio de que una tienda es software vivo que hay que mantener. La mayoría de los desastres que vemos se habrían evitado con dos hábitos: actualizar (o eliminar) módulos a tiempo y tener una capa de vigilancia que detecte lo que los logs normales no ven.

Si prefieres delegar esa disciplina en un equipo que la aplica todos los días, en Sysprovider nos encargamos de que tu PrestaShop esté parcheado, monitorizado y respaldado. Cuéntanos tu caso y lo revisamos.