Vulnerabilidades en PrestaShop 8 y 9: versiones afectadas y cómo actualizar con seguridad

PrestaShop publicó el 18 de agosto de 2026 dos actualizaciones de seguridad: PrestaShop 8.2.8 y PrestaShop 9.1.5. Ambas corrigen las mismas cinco vulnerabilidades, tres clasificadas con severidad alta y dos con severidad moderada.

Que una versión sea vulnerable no significa que la tienda haya sido comprometida. Cada fallo requiere unas condiciones concretas: algunos necesitan una cuenta de empleado, otro depende de abrir un CSV manipulado y uno afecta especialmente a instalaciones situadas detrás de un proxy, balanceador o CDN. Aun así, si la tienda ejecuta una versión afectada, la recomendación oficial es actualizar.

Qué versiones de PrestaShop están afectadas

Los cinco avisos oficiales comparten la misma matriz para las ramas con soporte. Las versiones corregidas son 8.2.8 y 9.1.5.

El último punto necesita precisión: el advisory de la inyección SQL confirma expresamente que el código defectuoso también existe en PrestaShop 1.7.x y versiones anteriores, ya fuera de soporte. No implica que las cinco vulnerabilidades se hayan confirmado en todas esas ramas.

Las cinco vulnerabilidades, explicadas sin alarmismo

1. Fórmulas ejecutables en exportaciones CSV

Severidad: alta. PrestaShop exportaba determinados valores sin neutralizar caracteres que una hoja de cálculo puede interpretar como fórmulas. Si un atacante consigue introducir un valor preparado en un campo que después se exporta, el riesgo aparece cuando un comerciante, empleado, gestoría o cliente abre ese archivo con una aplicación de hojas de cálculo.

No se ejecuta código en el servidor por el simple hecho de generar el CSV. La explotación requiere contenido manipulado y que una persona abra el archivo en un programa que procese la fórmula. Hasta actualizar, el advisory aconseja importar los CSV como texto, no habilitar contenido ni actualizar enlaces y revisar valores que comiencen por caracteres como =, +, - o @.

Consultar el advisory oficial sobre CSV injection.

2. Peticiones internas mediante imágenes de una importación CSV

Severidad: alta. Al importar productos, PrestaShop puede descargar las imágenes indicadas en el CSV. Antes del parche, el servidor no validaba suficientemente esas direcciones. Un archivo preparado podía conseguir que el servidor solicitara recursos internos o direcciones que no deberían ser accesibles desde fuera.

Este escenario no está abierto a cualquier visitante: requiere una cuenta de back office con permiso para importar y el uso de un CSV malicioso o no fiable. El impacto potencial es importante, pero la condición de acceso reduce la exposición práctica. Además de actualizar, conviene limitar el permiso de importación y evitar que el servidor web pueda conectarse sin restricciones a redes privadas o servicios internos.

Consultar el advisory oficial sobre SSRF en la importación.

3. Suplantación de la dirección IP detrás de un proxy o CDN

Severidad: alta. En una arquitectura con proxy inverso, balanceador o CDN, la IP del visitante suele llegar a PrestaShop mediante la cabecera X-Forwarded-For. La aplicación leía el extremo de la cadena que puede controlar el visitante en lugar del valor añadido por la infraestructura de confianza.

Un visitante sin cuenta podía aparentar otra IP. Esto podía debilitar la lista de acceso del modo mantenimiento, contaminar registros y afectar a controles de geolocalización, limitación de peticiones o fraude que dependieran de esa dirección. Las tiendas donde el usuario se conecta directamente al servidor web no están afectadas por este escenario concreto.

Actualizar el core es necesario, pero no sustituye la revisión de infraestructura. El proxy debe sobrescribir la cabecera recibida y el servidor de origen debería aceptar tráfico únicamente desde los rangos autorizados del CDN o balanceador.

Consultar el advisory oficial sobre X-Forwarded-For.

4. Inyección SQL desde filtros del back office

Severidad: moderada. Los nombres de algunos filtros de listados del back office no se validaban correctamente antes de utilizarlos en una consulta. Un empleado autenticado podía preparar un filtro para acceder a información situada fuera de los permisos de su perfil. El investigador pudo demostrarlo incluso con el perfil incorporado más restrictivo.

No es un ataque anónimo desde la tienda pública: exige una sesión válida de empleado. Sin embargo, es relevante en negocios donde acceden agencias, personal temporal, atención al cliente o colaboradores con permisos limitados. El advisory no ofrece una solución de configuración alternativa: la corrección es actualizar.

Consultar el advisory oficial sobre inyección SQL.

5. Información de clientes visible para empleados sin permiso

Severidad: moderada. El endpoint que alimenta las notificaciones del back office no comprobaba los permisos del empleado. Cualquier cuenta autenticada, incluso con un perfil sin permisos, podía consultar datos recientes como nombres de clientes, importes de pedidos, transportistas y estados.

La tienda pública y los visitantes anónimos no intervienen en este caso. El riesgo se concentra en instalaciones que confían en perfiles restringidos para separar funciones entre empleados, agencias o proveedores. Al tratarse de datos personales, también merece atención desde la gestión de privacidad. No existe un ajuste que corrija el endpoint sin aplicar el parche.

