ClickFix en WordPress: el falso CAPTCHA que infecta visitantes

Resumen rápido: ClickFix es un malware que se instala en sitios WordPress hackeados y muestra a los visitantes un CAPTCHA falso («Verify you are human», «I’m not a robot», a veces con el logo de Cloudflare). El «CAPTCHA» les pide pulsar Win + R, pegar y ejecutar un comando que el propio sitio ya copió al portapapeles. Ese comando instala un infostealer que roba contraseñas, cookies y sesiones. El dueño del sitio no lo ve, porque el malware se oculta a propósito de los administradores. Limpiarlo implica mucho más que borrar un archivo: hay que encontrar todos los focos, cerrar la puerta por la que entraron y rotar todas las credenciales, o vuelve en días.

Este artículo cuenta cómo funciona, cómo saber si tu sitio lo tiene, qué hacer paso a paso y qué errores evitar. Está escrito a partir de un caso real que atendí en 2026: 13 dominios infectados en una misma cuenta de hosting, 46 días sin que nadie lo notara y tres oleadas de reinfección en 60 días.

¿Tu sitio está mostrando un CAPTCHA raro ahora mismo? No sigas leyendo: escribime por WhatsApp y lo miramos hoy. Después volvés y leés el resto con calma.

Qué es ClickFix

ClickFix es una técnica de ingeniería social que convence a la víctima de ejecutar ella misma un comando malicioso en su computadora, disfrazando ese paso de «verificación de seguridad», «corrección de un error» o «CAPTCHA». El nombre viene de eso: click para «arreglar» (fix) algo que en realidad nunca estuvo roto.

En su variante más extendida, el vehículo son sitios WordPress legítimos hackeados. El atacante no crea páginas falsas: infecta sitios reales, con reputación, indexados en Google, y usa ese tráfico de confianza para atacar a los visitantes. Un diario local, un alojamiento turístico, una asociación deportiva, un comercio. Sitios que nadie sospecharía.

Lo que ve el visitante es una ventana superpuesta a la página, con un diseño prolijo que imita a Cloudflare o a Google reCAPTCHA:

«Verify you are human» con una casilla para tildar.
Al tildarla, aparecen «pasos de verificación»: pulsá Win + R, después Ctrl + V, después Enter.
Mientras tanto, el sitio ya copió al portapapeles un comando de PowerShell o mshta ofuscado.

Si la persona sigue los pasos, ejecuta el comando en su propia máquina. Ningún antivirus lo bloqueó porque no hubo descarga: la víctima lo ejecutó voluntariamente.

Cómo actúa: la cadena completa del ataque

Entender la cadena sirve para dos cosas: saber qué buscar en el servidor y explicarle a un cliente por qué «borré el archivo y ya está» no alcanza.

1. Intrusión en el sitio

El atacante consigue escribir archivos en el WordPress. Los vectores que vi en el caso real, en orden de aparición:

Acceso a nivel de cuenta de hosting (SSH, FTP o panel): los mismos tres archivos aparecieron en 13 dominios de la misma cuenta en una ventana de dos minutos. Una vulnerabilidad de plugin habría afectado a un solo sitio.
Credenciales de administrador de WordPress robadas: en la segunda y tercera oleada, el atacante entró con la cuenta de administrador legítima, desde IPs de datacenter en Malasia, Nueva York, Toronto y Berlín, con un user-agent de Safari en Mac que el dueño jamás usó. Quedó registrado en la tabla de sesiones de WordPress.
Editor de archivos del panel (Apariencia → Editor de archivos): con la sesión de administrador, escribieron el functions.php del tema 34 segundos después del login. Sin plugins, sin exploits: con la herramienta que WordPress trae de fábrica.

2. Persistencia: dónde se esconde

Acá es donde la mayoría de las limpiezas fallan. Un mismo operador usó, en cuestión de semanas, seis escondites distintos:

