Skimmers en WooCommerce 2026: cómo detectarlos y eliminarlos

Los skimmers de WooCommerce se volvieron la pesadilla silenciosa del ecommerce argentino en 2026. No tiran abajo el sitio, no cambian la apariencia del checkout, y el candadito HTTPS sigue ahí — pero cada tarjeta que entra se va derechito a un servidor externo sin que nadie se entere. Los análisis forenses de mayo de 2026 muestran que el ataque ya no es artesanal: son campañas automatizadas que explotan plugins vulnerables para inyectar código malicioso en archivos JavaScript legítimos del tema o del propio WooCommerce, dejando el código original intacto atrás del malware para que todo siga funcionando como si nada.

Un skimmer de WooCommerce es un fragmento de JavaScript malicioso que se inyecta en archivos legítimos de una tienda online para capturar los datos de tarjetas de crédito que los clientes ingresan en el formulario de checkout, y enviarlos en tiempo real a un servidor controlado por atacantes mediante WebSocket, sin que la tienda ni el comprador noten nada extraño. El vector de entrada casi siempre es un plugin con alguna vulnerabilidad conocida que permite escritura remota en disco.

¿Cómo se inyecta un skimmer en una tienda WooCommerce?

El punto de entrada favorito en lo que va de 2026 son los plugins de pago, caché y constructores visuales con vulnerabilidades de inclusión de archivos o subida sin sanitizar. El atacante escanea tiendas WooCommerce con herramientas automatizadas que detectan versiones vulnerables — según los reportes de CloudSEK de principios de año, el tiempo promedio entre la publicación de un CVE explotable y la primera campaña de skimming masivo bajó a menos de 48 horas.

Una vez adentro, no agrega archivos nuevos. Eso sería demasiado obvio. En su lugar, busca un archivo JavaScript que se cargue en todas las páginas — típicamente un main.js del tema, un custom.js del child theme, o el propio checkout.min.js de WooCommerce — y le inserta el payload al principio, respetando el código original que queda atrás. El archivo sigue pesando casi lo mismo y el sitio sigue funcionando, así que un diff de hashes o una comparación línea por línea contra el repo oficial es lo único que te va a cantar la posta.

Lo más turbio (y te hablo desde la experiencia de haber auditado tres tiendas comprometidas este año) es que el código malicioso está diseñado para sobrevivir actualizaciones automáticas. Conozco casos donde el skimmer reaparecía 24 horas después de la limpieza porque las credenciales FTP estaban comprometidas y el atacante tenía un cronjob oculto en wp_options que reinyectaba el payload. Ojo con limpiar superficialmente — si no rotás credenciales y revisás la base de datos, es como barrer la vereda durante un temporal.

¿Qué datos captura un skimmer y cómo los exfiltra?

Acá viene la parte que más bronca da: lo minucioso que es el malware. No se conforma con el número de tarjeta. Los skimmers actuales capturan todo lo que un formulario de checkout estándar de WooCommerce muestra por defecto: número de tarjeta, fecha de vencimiento, CVV, nombre del titular, email, teléfono, dirección de facturación completa. Usan selectores CSS que apuntan a los IDs que WooCommerce genera de forma predecible — #billing_first_name, #billing_phone, #billing_email y similares — así que no necesitan reverse-engineering de cada tienda porque WooCommerce no randomiza esos IDs.

El flujo es así: el código malicioso hace polling cada 500ms sobre los campos del formulario (sí, 500 milisegundos, lo detectás con un profiler de JavaScript si sabés qué buscar). Cuando un campo tiene valor que no estaba antes, lo captura. Si el campo es el número de tarjeta, le pasa el algoritmo de Luhn — una validación matemática estándar para números de tarjetas — y solo sigue adelante si el número es sintácticamente válido. Esto evita mandar basura que dispare alarmas del lado del C2. Esto se conecta con lo que analizamos en sincronización entre WooCommerce y eBay.

