Caso Comas Trial: login PrestaShop vacío por malware (y por qué hay que actualizar PrestaShop)

Caso real: comastrial.com/shop/ — Comas Trial, tienda B2B de recambios y trial para moto en España.

El cliente avisó con urgencia: ni el personal ni los clientes podían iniciar sesión. La página de login cargaba (cabecera y pie bien), pero no había campos de usuario ni contraseña. Empezaban a llamar a la tienda. En PrestaShop, sin login no hay cuenta, no hay pedidos en curso visibles para el cliente y el B2B se para.

La tienda corría PrestaShop 1.6.1.24 (tema default-bootstrap personalizado). Versión antigua. End-of-life. Justo el escenario en el que conviene plantear actualizar PrestaShop — pero primero había que devolver el acceso.

Qué se veía

No era una pantalla en blanco total. Era más engañoso:

• Título y layout “normales”.
• URLs de login tipo /shop/en/inicio-sesion?back=my-account y /shop/es/inicio-sesion?back=my-account.
• En el HTML, #center_column estaba vacío.
• No era CSS ocultando el formulario: la plantilla de autenticación no se estaba asignando.
• El enlace de login del header B2B apuntaba a “mi cuenta”; el invitado redirigía a autenticación… y allí no había formulario.

Para el dueño: “el login no funciona”. Para el HTML: no había login_form, ni #email, ni #passwd.

Diagnóstico: no era (solo) caché ni el tema

En estos casos se suele mirar primero caché Smarty, la plantilla authentication.tpl o un módulo de cabecera. Aquí el template aislado sí renderizaba. El problema estaba antes: el front controller nunca llegaba a setTemplate('authentication.tpl') en una visita normal de login.

Había que comparar el controlador de producción con uno limpio.

Qué encontramos (causa real)

controllers/front/AuthController.php comprometido

En producción, AuthController.php estaba infectado con malware.

Al inicio de initContent() el código malicioso hacía, en esencia, esto:

1. Exigía un parámetro en la URL (?query=check) para continuar.
2. Si no venía → return; temprano.
3. Resultado: en /inicio-sesion normal, el controller salía sin asignar la plantilla.
4. Además incluía un webshell tipo “Encrypted File Editor” (funciones del estilo fe_h(), fe_path(), etc.).

No hace falta pegar el webshell entero. Con el patrón basta: puerta trasera + early return = login vacío.

El tamaño del archivo delataba el lío

controllers/front/AuthController.php
# infectado ~64078 bytes | limpio ~36382 bytes

Casi el doble de peso. La plantilla Smarty estaba razonable (con detalles menores aparte). El controller no la cargaba en las URLs normales de login.

Arreglos secundarios del mismo incidente

• themes/default-bootstrap/authentication.tpl — Smarty inválido dentro de comentarios HTML; campo oculto back con valor incorrecto.
• themes/default-bootstrap/modules/blockuserinfo/nav.tpl — typo javasricpt → javascript; un </a> suelto.

No eran la causa del #center_column vacío, pero convenía limpiarlos al tocar el login.

Alcance

Lección: pocas líneas al inicio de un controller. Toda la tienda sin login.

Cómo lo solucionamos (paso a paso)

1. Reproducir en la URL live y confirmar #center_column vacío (no “CSS escondido”).
2. Comparar AuthController.php de producción vs copia limpia (tamaño + return temprano).
3. Subir AuthController.php limpio desde backup/repo conocido.
4. Corregir plantillas del tema (authentication.tpl, nav.tpl).
5. Vaciar caché Smarty en producción.
6. Verificar en vivo EN y ES: presencia de login_form, #email, #passwd.
7. Eliminar scripts temporales de diagnóstico del servidor tras la verificación.
8. Documentar el incidente y el riesgo de seguir en 1.6 sin plan de actualización.

Sin reinstalar PrestaShop a ciegas.

Resultado

• Formulario de login restaurado en producción (EN + ES).
• Personal y clientes B2B pueden volver a entrar.
• Verificación: campos de autenticación presentes en el HTML.
• Arreglo quirúrgico: restaurar controller + limpiar tema + vaciar caché.
• Riesgo de fondo intacto: PrestaShop 1.6.1.24 sigue siendo un blanco fácil.