Escondite	Cómo se veía	Por qué es difícil de ver
MU-plugin (`wp-content/mu-plugins/`)	Un archivo `.php` con nombre neutro	Los must-use plugins se ejecutan siempre, no se pueden desactivar desde el panel y no aparecen en la lista normal de plugins
Plugin normal con nombre plausible	`site-helper-<hash>`, descripto como «Performance Lab Helper»	Un plugin más en una lista de veinte no llama la atención
`functions.php` del tema	Una línea al final del archivo, con `add_action('wp_footer', …)`	Ningún verificador de integridad cubre los temas; el archivo es legítimo, la línea no
Archivos legítimos de plugins	El código antepuesto al principio de un archivo de Akismet, de Elementor Pro o de JetEngine	El plugin sigue funcionando; el archivo tiene la fecha de la actualización real
Entradas de la base de datos	El `<script>` inyectado dentro del contenido de 94 posts y revisiones	Un escaneo de la portada no lo ve; solo aparece al abrir un post
Service worker en el navegador del visitante	`nochain-sw.js` en la raíz del sitio	Sobrevive a la limpieza del servidor: queda instalado en el navegador de cada víctima

Y un detalle que convierte la limpieza en una trampa: el plugin malicioso se restaura solo. Deja un ZIP con su copia disfrazado de imagen en wp-content/uploads/2026/08/cache-63fcf1b7.jpg, y en cada carga de WordPress comprueba si lo borraron para volver a instalarse. Si borrás el plugin y no la «imagen», al rato está de vuelta.

3. Evasión: por qué el dueño no lo ve

Esto es lo que más desconcierta a quien administra el sitio: «yo entro todos los días y está perfecto». El inyector excluye deliberadamente a los administradores. En el código se comprobaba:

si existe la cookie wordpress_logged_in_* (usuario logueado),
si la URL es /wp-admin o /wp-login.php,
si existe una cookie propia (nc_skip=1) que el propio malware instala a todo usuario con permisos de administrador,
y si el visitante ya vio el CAPTCHA ese día (para no llamar la atención con repeticiones).

En una versión posterior fue más lejos: a la IP del administrador que había entrado a wp-admin le servía una versión inocua del script, y al resto del mundo la maliciosa.

Resultado: el dueño navega logueado y ve el sitio normal; un visitante nuevo que llega desde Google recibe el ataque. Por eso, cuando alguien te avisa «tu sitio me muestra un CAPTCHA raro» y vos no lo ves, el que tiene razón es el visitante.

4. EtherHiding: instrucciones en la blockchain

Las versiones actuales de ClickFix no traen el payload final en el servidor. El script inyectado carga una librería (ethers.js) y lee de un contrato inteligente en una blockchain pública (Base, Polygon, BNB Smart Chain) la dirección del servidor de control y el contenido a mostrar. La técnica se llama EtherHiding.

Consecuencias prácticas:

El atacante cambia el payload sin volver a tocar tu servidor: hoy muestra un CAPTCHA falso, mañana un «error de Chrome» que hay que «corregir», pasado un drainer de billeteras cripto.
No hay un dominio malicioso que bloquear: los datos viven en una blockchain que nadie puede dar de baja, y el script tiene ocho endpoints RPC públicos de respaldo.
Un antivirus que bloquee el dominio de control de hoy no sirve mañana.

En el caso real, un mismo operador usó un contrato en Base en junio y otro en Polygon en agosto, y llevaba inventario de víctimas: cada sitio infectado tenía un identificador propio en la llamada al servidor de control.

5. Lo que le pasa al visitante

El comando que ejecuta la víctima descarga e instala un infostealer (Lumma, Amatera y familias similares). En segundos le roba:

contraseñas guardadas en el navegador,
cookies y sesiones activas (con eso el atacante entra a cuentas sin necesitar la contraseña ni el 2FA),
datos de autocompletar y tarjetas,
billeteras de criptomonedas.