Consultar el advisory oficial sobre control de acceso.

Qué riesgo existe realmente para una tienda

La prioridad no debería decidirse únicamente por la etiqueta de severidad. Conviene cruzar la versión instalada con el funcionamiento real de la tienda:

• Si se realizan importaciones y exportaciones CSV, dos de los fallos afectan directamente a procesos habituales.
• Si varias personas o proveedores acceden al back office, cobran más importancia la inyección SQL y el acceso indebido a notificaciones.
• Si la tienda utiliza Cloudflare, otro CDN, un balanceador o un proxy inverso, hay que revisar tanto el parche como la configuración de cabeceras.
• Si la instalación es 1.7 o anterior, al menos el fallo SQL permanece sin parche oficial y se suma al riesgo de operar sobre una rama fuera de soporte.

La ausencia de señales visibles tampoco demuestra que un sistema esté limpio, pero ejecutar una versión afectada no demuestra que haya habido un ataque. Lo profesional es corregir la exposición, revisar registros cuando el contexto lo justifique y evitar conclusiones que no estén respaldadas por evidencias.

¿Debo actualizar inmediatamente?

Si utilizas PrestaShop 8.0–8.2.7 o 9.0–9.1.4, deberías planificar la actualización con prioridad. “Con prioridad” no significa pulsar el botón en producción sin preparación. Significa iniciar ya la revisión, probar el cambio en un entorno seguro y no aplazarlo indefinidamente.

PrestaShop recomienda actualizar a 8.2.8 o 9.1.5. En una instalación estándar el proceso puede ser directo; en una tienda con módulos de terceros, overrides, tema personalizado o integraciones empresariales, la actualización puede descubrir incompatibilidades que no guardan relación con las vulnerabilidades.

Por eso una actualización o migración de PrestaShop debe tratarse como un cambio controlado, con posibilidad real de volver atrás si las pruebas no son satisfactorias.

Cómo actualizar una tienda PrestaShop de forma segura

Un proceso profesional no necesita ser interminable, pero sí cubrir los puntos que sostienen la venta:

1. Inventario y compatibilidad. Confirmar versión exacta de PrestaShop y PHP; revisar módulos, tema, overrides e integraciones con ERP, PIM, logística, pagos o marketing.
2. Copia recuperable. Guardar archivos y base de datos y comprobar que existe un procedimiento de restauración, no sólo un archivo de backup.
3. Pruebas en staging. Replicar la tienda en un entorno aislado, aplicar allí la actualización y revisar errores, registros y tareas programadas antes de tocar producción.
4. Validación del negocio. Probar catálogo, búsqueda, cuenta de cliente, carrito, descuentos, impuestos, transportistas, checkout, pagos, pedidos, facturas, emails, stock, devoluciones, webhooks y cron.
5. Revisión de infraestructura. Verificar cachés, proxy, CDN y cabeceras de IP, especialmente por la vulnerabilidad de X-Forwarded-For.
6. Despliegue y observación. Elegir una ventana adecuada, disponer de rollback y monitorizar logs, conversiones, pagos y procesos automáticos tras la actualización.

Este procedimiento reduce el riesgo de que una corrección de seguridad termine provocando fallos en el checkout, discrepancias de stock o pérdida de comunicaciones con servicios externos. También es una parte natural de un servicio de mantenimiento PrestaShop: conocer el estado de la plataforma antes de que una actualización sea urgente.

Qué ocurre con las tiendas antiguas

PrestaShop 8.2 se encuentra en soporte extendido y recibe principalmente correcciones críticas y de seguridad. Las instalaciones 1.7 y anteriores están fuera de soporte. En concreto, el equipo de PrestaShop confirma que el código de la inyección SQL también está presente en 1.7.x y versiones anteriores y que no recibirán un parche.

Para una tienda antigua, copiar manualmente una corrección aislada puede parecer más sencillo que migrar, pero deja sin resolver el resto de deuda técnica: PHP obsoleto, módulos abandonados, incompatibilidades y futuras vulnerabilidades. La decisión debería partir de una evaluación de la tienda y terminar en un plan de migración verificable, no en una sucesión de parches improvisados.

La decisión práctica

Comprueba primero la versión exacta. Si está dentro de los rangos afectados, prepara la actualización a 8.2.8 o 9.1.5 y revisa especialmente empleados, importaciones CSV e infraestructura de proxy o CDN. Si utilizas PrestaShop 1.7 o una rama anterior, la ausencia de parche para el fallo SQL convierte la migración en una cuestión de seguridad, además de mantenimiento.

Si necesitas actualizar una versión afectada sin comprometer módulos, tema, integraciones o el funcionamiento del checkout, PsDevs puede revisar el entorno y preparar una actualización controlada. Cuéntanos qué versión utilizas y estudiaremos el alcance antes de intervenir.

Fuentes oficiales

• PrestaShop 8.2.8 is available.
• PrestaShop 9.1.5 is available.
• Security Advisories del repositorio oficial de PrestaShop.