Por qué esto empuja a actualizar PrestaShop

Este caso no se “cierra para siempre” cambiando un PHP.

PrestaShop 1.6 ya no recibe parches como las ramas actuales, es objetivo habitual de backdoors en controllers del core y, tras un hack, auditar “todo lo limpio” es caro. Cada día en 1.6 es más riesgo: login, checkout, back office.

Actualizar PrestaShop (o migrar PrestaShop 1.6 a 8/9) no es un capricho de moda. Es salir de un núcleo sin mantenimiento.

Ruta sensata:

1. Backup completo (archivos + BD) verificado.
2. Inventario de módulos y overrides.
3. Staging con la versión destino (8.x o 9.x).
4. Migrar datos sin perder pedidos, clientes y catálogo (actualizar PrestaShop sin perder datos).
5. Probar login FO/BO, checkout y roles B2B.
6. Go-live controlado + vigilancia post-migración.

Si tu tienda aún está en PrestaShop 1.6, un login vacío como el de Comas Trial es exactamente el aviso que muchos ignoran hasta que duele.

Prevención (checklist realista)

• Cambiar contraseñas (BO, FTP/SFTP, hosting, BD) tras un incidente.
• Revisar usuarios empleados y accesos FTP “fantasma”.
• Comparar tamaño/hash de controllers críticos del core con una copia limpia de la misma versión.
• Monitorizar cambios en controllers/, classes/, override/.
• Backups externos (no solo en el mismo servidor).
• Quitar módulos abandonados y temas huérfanos.
• Plan de mantenimiento PrestaShop + calendario para actualizar PrestaShop fuera de 1.6.
• Tras un malware: no dar por cerrado el ticket solo porque “ya se ve el formulario”.

Preguntas frecuentes

¿Por qué mi login de PrestaShop aparece vacío?

A menudo no es CSS: el controlador de autenticación no asigna la plantilla (authentication.tpl). En este caso real, un malware en AuthController.php hacía return antes de setTemplate, dejando #center_column vacío.

¿Puede un hack impedir el formulario de inicio de sesión?

Sí. Un backdoor en un front controller puede abortar initContent() en URLs normales de login y dejar la página “casi bien” pero sin campos #email / #passwd.

¿Conviene seguir en PrestaShop 1.6?

No como plan a largo plazo. PrestaShop 1.6 está obsoleto. Lo sensato es planificar actualizar PrestaShop a 8.x o 9.x.

¿Cómo actualizar PrestaShop sin perder pedidos y clientes?

Con migración controlada: backup verificado, staging, inventario de módulos, migración de datos, pruebas de login y checkout, y cutover. No es un clic de “actualizar” en producción de 1.6 a 9.

¿Cómo saber si mi AuthController.php está infectado?

Compara tamaño y contenido con el archivo limpio de tu misma versión. Un salto grande de bytes, código ofuscado al inicio de initContent(), o un return temprano condicionado a parámetros raros de URL son señales claras.

Conclusión

En Comas Trial el “login no funciona” no era magia ni un fallo de CSS. Era malware en AuthController.php: un return temprano impedía cargar authentication.tpl. Pocas líneas. Tienda entera sin acceso.

La solución correcta no fue reinstalar a ciegas. Fue diagnosticar → aislar → restaurar → verificar → planificar actualización.

Si tu formulario login PrestaShop está vacío, la tienda no deja iniciar sesión, o sospechas malware PrestaShop en 1.6, puedo hacer el mismo trabajo: diagnóstico en producción, limpieza quirúrgica y plan para actualizar PrestaShop a una versión soportada.

Soporte técnico PrestaShop · Migración y actualización PrestaShop · Mantenimiento PrestaShop · Errores al actualizar PrestaShop · Contactar

actualizar PrestaShop, actualizar PrestaShop 1.6, migrar PrestaShop 1.6, PrestaShop login no funciona, formulario login PrestaShop vacío, PrestaShop hackeado, malware PrestaShop, AuthController.php, limpiar virus PrestaShop, mantenimiento PrestaShop, Comas Trial, caso de éxito