Y acá se cierra el círculo: si el dueño del sitio o alguien de su equipo cayó en el CAPTCHA, el atacante tiene las credenciales del WordPress. En el caso que atendí, la hipótesis más sólida de la segunda oleada era exactamente esa: las credenciales de administrador cosechadas en la primera.

Cómo saber si tu sitio WordPress está infectado con ClickFix

Chequeos que podés hacer sin conocimientos técnicos, en cinco minutos:

Entrá a tu sitio en una ventana de incógnito, sin estar logueado, idealmente desde el celular con datos móviles (otra IP). Buscalo en Google y entrá desde el resultado: el malware suele activarse solo cuando el Referer es un buscador.
Revisá un post cualquiera, no solo la portada. Hubo sitios con la portada limpia y 14 posts infectados.
Mirá Google Search Console: la sección Seguridad y acciones manuales avisa cuando Google detecta «software malicioso» o «páginas engañosas».
Revisá el correo del hosting. Los proveedores escanean y mandan un aviso de abuse con 24 horas para limpiar antes de suspender la cuenta completa. Ese correo llega a la casilla de registro, que muchas veces nadie lee.
Tomá en serio cualquier aviso de un visitante. En dos de las tres oleadas, quien detectó el problema fue un cliente o un lector, no una herramienta.

Chequeos técnicos, para quien tiene acceso al servidor:

