Módulos huérfanos en PrestaShop: el código que nadie mira y que sigue respondiendo

Una tienda con años de recorrido acumula módulos como un trastero acumula cajas. Se probó un módulo de reseñas, se cambió de pasarela, se instaló algo para una campaña de Navidad. Se desinstalaron desde el back-office, pero las carpetas siguen ahí, en modules/, con todo su código.

A esas carpetas las llamamos módulos huérfanos. No aparecen en el gestor de módulos, nadie las actualiza, y en muchas tiendas su PHP sigue respondiendo a quien lo pida por URL.

Por qué quedan huérfanos

• Desinstalar no es borrar. En PrestaShop, desinstalar ejecuta el uninstall() del módulo (que quita sus tablas y su configuración) pero la carpeta puede quedarse en disco. Borrarla es otra acción, y muchas veces no se hace.
• Migraciones y copias. Al migrar o restaurar, se copian carpetas de módulos que en la tienda nueva nunca se instalan.
• Subidas por FTP. Alguien subió un módulo por FTP para probarlo y nunca llegó a instalarlo.
• Restos de temas. Algunos temas comerciales traen sus propios módulos; al cambiar de tema, los del anterior se quedan.

Por qué son un riesgo

Código vulnerable que no se actualiza nunca

Un módulo instalado, aunque sea viejo, al menos aparece en la lista y alguien puede ver que tiene actualización. Un huérfano no aparece en ninguna parte. Si su versión tenía una vulnerabilidad conocida, la seguirá teniendo para siempre.

Su PHP se sigue ejecutando

Aquí está lo importante. Que el módulo no esté instalado no impide que sus ficheros respondan. Muchos módulos antiguos traen ficheros PHP pensados para pedirse directamente por URL: un ajax.php, un validation.php, un script de importación. Esos ficheros arrancan PrestaShop por su cuenta y hacen su trabajo, estén registrados o no.

En PrestaShop 8 y anteriores, la carpeta modules/ no trae ninguna protección de serie que impida ejecutar esos .php. PrestaShop 9 sí incluye un .htaccess en modules/ que deniega los .php pedidos directamente, lo que cierra gran parte del problema en Apache y LiteSpeed. Pero los controladores front que pasan por el despachador de PrestaShop siguen siendo accesibles si el módulo está instalado, y en Nginx el .htaccess se ignora.

Un escondite cómodo

Para un atacante, una carpeta que nadie mira es el sitio ideal para dejar una puerta trasera. Un fichero nuevo dentro de un módulo huérfano tiene muchas menos probabilidades de ser visto que uno en la raíz.

Cómo inventariarlos

La idea es cruzar dos listas: las carpetas de modules/ en disco y los módulos registrados en la base de datos.

1. Saca la lista de módulos registrados. En la base de datos: SELECT name, active, version FROM ps_module ORDER BY name;
2. Saca la lista de carpetas de modules/, desde el gestor de ficheros del hosting o por SSH.
3. Las carpetas que no están en la primera lista son huérfanas. Anota de cada una: si tiene ficheros .php fuera de controllers/, su versión (en config.xml o en el fichero principal) y la fecha de sus ficheros.
4. Distingue los instalados pero desactivados. Esos sí están en la lista, pero también merecen revisión: si no se usan, conviene desinstalarlos y borrarlos.
5. Marca los sospechosos. Un módulo con autor desconocido, sin documentación, con una compatibilidad declarada imposible o con una descripción que no describe nada, probablemente no lo instaló nadie de tu equipo.

Cómo retirarlos sin romper el tema

Borrar una carpeta parece trivial, pero hay casos en que algo depende de ella:

• Plantillas del tema que incluyen ficheros de un módulo. Algunos temas llaman directamente a plantillas o CSS de módulos concretos. Busca el nombre del módulo en la carpeta del tema antes de borrar.
• Overrides huérfanos. Un módulo desinstalado puede haber dejado ficheros en override/ que sigan ejecutándose. Revisa esa carpeta y, si quitas un override, borra también la caché de clases.
• Módulos que otro módulo usa como librería. Pasa con algunos paquetes que comparten una carpeta común entre varios módulos del mismo autor.
• Crons externos que llaman a un fichero del módulo. Si el panel del hosting tiene una tarea programada que apunta a esa carpeta, fallará; mejor saberlo antes.

El procedimiento seguro:

1. Haz una copia de seguridad de ficheros y base de datos.
2. En lugar de borrar, mueve la carpeta fuera del directorio web (o renómbrala si no tienes otra opción) y deja pasar unos días.
3. Navega la tienda, haz un pedido de prueba, revisa el back-office y los registros de errores.
4. Si nada se ha quejado, bórrala definitivamente.
5. Repite el inventario cada pocos meses, o cada vez que se desinstale algo.

Lo que conviene hacer además

• Bloquea la ejecución directa de PHP en modules/ si tu tienda es anterior a PrestaShop 9, con excepciones solo para los ficheros que de verdad lo necesiten.
• Escanea los huérfanos antes de borrarlos: si alguno contiene una puerta trasera, borrar sin más te deja sin saber cómo entraron ni qué más hicieron.
• Aprovecha una migración para empezar con modules/ limpio: en una tienda nueva solo entra lo que se instala de verdad. Es una de las ventajas menos comentadas de dejar atrás una 1.6 o una 1.7 con años de restos.

Cómo resolverlo en PrestaShop

RKR Security Alert busca dentro de modules/ las carpetas sin registro en la base de datos y gradúa su gravedad por lo que contienen: informativo si solo hay recursos, crítico si hay PHP alcanzable con hallazgos. También mira qué extensiones deniega de verdad el .htaccess de modules/ y las cruza con los puntos de entrada que va encontrando, para responder a cuántos ficheros de módulo puede pedir cualquiera desde fuera, y cuenta los módulos instalados que no están cubiertos por la línea base de integridad. Si prefieres que lo hagamos nosotros, con un bono de horas de soporte de Rekire inventariamos los módulos de tu tienda, retiramos los que sobran comprobando que no rompen el tema y te dejamos la lista de lo que conviene actualizar.