La exfiltración merece un párrafo aparte porque es re piola en el mal sentido. Los datos se empaquetan, se cifran con RC4 (un cifrado de flujo que, aunque está roto hace años, sigue siendo suficiente para ofuscar el payload en tránsito) y después se codifican en Base64 y se invierte el string resultante. Ese mamarracho va por WebSocket a un dominio C2 que suele correr en puertos no estándar — 2083, 8443, 9090 — para evadir reglas de firewall que solo inspeccionan tráfico HTTP en 80 y 443. El malware mantiene un registro en localStorage de lo que ya envió usando keys con nombres que parecen de analytics (tipo fbpixel_ o _ga_) y no reenvía datos duplicados. Después de cada envío exitoso, borra los rastros del DOM — los event listeners que puso, los campos temporales que creó — para que una inspección rápida desde la consola del navegador no muestre nada raro.

¿Por qué los skimmers pasan desapercibidos en auditorías?

La pregunta del millón. El sitio funciona bárbaro. Los pedidos entran, los pagos se procesan, el dashboard de WooCommerce no muestra errores. El candadito HTTPS está verde. No hay archivos nuevos en el directorio del tema. El archivo JS comprometido es uno que estuvo ahí desde siempre — solo que ahora tiene 300 líneas extra al principio que nadie miró porque nadie hace diff manual de todos los JS de un sitio en producción todos los meses, seamos honestos.

Después tenés las herramientas automáticas. Wordfence, Sucuri y los escáneres de hosting monitorean hashes de archivos del core de WordPress— pero muchos no cubren archivos de temas ni de plugins premium, y mucho menos del child theme que escribió el desarrollador freelance hace tres años. El tráfico malicioso es mínimo: un WebSocket cada vez que alguien completa el checkout (y con la deduplicación en localStorage, solo la primera vez por cliente). No es un pico de tráfico que active alertas de ancho de banda. Es literalmente un goteo.

Y si eso fuera poco, los atacantes se esmeran en el camuflaje semántico. Las keys de localStorage que usa el skimmer para tracking y deduplicación tienen nombres como fbpixel_session_1743 o _ga_disable_UA-, que cualquier administrador va a asociar con Facebook Pixel o Google Analytics y no va a cuestionar (¿quién va a borrar la key del Pixel metiéndose en el localStorage de su propio sitio sin miedo a romper algo?). Es un nivel de sutileza que hace que las auditorías superficiales sean prácticamente inútiles.

Indicadores técnicos de compromiso (IOCs) clave para detectar skimmers

Basado en el análisis de campañas activas durante mayo de 2026, estos son los IOCs que deberías buscar si administrás una tienda WooCommerce. Armé esta tabla con lo que encontraron los equipos de CloudSEK y los reportes de seguridad de la comunidad de WordPress, más lo que yo mismo vi en auditorías este año:

Una aclaración sobre el hash: esto no lo hace Wordfence automáticamente para temas de pago ni child themes. Tenés que bajarte la versión oficial del ThemeForest o del repo correspondiente y correr un sha256sum a mano, o usar scripts como los que publicó Patchstack a principios de 2026 para automatizar la verificación de integridad en plugins premium populares.

Herramientas y métodos para detectar un skimmer en tu tienda

Hay varias formas de encararlo, y te digo desde ya: ninguna por sí sola alcanza. Combiná al menos tres de estos métodos. Es la única forma de dormir tranquilo. Cubrimos ese tema en detalle en las diferencias con Ally.

Content Security Policy en modo report-only

Activás CSP con el header Content-Security-Policy-Report-Only y configurás una whitelist estricta de dominios a los que tu checkout puede conectarse: tu pasarela de pago, Google Analytics si lo usás, Facebook si tenés Pixel, y punto. Cualquier intento de conexión WebSocket a un dominio que no está en la whitelist va a generar un reporte sin bloquear al cliente. En un par de días tenés un mapa de todas las conexiones salientes que tu checkout está haciendo — y si aparece un dominio en Bulgaria con puerto 8443, ya sabés por dónde viene la mano.

