Vulnerabilidad ps_facetedsearch: la actualización de PrestaShop que no puede saltarse

Un 10 sobre 10 explotable sin ninguna cuenta

El 3 de junio de 2026, el equipo de PrestaShop publicó un parche de urgencia para ps_facetedsearch, el módulo de búsqueda por facetas que viene instalado de serie en prácticamente todas las tiendas desde la versión 1.7.1.0. La vulnerabilidad corregida alcanza la puntuación máxima de la escala CVSS: 10.0.

Tres rasgos la convierten en un problema serio:

• no exige autenticación alguna: ni cuenta de cliente ni acceso al back-office;
• se explota desde el front-office, con una simple petición HTTP;
• desemboca en una ejecución remota de código, es decir, en la subida a su servidor de un archivo PHP que el atacante controla.

Dicho de otro modo: un robot que rastrea tiendas PrestaShop puede tomar el control de la suya sin que quede el menor rastro en su historial de administración.

Cómo funciona la vulnerabilidad

El módulo guarda en caché los bloques de filtros para no recalcular las facetas en cada visita. Los valores de los filtros de deslizador (precio, peso) se leen de la URL y se almacenan serializados en esa caché.

El fallo está en la relectura. Hasta la versión 4.0.3, el módulo aplicaba a esos valores la función nativa de PHP unserialize() sin validarlos lo suficiente antes. Un atacante puede, por tanto, construir una URL que contenga un objeto PHP malicioso. Al deserializarse, ese objeto dispara una cadena de gadgets presente en las dependencias de PrestaShop y termina escribiendo un archivo arbitrario dentro de la carpeta del módulo.

El parche oficial sustituye unserialize() por \Tools::unSerialize(), la capa segura de PrestaShop.

¿Le afecta a usted?

Versiones vulnerables: 3.0.0 a 4.0.3. Versión corregida: 4.0.4.

Compruebe la suya en Módulos > Gestor de módulos, buscando «Búsqueda por facetas». También puede leer la etiqueta <version> del archivo modules/ps_facetedsearch/config.xml.

En la base de datos basta una consulta:

SELECT name, version FROM ps_module WHERE name = 'ps_facetedsearch';

Por debajo de 4.0.4, dé la tienda por expuesta, aunque los filtros solo se muestren en unas pocas categorías: el controlador sigue siendo accesible.

El parche: dos caminos posibles

Actualizar el núcleo. PrestaShop publicó ese mismo día las versiones 8.2.7 y 9.1.4, que ya incorporan el módulo corregido. Es la vía recomendada si su tienda está cerca de esas versiones.

Actualizar solo el módulo. Descargue ps_facetedsearch 4.0.4 del repositorio oficial y reemplace la carpeta. Es la opción más rápida cuando subir de versión el núcleo implica una campaña de pruebas de verdad.

En ambos casos, vacíe var/cache/prod/ al terminar y purgue la caché del módulo. Si no puede intervenir de inmediato, aplique las mitigaciones publicadas junto al aviso de seguridad: retirar los filtros de deslizador de las plantillas públicas, vaciar la caché de la búsqueda por facetas y bloquear en el cortafuegos de aplicaciones web las peticiones cuya query string contenga patrones de serialización PHP (O:, ;i:).

Comprobar si ya han entrado

Un parche no cierra una puerta que ya se ha usado. Después de actualizar, busque rastros de archivos subidos.

Archivos PHP modificados recientemente dentro de los módulos:

find modules/ -name "*.php" -mtime -60 -ls

Patrones típicos de puerta trasera:

grep -rl "eval(\$_POST\|eval(base64_decode\|assert(\$_REQUEST" modules/ themes/ override/

Revise además:

• la carpeta modules/ps_facetedsearch/: cualquier archivo .php ajeno a la distribución oficial es sospechoso;
• los logs de acceso de su alojamiento, en busca de peticiones con cadenas anormalmente largas;
• la tabla ps_employee: una cuenta de administrador que no reconoce delata una intrusión instalada para durar;
• los archivos .htaccess y robots.txt, que suelen modificarse para esconder páginas de spam.

Si encuentra algo, no se limite a borrar el archivo. Una intrusión casi siempre viene acompañada de una segunda puerta trasera. Hay que cambiar todas las contraseñas de los empleados, regenerar las claves de config/settings.inc.php, empezando por _COOKIE_KEY_, y restaurar una copia de seguridad anterior a la intrusión. Nuestro artículo sobre una tienda PrestaShop hackeada detalla el procedimiento completo.

La lección: un módulo de serie no es un módulo seguro

Muchos comerciantes vigilan sus módulos de terceros y dejan que los nativos vivan su vida. Este episodio recuerda que el código entregado por defecto está presente en cientos de miles de tiendas: es justamente el que más interesa a los atacantes.

Tres hábitos reducen el riesgo de forma espectacular:

• seguir las publicaciones de seguridad de PrestaShop y de Friends-of-Presta;
• aplicar los parches de seguridad en menos de 72 horas, pasando por un entorno de preproducción cuando la tienda es compleja;
• mantener un inventario de las versiones de los módulos, para responder en cinco minutos a la pregunta «¿me afecta?».

Es exactamente lo que cubre un contrato de mantenimiento de PrestaShop.

¿Necesita una auditoría ahora mismo?

Comprobamos su versión, aplicamos el parche y buscamos rastros de intrusión. Diagnóstico gratuito, respuesta en menos de 1 h, de 9:00 a 22:00 los 7 días de la semana.