El 13 de febrero de 2026, PrestaShop publicó una alerta de seguridad recomendando verificar tiendas ante la detección de un script malicioso (“digital skimmer”) que podría derivar en robo de información de pago de algunos clientes.
En HostingTG nos tomamos estas alertas muy en serio porque, cuando un skimmer entra en una tienda online, el daño no es solo “técnico”: hay impacto reputacional, potencial incidencia RGPD, y en el peor caso, una cadena de fraude que se alarga semanas.
En este artículo te explico qué hace el skimmer, cómo comprobar si estás afectado y, sobre todo, qué hacer paso a paso para dejar tu tienda limpia y más difícil de comprometer.
Qué es un “digital skimmer” y por qué es tan peligroso
Un digital skimmer es un tipo de malware diseñado para capturar datos sensibles (especialmente durante el pago). En este caso concreto, PrestaShop describe que el atacante sustituye los botones de pago legítimos en la página de pedido por otros fraudulentos. Al hacer clic, el cliente termina en un formulario de pago falso cuyo objetivo es robar la información.
La clave aquí es que no siempre verás errores: el usuario cree que está pagando “normal”, y el atacante intenta pasar desapercibido el mayor tiempo posible.
Cómo funciona este caso concreto: inyección de <script> en el tema
Lo más relevante de la alerta es dónde se carga el skimmer: PrestaShop indica que el script se inserta mediante una etiqueta <script> escrita directamente en el archivo del tema activo _partials/head.tpl. Eso implica algo importante: alguien ha podido modificar archivos de tu tienda.
Traducción práctica:
- No es “solo” un problema de navegador o caché.
- Hay que tratarlo como compromiso de sistema (o al menos de credenciales con permisos de escritura).
Señales típicas de un skimmer (lo que debes buscar)
Aunque cada infección puede variar, este tipo de skimmers suelen dejar señales como:
- Un
<script>“raro” en elheaddel sitio (o cargado desde ahí). - Código “ofuscado” (cadenas largas sin sentido, o funciones para decodificar).
- Llamadas a recursos externos que no pertenecen a tu dominio.
- Redirecciones en el checkout a páginas/formularios no esperados.
En la alerta, PrestaShop menciona como patrón que la estructura usa XMLHttpRequest y la función atob() (decodificación base64), y que la URL decodificada puede variar entre tiendas.
Cómo verificar si tu tienda está afectada (dos métodos)
1) Verificación rápida desde el front-office (sin tocar el servidor)
PrestaShop recomienda inspeccionar una página desde el navegador (clic derecho → Inspeccionar) y revisar dentro de etiquetas <script> si aparece un código con la estructura sospechosa (mismo patrón, aunque el “payload” cambie).
Dónde mirar primero (prioridad):
- Página de carrito/checkout.
- Pantalla de selección de método de pago.
- Confirmación de pedido (si tu flujo lo usa).
Tip práctico de HostingTG: haz la comprobación en modo incógnito, y si puedes, desde dos dispositivos/redes (por si hay cachés intermedias o scripts servidos condicionalmente).
2) Verificación en el servidor: localizar el archivo comprometido
Si tienes acceso por FTP/SFTP, PrestaShop indica una ruta típica dentro del tema activo:
/themes/<TU_TEMA>/templates/_partials/head.tpl
Abre el archivo y busca:
<script>que no reconozcas.- Código que “descarga” JS de otra parte.
- Uso de
atob()y ejecución dinámica (por ejemplo, construir funciones a partir de texto).
Ojo: que el skimmer esté ahí no significa que solo esté ahí. Tómalo como un síntoma de acceso no autorizado.
Qué hacer si tu tienda está afectada (protocolo completo, sin atajos)
La alerta oficial sugiere cambiar contraseñas de accesos (back-office, base de datos, FTP, SSH, etc.) y contactar con soporte/agencia si hay dudas.
Nosotros lo ampliamos con un protocolo más “de incident response”, porque borrar el script sin más es como secar el suelo sin cerrar la tubería.
Paso 1 — Contención inmediata (para frenar el daño)
- Pausa el checkout (modo mantenimiento o deshabilitar temporalmente pagos).
- Si no puedes parar la tienda, al menos:
- desactiva temporalmente métodos de pago más sensibles,
- coloca aviso de “mantenimiento” en checkout,
- y limita compras hasta completar revisión.
Objetivo: evitar que entren más clientes a un flujo de pago potencialmente manipulado.
Paso 2 — Evidencias rápidas (antes de tocar demasiado)
Antes de modificar archivos “a lo loco”:
- Guarda una copia del
head.tplactual. - Anota fecha/hora del hallazgo.
- Exporta logs si tienes (accesos, errores, cambios).
Esto te sirve para:
- entender el vector de entrada,
- y si toca notificar, tener trazabilidad.
Paso 3 — Limpieza segura (eliminar el skimmer)
Aquí hay dos enfoques recomendables:
Opción A: Restauración desde copia limpia (la más fiable)
- Restaura el tema (o el archivo afectado) desde un backup anterior al compromiso.
- Compara diferencias con la versión infectada.
Opción B: Limpieza manual (si no tienes copia limpia)
- Elimina el
<script>malicioso y cualquier bloque asociado. - Revisa que no haya más scripts inyectados en:
header.tpl,footer.tpl, plantillas del checkout,- overrides o assets del tema.
Importante: la alerta deja claro que el atacante pudo modificar un archivo. Eso suele implicar que el problema no termina en ese <script>.
Paso 4 — Cambio de credenciales (obligatorio, no “por si acaso”)
PrestaShop recomienda cambiar contraseñas de accesos: back-office, base de datos, FTP, SSH y actualizar el acceso a la base de datos en la configuración.
Checklist mínimo:
- Administradores del back-office (todos).
- FTP/SFTP y panel de hosting.
- SSH (si aplica).
- Base de datos (usuario y password) + actualización en config.
- Cuentas de correo asociadas (si se usan para recuperaciones).
Consejo HostingTG: si puedes, rota también claves/API de pasarelas de pago o integraciones (según proveedor). Aunque el skimmer robe datos en un formulario falso, es buena práctica si hubo acceso.
Paso 5 — Localizar el punto de entrada (si no, volverá)
Los skimmers suelen entrar por:
- módulos/temas desactualizados,
- credenciales débiles o filtradas,
- permisos de archivos demasiado laxos,
- panel/FTP expuesto o sin MFA,
- vulnerabilidades en terceros (extensiones mal mantenidas).
Qué revisar sí o sí:
- Archivos modificados recientemente (más allá del
head.tpl). - Administradores nuevos o cambios en roles/permisos.
- Módulos instalados que no uses (mejor fuera).
- Rutas sensibles expuestas (back-office con nombre por defecto, etc.).
Paso 6 — Refuerzo y endurecimiento (para que no sea una puerta giratoria)
Medidas que suelen marcar diferencia en tiendas reales:
Seguridad de acceso
- MFA/2FA en panel de hosting y back-office (si lo tienes disponible).
- Limitar acceso al back-office por IP o VPN (cuando sea viable).
- Contraseñas únicas y largas (y gestor de contraseñas).
Seguridad de archivos y despliegue
- Ajustar permisos: solo escritura donde sea imprescindible.
- Evitar editar “en producción” desde módulos/editores.
- Desplegar por SFTP/CI y mantener control de cambios.
Protección de capa web
- WAF (firewall de aplicación) o reglas específicas para checkout.
- Rate limiting y protección contra bots en endpoints sensibles.
- Monitorización de integridad: alertas cuando cambie un archivo clave (como
head.tpl).
Actualizaciones
- Mantener PrestaShop + módulos + tema al día.
- Eliminar módulos “abandonados” o sin mantenimiento claro.
Preguntas frecuentes
¿Si no veo el script en head.tpl, estoy a salvo?
No necesariamente. La alerta describe ese punto de carga, pero un atacante puede inyectar scripts en otros archivos, módulos, overrides o incluso servirlos condicionalmente. Si sospechas, amplía revisión y busca cambios recientes.
¿Esto afecta a “todas” las tiendas PrestaShop?
La alerta habla de “algunas tiendas” del ecosistema, no de todas. Aun así, recomienda verificación completa.
¿Basta con borrar el <script> y listo?
Es un primer paso, pero no el final. Si pudieron escribir en tus archivos, necesitas rotar credenciales y revisar punto de entrada; si no, la reinfección es muy probable.
¿Cómo sé si han robado datos realmente?
Sin logs y trazas es difícil afirmarlo al 100%. Por eso son clave: evidencias, ventanas de tiempo, análisis de cambios, y (si aplica) soporte especializado.
Sobre Digital Skimmer
Esta alerta de PrestaShop no es para “asustar”: es un aviso para actuar rápido y con método. Verifica tu front-office, revisa el head.tpl del tema, y si encuentras indicios, no te quedes en borrar el script: contén, guarda evidencias, limpia bien, rota accesos y refuerza la tienda.