Monitoreo de integridad de archivos (FIM) con AIDE o similar

Advanced Intrusion Detection Environment (AIDE) es una herramienta de la vieja escuela de Linux que compara hashes de archivos contra una base de datos de referencia. La instalás en el servidor, generás la base de referencia cuando el sitio está limpio, y programás un chequeo diario. Si un plugin vulnerable permite que alguien toque un archivo JS, el hash cambia y AIDE te salta la alarma por mail. Wordfence tiene algo parecido pero limitado a core de WordPress — no cubre temas premium ni child themes, que es justo donde los skimmers se meten.

Análisis manual de JavaScript

Agarrás los archivos JS de tu tema activo, especialmente los que se cargan en el checkout, y buscás strings que parezcan Base64. Los skimmers actuales usan Base64 invertida — así que un grep comunacho de atob no te va a alcanzar. Lo que hacés es buscar cualquier variable que contenga un string largo y llamativo, lo pasás por un script que invierta el string, lo decodifique de Base64, y fijate si el resultado tiene pinta de dominio o IP. Es un laburo manual pero para eso estamos, ¿no?

Subresource Integrity (SRI) en scripts externos

Si tu tema o plugins cargan scripts de CDNs externas — jQuery desde Google CDN, Font Awesome, lo que sea — agregales el atributo integrity con el hash del recurso legítimo. Si un atacante modifica el script en tu servidor, el navegador directamente no lo ejecuta porque el hash no coincide. No evita que el archivo local se modifique, pero inhabilita que el código malicioso se ejecute en el navegador del cliente, que es donde ocurre la captura.

Pasos concretos para eliminar un skimmer de WooCommerce

Si ya confirmaste que tenés un skimmer — por hash alterado, por dominio C2 apareciendo en los logs, o porque un cliente te avisó que le clonaron la tarjeta justo después de comprar en tu tienda — el protocolo es quirúrgico. No alcanza con tocar el archivo infectado, porque si el atacante tiene persistencia, en horas vuelve.

• Identificá el archivo JS comprometido. Buscá timestamps de modificación recientes en /wp-content/themes/ y /wp-content/plugins/. El archivo va a tener una fecha de modificación más nueva que el resto del tema. Si tenés backup limpio, compará hashes. Si no, revisá el contenido buscando cadenas ofuscadas al principio del archivo.
• Reemplazá por copia limpia. No edites el archivo infectado para «sacarle lo malo». Descargá la versión oficial del tema o plugin desde el repo, o restaurá desde un backup limpio (que estés seguro de que es anterior a la infección).
• Rotá todas las credenciales. Empezá por las de administrador de WordPress, FTP/SFTP, base de datos, y acceso al panel de hosting. Si usás el mismo password en otros servicios, cambialos también. Asumí que todo está comprometido, porque probablemente lo está.
• Eliminá plugins vulnerables. Revisá la lista de plugins instalados. Si hay algo desactualizado, sin soporte, o bajado de fuentes dudosas, volá. Instalá solo lo necesario desde repos oficiales. Un buen hosting ya incluye herramientas de escaneo de malware — por ejemplo, los planes de donweb.com para WooCommerce vienen con protección anti-malware integrada que monitorea cambios sospechosos en tiempo real.
• Revisá la base de datos. Buscá en wp_options entradas con nombres que no reconozcas, especialmente en option_name valores que parezcan código o contengan eval() o base64_decode(). Los backdoors suelen esconderse como opciones de WordPress «legítimas» con nombres random o que imitan plugins desinstalados hace años.
• Implementá prevención inmediata. CSP estricta, FIM con AIDE, SRI en scripts de terceros, y bloqueo de escritura en directorios de plugins desde el panel de hosting. Que no vuelva a pasar.

El orden importa. Si rotás credenciales antes de eliminar el backdoor de la base de datos, le estás dando la contraseña nueva al atacante sin querer. Primero limpieza, después credenciales, después hardening.

Medidas de protección técnica contra skimmers (guía práctica)

