Las mejoras importantes que aportamos a PrestaSecure para proteger tu tienda.
Última actualización: 17 octubre 2026
Tras un análisis, un aviso al principio de la lista de hallazgos indica cuántos parches están listos para su tienda y los aplica con un clic, en el módulo y en su espacio PrestaSecure. Se aplican uno tras otro, cada uno con su copia de seguridad previa, y se pueden deshacer uno a uno. Todas las ofertas pueden aplicar un parche desde su espacio PrestaSecure; con Serenity, nuestro equipo los aplica por usted.
Una regla contra la inyección SQL reaccionaba por error a ciertas secuencias de caracteres presentes en las imágenes enviadas por los módulos de personalización, en cookies, en los tokens de retorno de pago de PayPal o en los identificadores de clic publicitario. Ahora solo apunta a los verdaderos intentos de inyección, que siguen todos bloqueados.
Según la configuración del servidor, PHP puede ejecutar estas extensiones: los archivos maliciosos depositados con estos nombres escapaban hasta ahora al análisis. Todas las extensiones ejecutables (.php, .php3 a .php8, .phtml, .pht, .phar) se controlan ahora.
En una tienda migrada, por ejemplo de PrestaShop 8 a 9, el módulo comparaba los archivos del núcleo con los originales de la versión anterior y los señalaba por miles como modificados. Ahora lee la versión real en cada análisis, y su espacio PrestaSecure muestra la nueva versión del módulo en cuanto se actualiza automáticamente.
Un módulo de terceros mal escrito ya no bloquea el final de un análisis: PrestaSecure ya no carga los módulos de la tienda durante el escaneo. Deshacer un parche solo retira ahora los archivos que el propio parche creó y que no han cambiado desde entonces.
Ocho pestañas en su back-office, con el menú de PrestaShop: Resumen, Análisis, Cortafuegos, Conexiones, Historial, Ajustes, Informe y Ayuda. La nota, las vulnerabilidades y los hallazgos los calcula PrestaSecure: el módulo y su espacio de cliente muestran las mismas cifras y proponen las mismas acciones. El Resumen ordena lo que hay que hacer, de lo más urgente a lo menos urgente.
Tanto si se lanza desde el módulo, desde su espacio PrestaSecure o por nuestro equipo, el análisis en curso muestra su progreso y las amenazas encontradas, la más grave primero. Un archivo señalado se abre con las líneas en cuestión resaltadas, un archivo del núcleo se compara con el original de su versión y los archivos añadidos o modificados en un análisis también se pueden leer. Los archivos con los accesos de la tienda nunca se muestran.
Un archivo del núcleo de PrestaShop se restaura desde el original, nunca se pone en cuarentena. Para los demás archivos, la cuarentena pasa por un aviso: retirar un archivo en uso puede romper el sitio. Puede pedir la opinión de PrestaSecure, ofrecida sin plazo ni compromiso (3 solicitudes al mes); con Serenity, señala el archivo a nuestro equipo. Un archivo ignorado reaparece si su contenido cambia, y toda cuarentena se puede restaurar.
Tras limpiar la base de datos, la alerta seguía mostrándose hasta que alguien la marcaba como corregida a mano. El módulo indica ahora a PrestaSecure si ha leído realmente la base durante el análisis: si es así y la tabla ya no está afectada, la alerta se cierra. Si la lectura ha fallado, la alerta sigue abierta, porque un análisis que no ha podido leer nada no demuestra nada.
Un código malicioso puede escribirse directamente en la base de datos, por ejemplo en la nota de una ficha de cliente. Se ejecuta entonces en el navegador del empleado que abre la ficha o el pedido, y puede enviar la dirección de su back office a un tercero. Como no se modifica ningún archivo, ni el análisis de archivos ni el de las páginas de la tienda podían verlo. El análisis controla ahora las notas de clientes, los complementos de dirección y los mensajes de pedidos y del servicio al cliente. PrestaShop rechaza este tipo de contenido al introducirlo: su presencia indica una escritura directa en la base. La alerta aparece en su espacio PrestaSecure con el número de fichas afectadas, y nuestro equipo recibe el aviso.
En una tienda cuya tarea programada se ejecuta cada quince minutos, un nuevo análisis completo empezaba en cuanto terminaba el anterior, hasta varias decenas al día: una carga inútil para su servidor. La tarea programada sigue terminando un análisis en curso, pero solo inicia uno nuevo si el último tiene más de veinte horas. Los análisis que usted lanza no cambian.
El widget de inicio enumera cada corrección disponible con el módulo afectado, la naturaleza del fallo en palabras sencillas y los días transcurridos desde su detección. Un clic basta para aplicarla, tras una copia de seguridad automática; la vuelta atrás sigue siendo posible. La puntuación de seguridad muestra también la que tendría la tienda una vez aplicadas las correcciones, y el cortafuegos indica las peticiones rechazadas en las últimas 24 horas.
Cuando una corrección no se aplica, su tienda no se modifica y el módulo se lo indica con claridad, con una referencia de seguimiento. Nuestro equipo recibe el aviso y revisa la corrección; usted recibe un correo en cuanto se repara, y el botón de aplicación vuelve por sí solo.
Una dirección que encadena ataques queda bloqueada 15 minutos al tercer intento, 2 horas al quinto y 24 horas al décimo. El contador se reiniciaba en cada petición: cada ataque se rechazaba, pero el atacante podía insistir sin límite y probar variantes. El contador se conserva ahora, y una dirección ya bloqueada que reincide queda bloqueada más tiempo.
Algunos robots encadenan páginas de categorías con filtros apilados o listas de cientos de productos. El cortafuegos ya los rechazaba, pero solo una vez cargada la tienda, tras cientos de consultas a la base: en un alojamiento compartido limitado, eso bastaba para tumbar el sitio. Estas peticiones las rechaza ahora el propio servidor web, con una página ligera, sin tocar la base. Este filtrado sigue su licencia y se retira solo si el módulo se desactiva.
Tras cada corrección, el módulo vuelve a leer el archivo y solo confirma el éxito si su contenido ha cambiado realmente. Cada archivo modificado se verifica y, en caso de error, la versión original se restaura automáticamente. Un código ya neutralizado por su desarrollador se reconoce y se deja tal cual.
Una carpeta de módulo presente en el servidor pero desinstalada de la tienda puede contener un fallo explotable. Estas carpetas huérfanas estaban ocultas y no se podían retirar cuando se trataba de un módulo incluido con PrestaShop. Ahora se muestran como tales y pueden eliminarse, tras una copia de seguridad puesta en cuarentena. Un módulo instalado en su tienda nunca se toca.
En PrestaShop 8 y 9, el código introducido en la pantalla de verificación no llegaba a nuestro servicio desde algunas páginas del back office: el empleado volvía a la pantalla de entrada creyendo que el código era incorrecto. Está corregido. Una dirección validada desde su espacio de cliente o por nuestro equipo se aplica ahora en menos de un minuto, en lugar de esperar la tarea programada de su tienda; lo mismo ocurre al desactivar la protección. Por último, cuando no se puede emitir un código, la puerta permanece cerrada y la pantalla indica cuánto esperar: ningún acceso sin validación.
Un inicio de sesión en su administración desde una dirección que su tienda nunca ha usado puede ahora quedar en espera hasta que se introduzca un código enviado por correo. La protección empieza en observación: durante los primeros días solo registra las direcciones que su equipo utiliza, sin bloquear a nadie ni enviar nada. Usted decide después cuándo activarla, una vez completada la lista. Plan Advance y superiores.
Detrás de Cloudflare o de un balanceador, todas las conexiones parecían venir de la misma dirección, lo que impedía cualquier distinción. Ahora leemos la dirección de origen, pero solo cuando la petición procede de un intermediario que reconocemos: una cabecera falsificada por un atacante no puede suplantar una dirección de confianza.
Cuando una corrección de seguridad no encontraba el archivo previsto, concluíamos que el fallo había desaparecido. Suele ser cierto, pero no siempre: el archivo puede estar en otro sitio del que buscábamos, con el fallo aún presente. Ahora distinguimos ambos casos, y ninguna tienda se considera a salvo sin pruebas.
Nuestras correcciones de seguridad sustituyen un bloque de código byte a byte, para no tocar nunca nada más que lo previsto. Pero un mismo archivo no se escribe igual según se haya guardado desde Windows o desde un servidor: los finales de línea difieren, de forma invisible. En esas tiendas la corrección ya no reconocía el bloque previsto y se abstenía, por prudencia. El motor reexpresa ahora el patrón en el estilo del archivo que tiene delante: la protección se aplica en todas partes, sin reescribir nada al azar.
Ocultar código malicioso en un archivo que se presenta como una imagen es una técnica probada: el archivo lleva la extensión de una foto, pero el servidor encuentra instrucciones dentro. Los buscábamos donde llegan archivos del exterior: las carpetas de subida y descarga. La dificultad no es mirar en otra parte, sino hacerlo sin releer los cientos de miles de imágenes legítimas de su catálogo en cada análisis. Ahora olfateamos la cabecera de cada imagen en todas partes, incluidos sus temas, módulos y bibliotecas, y solo examinamos a fondo las que realmente contienen código. El escaneo sigue siendo igual de rápido y ya no deja ese rincón de lado.
En cuanto se señala un archivo, nuestro sistema lo estudia a fondo. Ahora ves en tu panel hacia dónde se inclina ese análisis, probable falsa alarma o amenaza real, junto con su nivel de confianza, sin esperar a que intervengamos por detrás. Así sabes enseguida qué merece tu atención.
Algunos comerciantes alojan también un WordPress dentro de su tienda PrestaShop. No es recomendable, pero ocurre, y su núcleo a veces disparaba alertas por error. Lo mismo pasaba con las bibliotecas de prueba que acompañan a ciertos módulos y con los archivos JavaScript comprimidos. El escáner ahora reconoce estos componentes normales y los deja a un lado, sin bajar la guardia con los archivos realmente peligrosos. Tus informes de análisis se leen mejor.
Algunos atacantes injertan un script invisible en la página de acceso de tu back-office para captar tu usuario y tu contraseña cada vez que entras, y luego se reinstalan solos tras un simple cambio de contraseña. Así es como vuelven día tras día. Ahora detectamos este tipo de injerto: un script cargado a escondidas en la administración y una marca oculta en el navegador, incluso cuando el atacante renombra los archivos para despistar. Detectado en una tienda real, esta trampa pasaba desapercibida y ahora dispara una alerta crítica.
En tiendas con una enorme cantidad de archivos, o con registros de actividad pesados, el análisis podía detenerse a mitad por falta de memoria. Ahora controla su consumo sobre la marcha y llega hasta el final, sea cual sea el tamaño del sitio.
Hemos reforzado la detección de skimmers de tarjeta (tipo Magecart) que ocultan su dirección de recogida en forma codificada dentro de un script o una imagen falsa, así como de los cargadores que ejecutan una puerta trasera descargada desde un servidor externo, incluso cuando el código está disimulado a propósito. Detectados en tiendas reales, estos patrones aparecen ahora como alerta crítica en vez de pasar desapercibidos.
Ahora rastreamos las puertas traseras que se camuflan, disfrazando su código (por ejemplo jugando con las mayúsculas y minúsculas para engañar a los antivirus) o reinstalándose solas mediante un archivo descargado desde el exterior. Detectadas en tiendas reales, a menudo ocultas en módulos piratas, estas trampas pasaban hasta ahora «desapercibidas»: ahora disparan una alerta crítica.
Se acabó la página abrupta de «Acceso denegado». Tras varios intentos, el cliente ve el formulario de acceso habitual con un mensaje claro: demasiados intentos, tiempo de espera restante y un enlace para restablecer su contraseña. El umbral se ha relajado para no penalizar a quien solo se equivoca de contraseña, bloqueando al instante los ataques automatizados.
Consulta el contenido de un archivo señalado, o su comparación con la versión oficial de PrestaShop, directamente desde tu panel PrestaSecure, sin SSH ni FTP. Acceso de solo lectura, limitado a tu tienda y a tipos de archivo seguros.
El escáner ahora inspecciona la configuración y los contenidos editoriales mostrados en tu tienda, no solo los archivos. Así se cierra un punto ciego que algunos atacantes aprovechan para inyectar un script de robo de tarjetas fuera de los archivos del sitio, un vector visto en un incidente real.
Catálogos de varios millones de archivos, multitienda: el análisis ahora cubre todo el parque, sin truncamiento ni desbordamiento de memoria, encadenando varias pasadas automáticas si hace falta. No se deja fuera ninguna zona del sitio.
Los análisis recurrentes ahora solo revisan los archivos realmente modificados desde la última vez, en lugar de recorrerlo todo. El ahorro de tiempo es enorme en tiendas grandes, sin perder cobertura: un solo byte modificado se sigue detectando.
El informe se construye ante tus ojos: las amenazas aparecen a medida que avanza el análisis, con su gravedad y agrupación, en lugar de esperar al final.
El módulo analiza el registro de errores PHP de tu tienda en busca de firmas de ataque conocidas (inyección de plantillas, intentos de leer archivos de configuración sensibles, inclusión de archivos remotos…). Los atacantes suelen dejar meses de intentos fallidos antes de lograrlo: se te avisa desde las primeras señales.
Ya no se omite ninguna carpeta en el análisis (dependencias, temas, back office, carpetas de subida…). El código malicioso puede esconderse en cualquier lugar, incluida una dependencia o un webshell colocado en la administración. El análisis cubre ahora todo el sitio.
Corrige en pocos clics: aplicación de parches de seguridad validados, limpieza de archivos infectados, eliminación de módulos fantasma (presentes en disco pero desconocidos para PrestaShop) y actualización de módulos vulnerables, todo con copia de seguridad y reversión automáticas.
Una insignia indica, para cada vulnerabilidad detectada, si ya está neutralizada por el cortafuegos de aplicaciones PrestaSecure. Distingues de un vistazo lo protegido de lo que requiere acción.
Aplica los parches de vulnerabilidades conocidas del núcleo de PrestaShop y de los módulos desde tu panel, con copia de seguridad previa, verificación automática tras aplicarlos y opción de deshacer en cualquier momento.
Primera versión: panel de protección con puntuación, antivirus (análisis de archivos y huellas), cortafuegos de aplicaciones (inyección SQL, XSS, fuerza bruta, salto de directorio), herramientas de remediación, informe de seguridad exportable y actualizaciones automáticas del módulo.