Listar wp-content/mu-plugins/ y abrir cada archivo que no reconozcas.
Listar los plugins por fecha de instalación y buscar nombres genéricos (site-helper, wp-helper, performance-*, cache-*) con un sufijo hexadecimal.
Leer la última línea del functions.php del tema activo.
Buscar en toda la instalación los patrones atob(, new Function(new TextDecoder, eth_call, eval(base64_decode y 0x seguido de 40 caracteres hexadecimales (una dirección de contrato).
Buscar archivos .jpg, .png, .css o .js que empiecen con <?php o con PK (un ZIP disfrazado).
Buscar el mismo patrón <script> dentro de wp_posts y wp_options, no solo en archivos.
Revisar las sesiones activas de cada administrador (session_tokens en wp_usermeta): guarda la IP, el navegador y la hora de cada login. Es la mejor evidencia de intrusión que tiene WordPress.

Caso real: 13 dominios, 46 días, tres oleadas

Cuento el caso porque las decisiones que hubo que tomar son las mismas que va a tener que tomar cualquiera que pase por esto.

Oleada 1 (junio–julio). Los tres archivos del malware aparecieron en 13 de los 14 dominios de una cuenta de hosting compartido, todos en la misma ventana de dos minutos. Estuvo activo 46 días antes de que un CAPTCHA en ventana de incógnito lo delatara. Una auditoría previa ya había listado el MU-plugin sospechoso y lo había clasificado como «informativo». Lección: un archivo ejecutable no identificado en producción nunca es «informativo».

Ese mismo día, horas después de la limpieza, llegó el aviso de abuse del hosting: 24 horas para remover el malware o suspendían el plan entero, los 14 dominios.

Oleada 2 (agosto). Cuatro sitios en 76 segundos, en dos infraestructuras distintas que solo tenían en común a la persona que las administraba. Ya no era un MU-plugin: era un plugin normal con nombre plausible, más inyecciones dentro de archivos legítimos de Akismet, Elementor Pro y JetEngine, más un instalador escondido como .jpg. Eso descartó el acceso al hosting y apuntó a credenciales de administrador de WordPress en manos del atacante.

Oleada 3 (agosto, dos días después de rotar contraseñas). Entraron con una sesión de administrador que seguía siendo válida después del cambio de contraseña (WordPress no cierra las sesiones abiertas al cambiar la clave) y usaron el editor de temas. Esta vez el contenido inyectado estaba en 94 posts de un sitio y 14 de otro.

Lo que cerró el problema no fue la limpieza: fue rotar todas las credenciales, destruir todas las sesiones, activar 2FA en todos los sitios, bloquear el editor de archivos, y extender eso también a los sitios de clientes alojados en otros hostings donde la misma cuenta de administrador existía. Uno de esos sitios, fuera del perímetro que se estaba mirando, siguió infectado once días más por esa única razón.

Qué hacer si tu WordPress está infectado: paso a paso

Este es el procedimiento que aplico. El orden importa.

Paso 0: no borres nada todavía

Preservá evidencia. Copiá los archivos sospechosos a una carpeta fuera del directorio público conservando fechas (cp -p), anotá la hora de modificación de cada uno (stat) y exportá la tabla de sesiones. Sin las fechas no vas a poder reconstruir cuándo y cómo entraron, y sin eso no podés cerrar la puerta.

Paso 1: respaldo completo, aunque esté infectado

Archivos y base de datos, fuera del webroot. Si la limpieza rompe algo, tenés a dónde volver. Un respaldo infectado es mejor que ningún respaldo.

Paso 2: encontrá todos los focos

Hacé la lista completa antes de tocar nada: MU-plugins, plugins, functions.php, archivos alterados dentro de plugins, posts, opciones, tareas cron, usuarios administradores desconocidos, archivos con extensión falsa. Si limpiás un foco y dejás otro, se reinstala.

Ojo con lo que no cubre wp core verify-checksums: solo verifica el núcleo de WordPress. No mira plugins ni temas. Un «todo verifica» del núcleo no dice nada sobre un functions.php o un archivo de Akismet.

Paso 3: limpiá archivos y base de datos

Plugins del repositorio oficial con archivos alterados: reinstalalos desde cero (wp plugin install <slug> --force). No los edites a mano.
Plugins premium alterados: reinstalalos desde el paquete original de la licencia. No hay checksums públicos para compararlos.
Temas: restaurá el functions.php original o quitá la línea inyectada, y verificá la sintaxis con php -l antes de subirlo.
Posts: limpiá el bloque <script> con una expresión regular probada primero en modo simulación, contando cuántos bytes quita a cada post. En el caso real, cada post perdió exactamente 3.177 bytes: si uno perdía más o menos, la regex estaba mal. Acordate de que las revisiones guardan su propia copia del contenido: si limpiás el post y no la revisión, el script sigue ahí (si nunca las viste, así funcionan las revisiones de WordPress).
Borrá el ZIP disfrazado de imagen y cualquier archivo PHP dentro de uploads.
Quitá de active_plugins cualquier entrada cuyo archivo no exista: es un cargador latente esperando que repongan el archivo.

Paso 4: neutralizá el service worker (no lo borres)

Si el malware registró un service worker (nochain-sw.js o similar), no borres el archivo. El service worker ya instalado en el navegador de cada víctima sigue corriendo con su lógica en caché aunque el archivo desaparezca del servidor, y ya no hay forma de alcanzarlo.

Reemplazá su contenido por un kill-switch: un script que en su próxima activación borra sus cachés, se desregistra y recarga la página. Dejalo publicado varias semanas. Y avisale al hosting por qué el archivo sigue existiendo, o su escáner lo va a marcar de nuevo solo por el nombre.

Paso 5: cerrá la puerta

Esto es lo que diferencia una limpieza de una limpieza que dura:

Rotá todas las contraseñas: administradores de WordPress, base de datos, panel de hosting, FTP, SSH. Todas, únicas, generadas por un gestor de contraseñas.
Destruí todas las sesiones de todos los usuarios (wp user session destroy <id> --all). Cambiar la contraseña no cierra las sesiones abiertas.
Rotá las salts de wp-config.php: invalida cualquier cookie robada.
Revisá y revocá las application passwords: sobreviven a cualquier cambio de contraseña.
Bloqueá el editor de archivos con define('DISALLOW_FILE_EDIT', true); en wp-config.php. Es la herramienta exacta que usaron.
Activá la verificación en dos pasos en cada WordPress y en el panel del hosting.
Cerrá FTP si no lo usás: es texto plano.
Eliminá los usuarios administradores que no reconozcas, y revisá los que sí: ¿tienen el correo correcto?

Paso 6: revisá tu propia computadora

Si el atacante tiene las credenciales de administrador y no hay una vulnerabilidad que lo explique, la pregunta es de dónde las sacó. La respuesta más probable es un infostealer en la computadora de alguien que administra el sitio. Un análisis completo del antivirus (no el rápido), cierre de todas las sesiones del navegador, y cambio de contraseñas desde un equipo limpio.

Paso 7: purgá cachés y verificá desde fuera

Purgá LiteSpeed, WP Rocket, Cloudflare o lo que uses. Después comprobá desde fuera del servidor, con un user-agent de Chrome y un Referer de Google, la portada y varios posts. «El comando no dio error» no es verificación; una respuesta HTTP 200 sin el script inyectado, sí.

Paso 8: respondé al hosting y a Google

Si hubo ticket de abuse, respondelo con detalle: qué era, qué se removió, cómo verificarlo y por qué algún archivo con nombre sospechoso sigue existiendo (el kill-switch). Si Search Console marcó el sitio, pedí la revisión una vez limpio.

Paso 9: avisá a quien corresponda

Si es el sitio de un cliente, sus visitantes estuvieron expuestos. Decírselo es parte del trabajo, aunque sea incómodo.

Si sos un visitante y ejecutaste el comando

Tratá tu computadora como comprometida, porque lo está.

Desconectala de internet y hacé un análisis completo con el antivirus actualizado.
Desde otro dispositivo limpio, cambiá las contraseñas empezando por el correo, después cuentas de Google/Microsoft/Apple, banco, billeteras, redes sociales y cuentas del trabajo.
Cerrá todas las sesiones activas en cada servicio (la opción «cerrar sesión en todos los dispositivos»). El ladrón tiene tus cookies: con eso entra sin contraseña.
Activá 2FA donde no lo tuvieras.
Si en esa computadora administrabas un sitio web, avisá inmediatamente a quien lo mantiene: el atacante tiene esas credenciales.

Por qué ClickFix vuelve (y cómo evitar la reinfección)

La reinfección es la norma, no la excepción, por tres motivos:

Se limpia el síntoma, no el acceso. Borrar el archivo que muestra el CAPTCHA sin rotar credenciales es invitar al atacante a volver mañana, y va a volver con un escondite distinto.
Las sesiones y las application passwords sobreviven al cambio de contraseña. Se rota la clave, el atacante sigue adentro con la sesión vieja.
El perímetro es más grande de lo que se mira. Si el vector son las credenciales de quien administra, el alcance es todo lo que esa persona administra, en cualquier servidor.

La prevención que funciona es aburrida y consistente:

Mantenimiento mensual real: núcleo, plugins y temas al día, con respaldo previo y verificación posterior. Un plugin sin licencia activa no anuncia actualizaciones y queda ciego a los parches: hubo un caso con una vulnerabilidad de ejecución remota sin parchear por eso.
Gestor de contraseñas y 2FA en todos los accesos, sin excepciones ni «por ahora».
Principio de mínimo privilegio: cada persona con su usuario, con el rol que necesita. Sin cuentas de administrador compartidas.
DISALLOW_FILE_EDIT en todos los sitios, siempre.
Vigilancia de vulnerabilidades publicadas por plugin (por ejemplo, con la API de WPScan), porque un plugin íntegro y desactualizado pasa el checksum y es explotable igual.
Barrido periódico de MU-plugins, functions.php de temas y patrones de ofuscación, con fechas de modificación.
Leer el correo del hosting.

Errores comunes al limpiar un sitio hackeado

Restaurar un backup sin saber la fecha de la intrusión. Si el compromiso fue hace 46 días y el backup tiene 30, restaurás el malware.
Borrar el service worker. Deja a cada víctima con el malware instalado en el navegador para siempre.
Confiar solo en verify-checksums del núcleo. No cubre plugins ni temas, que es justo donde se esconde.
Escanear solo la portada. Los posts pueden estar infectados con la portada limpia.
Buscar un solo marcador. El mismo operador cambió de contrato, de red y de ofuscación en semanas. Hay que buscar por comportamiento (atob, TextDecoder, new Function, eth_call), no por un nombre de archivo.
Limpiar sin cerrar el acceso. Es el error más caro. Volvieron en 9 días la primera vez y en 2 la segunda.
Dar por limpio un sitio que no está en «tu» servidor. Si administrás sitios de clientes en otros hostings con la misma cuenta, están en el alcance.
Usar el escáner del hosting como única fuente. Encuentra parte, sustituye archivos a veces mal, y su cuarentena no siempre es visible por SSH.

Indicadores de compromiso (IOC) observados

Para quien esté buscando en su servidor. Los nombres cambian entre campañas; los patrones de comportamiento, menos.

Tipo	Indicador
MU-plugin	`wp-content/mu-plugins/nc-dropin.php`
Service worker	`/nochain-sw.js`, `wp-content/nochain/sw.js`, ruta dinámica `/?nochain_sw=1`
Plugin falso	`wp-content/plugins/site-helper-<12 hex>/` con `assets/ethers.min.js` o `assets/lib.umd.js` y `assets/diag-runner.js`
Instalador disfrazado	`wp-content/uploads/<año>/<mes>/cache-<8 hex>.jpg` (es un ZIP)
Variables en el HTML	`wpCacheProbe<N>`, `wpPerfSample<N>`, handles `sh<12 hex>_vendor-js` / `_runtime-js`
Cookie de evasión	`nc_skip=1`
Ofuscación	`atob(...)` + XOR de un byte + `new Function(new TextDecoder().decode(...))()`
Contratos	`0x58460d0b3d4d6b03761c89120393c0c676676496` (Base) · `0xB6bC9e1D0b2fB96Ab7C47E04Cb0BE477410bC1f2` (Polygon)
Firma de sesiones	Logins de administrador desde IPs de datacenter/VPN con user-agent Mac / Safari 18, seguidos de escritura de `functions.php` en menos de un minuto
Admin fantasma	Usuarios `adm<6 alfanum>` con correo `@example.com`

Preguntas frecuentes

¿Qué es el CAPTCHA falso «Verify you are human» que aparece en mi sitio?

Es el síntoma visible de ClickFix: un malware instalado en tu WordPress que muestra a los visitantes una verificación falsa para que ejecuten un comando en su computadora. No es un problema del navegador del visitante ni de Cloudflare: es tu sitio el que está infectado.

¿Por qué yo no lo veo y mis visitantes sí?

Porque el malware detecta que estás logueado o que entraste a wp-admin y te excluye a propósito. Probá en una ventana de incógnito, desde otro dispositivo, entrando desde un resultado de Google.

¿Es peligroso para mí o para mis visitantes?

Para tus visitantes, mucho: quien ejecuta el comando termina con un infostealer que le roba contraseñas, sesiones y billeteras. Para vos, también: el atacante tiene acceso a tu sitio, y si alguien de tu equipo cayó, tiene tus credenciales. Además Google puede marcar el sitio como peligroso y el hosting puede suspenderte la cuenta.

¿Google me va a penalizar?

Google puede mostrar la advertencia «Este sitio puede dañar tu ordenador» y sacarte de los resultados hasta que limpies y pidas revisión desde Search Console. Cuanto más tiempo pase, más tráfico y reputación perdés.

¿Con desactivar el plugin sospechoso alcanza?

No. El plugin se reinstala solo desde una copia disfrazada de imagen, y suele haber otros focos: el functions.php del tema, archivos alterados dentro de plugins legítimos, posts en la base de datos y un service worker en los navegadores de las víctimas. Y aunque quitaras todo, si no rotás credenciales y cerrás sesiones, vuelven.

¿Sirve restaurar un backup?

Solo si estás seguro de que el backup es anterior a la intrusión, que suele ser semanas antes de que se note. Y aun así hay que rotar todas las credenciales, porque el backup no arregla cómo entraron.

¿Cuánto tarda la limpieza?

La contención (dejar de servir el malware) se hace el mismo día. La limpieza completa, la rotación de accesos, el endurecimiento y la verificación llevan entre uno y tres días según la cantidad de sitios y de focos. Si son varios sitios en la misma cuenta, se limpian todos: la infección casi nunca es de uno solo.

¿Qué es EtherHiding?

Es la técnica de guardar la configuración del malware en un contrato inteligente de una blockchain pública. Le permite al atacante cambiar lo que hace el script sin tocar tu servidor y hace imposible «dar de baja» su infraestructura. Es el motivo por el que limpiar el servidor sin cerrar el acceso no sirve: el control lo tiene él, desde afuera.

¿Qué hago si ya ejecuté el comando en mi computadora?

Tratala como comprometida: análisis completo, cambio de contraseñas desde otro dispositivo empezando por el correo, cierre de sesiones en todos los servicios y 2FA. Si desde esa computadora administrabas un sitio, avisá ya a quien lo mantiene.

¿Cómo evito que vuelva a pasar?

Mantenimiento mensual real, gestor de contraseñas, 2FA en todo, editor de archivos deshabilitado, un usuario por persona, vigilancia de vulnerabilidades y alguien que lea los avisos del hosting. No hay ninguna medida mágica; hay consistencia.

Servicio de limpieza y recuperación de WordPress hackeado

En BelkCar Informática atiendo este tipo de incidentes como parte del servicio de mantenimiento y seguridad WordPress, y también como intervención puntual cuando el sitio ya está infectado. El procedimiento es exactamente el de este artículo:

Contención el mismo día: tu sitio deja de servir el malware a los visitantes.
Diagnóstico forense: encuentro todos los focos y reconstruyo cómo y cuándo entraron, con evidencia (fechas de archivos, sesiones, logs).
Limpieza completa: archivos, base de datos, plugins reinstalados desde origen, service worker neutralizado.
Cierre del acceso: rotación de todas las credenciales, destrucción de sesiones, 2FA, editor bloqueado, endurecimiento del servidor.
Verificación real desde fuera, respuesta al abuse del hosting y pedido de revisión a Google.
Informe para vos y para tus clientes, en castellano claro, con lo que pasó y lo que se hizo.
Prevención: plan de mantenimiento mensual para que no se repita.

Trabajo con sitios en Hostinger, SiteGround, cPanel y VPS propios, en Argentina y en el exterior.

Contacto directo:

WhatsApp: +54 9 342 509-9651
Correo: contacto@belkcarinformatica.com
Formulario: belkcarinformatica.com/contacto

Si me escribís, mandame el dominio y, si podés, una captura de lo que ven tus visitantes. Con eso alcanza para arrancar.

También te puede interesar

Error ERR_QUIC_PROTOCOL_ERROR en WordPress: qué es y cómo solucionarlo — el otro caso de «algunos visitantes ven algo raro y yo no».
Cloudflare, IA y la caída global del 18 de noviembre de 2025 — qué pasa cuando tu sitio depende de infraestructura que no controlás.
Por qué no veo las revisiones en WordPress — dónde queda guardada de verdad una copia de cada post.
This article in English — la versión en inglés, con el mismo caso y el mismo procedimiento.

Federico Díaz es el responsable técnico de BelkCar Informática (Santa Fe, Argentina). Administra y mantiene sitios WordPress para medios, comercios, instituciones deportivas y alojamientos turísticos desde hace más de una década. Este artículo se basa en incidentes reales atendidos entre junio y agosto de 2026; los sitios afectados se mantienen en el anonimato por respeto a sus dueños.

ClickFix en WordPress: el falso CAPTCHA que infecta a tus visitantes (y cómo limpiarlo de verdad)