Prevenir es más barato que curar. Y en este caso, curar implica potencialmente lidiar con chargebacks, clientes furiosos, y en el peor escenario una demanda por filtración de datos — la Ley de Protección de Datos Personales en Argentina no se anda con chiquitas si demostrás negligencia. Ya lo cubrimos antes en opiniones sobre Wordfence.

Content Security Policy con whitelist estricta

Es tu primera línea de defensa. Configurás el header CSP para que el navegador solo permita conexiones a dominios que vos autorizás explícitamente. Si el skimmer intenta abrir un WebSocket a un dominio que no está en la lista blanca, el navegador lo bloquea de raíz. El skimmer ni siquiera llega a cifrar los datos — se estrella contra el CSP. Recomendación: arrancá en modo report-only por una semana, recolectá los reportes, ajustá la whitelist, y después pasás a modo enforce. Si lo ponés en enforce de una sin testear, podés romper funcionalidades legítimas (como el tracking de conversiones de tu pasarela de pago).

Restricciones de escritura en directorios

Desde el panel de hosting o directamente desde SSH, bloqueá la capacidad de escritura de PHP en los directorios de plugins y temas. Si un plugin vulnerable intenta modificar un archivo JS, no va a poder porque el filesystem no lo permite. La contra: cuando quieras actualizar plugins, vas a tener que desbloquear temporalmente. Es una pavada si tenés acceso SSH — un chattr +i sobre los directorios que no deberían cambiar nunca.

Auditoría periódica de plugins con Patchstack

Patchstack mantiene una base de datos de vulnerabilidades específicas de WordPress y WooCommerce, y monitorea en tiempo real si alguno de tus plugins tiene un CVE activo. Por USD 5 por sitio por mes, te avisa antes de que los atacantes barran tu versión. No es infalible, pero combinado con CSP y FIM, armás una defensa en capas que hace que el atacante tenga que esforzarse mucho más — y los skimmers de WooCommerce en 2026 apuntan al blanco más fácil, no al que tiene tres defensas activas.

Errores comunes al detectar o eliminar skimmers

En las auditorías que hice este año, me encontré con los mismos errores una y otra vez. Gente que hizo lo que pudo pero se quedó corta por confiar en herramientas que no cubrían todo el espectro del problema. No son errores de novato — son errores de quien no vivió un ataque así antes, y es normal. Pero mejor aprender en cabeza ajena.

Confiar ciegamente en el escáner de Wordfence. Wordfence es buenísimo para el core de WordPress y para detectar malware con firmas conocidas. El tema es que los skimmers de 2026 usan ofuscación custom que no está en las firmas, y se meten en archivos que Wordfence no monitorea — temas premium, child themes, plugins comprados en CodeCanyon. Si el escáner dice «todo limpio», no significa que esté todo limpio. Significa que no encontró lo que sabe buscar.

Eliminar el código malicioso del archivo y darlo por resuelto. Si encontraste el JS comprometido y le borraste el bloque ofuscado del principio, felicitaciones: eliminaste el síntoma visible. Pero si no averiguaste cómo llegó ahí — qué plugin vulnerable usaron, si las credenciales FTP están comprometidas, si hay un cronjob oculto en la base de datos — el skimmer vuelve en menos de 48 horas. Lo vi pasar tres veces con la misma tienda antes de que me llamaran.

No revisar la base de datos. El backdoor clásico de 2025-2026 es una entrada en wp_options que contiene código PHP serializado o un eval() disfrazado, que se ejecuta cuando WordPress carga ciertas páginas. Limpiás archivos, rotás credenciales, pero dejás esa opción en la base de datos y el atacante tiene una puerta abierta. Hacé un dump de la base de datos y buscá eval(, base64_decode(, gzinflate( y str_rot13( dentro de los valores de las opciones. Lo explicamos a fondo en comparativa con Patchstack.

Asumir que el HTTPS te protege. El candadito verde significa que la conexión entre el navegador del cliente y tu servidor está cifrada. Bárbaro. Pero el skimmer corre en el navegador del cliente — captura los datos antes de que se cifren, o después de que tu servidor los descifra para procesar el pago. HTTPS no hace absolutamente nada contra un skimmer en el frontend. Es como ponerle alarma al auto pero dejar la ventanilla abierta.

Preguntas Frecuentes

¿Cómo detectar un skimmer en mi tienda WooCommerce?

Compará los hashes SHA256 de los archivos JavaScript de tu tema y plugins contra las versiones oficiales de los repos. Activá CSP en modo report-only para identificar conexiones WebSocket a dominios desconocidos desde el checkout. Revisá manualmente las keys de localStorage con nombres que imitan herramientas de analytics — si ves fbpixel_ con un ID que no coincide con tu Pixel real, tenés un problema.

¿Qué es un skimmer de tarjetas en WooCommerce?

Es código JavaScript malicioso que se inyecta en archivos legítimos del frontend de una tienda WooCommerce para capturar los datos de tarjetas de crédito que los compradores ingresan durante el checkout. Los envía cifrados a un servidor externo controlado por atacantes, mientras la tienda sigue operando normalmente y las transacciones legítimas se procesan sin interrupción.

¿Qué plugins de WooCommerce son vulnerables a skimmers?

Cualquier plugin con una vulnerabilidad que permita escritura remota de archivos puede ser la puerta de entrada. En 2026 las campañas más activas explotaron plugins de caché, constructores de páginas visuales, y gateways de pago no oficiales con CVEs publicados y parches disponibles pero no aplicados. El factor común no es el tipo de plugin sino la falta de actualización y el uso de software sin soporte activo.

¿Cómo eliminar un skimmer de WooCommerce paso a paso?

Identificá el archivo modificado comparando timestamps y hashes contra versiones limpias. Reemplazalo con una copia oficial, no edites el archivo infectado. Rotá todas las credenciales: WordPress, FTP, base de datos y hosting. Eliminá plugins desactualizados o de fuentes no oficiales. Revisá wp_options en busca de backdoors ocultos. Implementá CSP estricta, FIM y restricciones de escritura para prevenir reinfecciones.

¿Cómo prevenir skimmers en WooCommerce en 2026?

Actualizá todos los plugins apenas salen los parches de seguridad — los atacantes automatizan el escaneo de versiones vulnerables en menos de 48 horas. Configurá una CSP estricta que limite conexiones salientes a dominios conocidos. Usá monitoreo de integridad de archivos con AIDE. Bloqueá permisos de escritura en directorios de plugins desde el panel de hosting cuando no estés haciendo mantenimiento. Auditá tus plugins con herramientas como Patchstack.

Conclusión

Los skimmers de WooCommerce en 2026 dejaron de ser ese ataque raro que le pasaba a otro para convertirse en una amenaza automatizada y persistente que explota el eslabón más débil de toda tienda online: los plugins que instalamos y nos olvidamos. La diferencia entre una tienda comprometida y una limpia no es el presupuesto ni la suerte — es tener visibilidad sobre lo que pasa en el frontend y no asumir que porque todo funciona, todo está bien. El checkout de WooCommerce procesa plata real de clientes reales, y la responsabilidad de proteger esos datos es tuya. CSP, FIM, SRI y una política de actualización agresiva no son lujos técnicos: son el mínimo indispensable para operar un ecommerce en serio este año.

Fuentes

• Seguridad en WordPress – Anatomía de un ataque de skimming en WooCommerce: análisis forense detallado del vector de infección, técnicas de ofuscación y persistencia.
• CloudSEK – WooCommerce Payment Skimmer: Card Data Theft via Checkout Backdoor: reporte de inteligencia de amenazas con IOCs, dominios C2 y metodología de exfiltración.
• Patchstack – Vulnerability Database: base de datos de vulnerabilidades específicas de WordPress y WooCommerce, con monitoreo en tiempo real.
• MDN – Content Security Policy: documentación oficial de Mozilla sobre implementación de CSP, incluyendo modo report-only.