Secuestro WordPress por plugin: 400K sitios en riesgo

Actualizado el 02/09/2026 — Este artículo fue actualizado con información reciente, nuevas tendencias de ataques en 2026 y secciones expandidas sobre vectores menos obvios.

El secuestro de WordPress por una vulnerabilidad de plugin es uno de los ataques más graves que puede sufrir un sitio web: un atacante explota una falla en un plugin instalado para tomar control del panel de administración, cambiar contraseñas, inyectar malware o redirigir tráfico. En 2026, los datos muestran que siguen afectando cientos de miles de sitios activos en todo el mundo.

Un secuestro de WordPress ocurre cuando un atacante obtiene control administrativo total sobre un sitio, ya sea por credenciales robadas o explotación de vulnerabilidades en plugins. El resultado: el dueño legítimo pierde acceso y otra persona controla todo lo que se publica, adónde redirige el tráfico y qué código ejecutan los navegadores de los visitantes. En 2026, el vector más común es la explotación de fallas de autorización en plugins con millones de instalaciones activas, afectando desde blogs pequeños hasta sitios de comercio electrónico con miles de usuarios. La recuperación requiere identificar el punto de entrada, restaurar desde backup limpio y aplicar parches críticos en el mínimo tiempo posible.

WordPress es un sistema de gestión de contenidos de código abierto creado por Mike Little y Matt Mullenweg en 2003, utilizado para crear y administrar sitios web y blogs, desarrollado por la comunidad global y Automattic.

Diferencia entre Domain Takeover y Account Takeover en WordPress

No son lo mismo y la confusión causa malinterpretaciones sobre el daño real. Un domain takeover implica que el atacante toma control del dominio a nivel DNS: puede apuntar el dominio a otro servidor completamente diferente, hacer que el sitio desaparezca de la internet o servir un sitio totalmente distinto desde el mismo dominio. Un account takeover es más específico: el atacante toma control del panel de administración de WordPress pero el sitio sigue alojado en el mismo servidor, bajo el mismo dominio.

La diferencia importa porque el mecanismo de recuperación es diferente. En un domain takeover necesitás regain acceso a los registros del dominio (Whois, hosting del registrador), cambiar nameservers o apuntadores A. En un account takeover necesitás acceso FTP/SSH para resetear la base de datos, o acceso al email de admin para recuperar la contraseña vía WordPress. La mayoría de los CVEs documentados en 2025-2026 son account takeovers que resultan en el sitio funcionando como vector de distribución de malware o spam SEO.

En términos prácticos: si alguien tomó el control de tu panel WordPress pero tu dominio sigue apuntando al servidor correcto, es account takeover. Si el dominio está apuntando a otro servidor y el sitio desapareció, es domain takeover. Pero aunque sean ataques distintos, el resultado visible es el mismo: perdiste el control del sitio.

Los CVEs Más Críticos que Definieron 2025-2026

Acá es donde el panorama se pone concreto. No es vaguedad sobre «plugins peligrosos»: son CVEs específicos con millones de instalaciones afectadas y explotación activa confirmada.

CVE-2025-11833 — Post SMTP (400.000 sitios comprometidos)

Este es el que más daño hizo en el ciclo reciente. Según Wordfence, la falla estaba en el endpoint /wp-json/post-smtp/v1/get-log, accesible sin autenticación. Desde ahí, cualquier atacante podía leer los logs del plugin y extraer tokens de reset de contraseña enviados por email. Con ese token, el flujo era trivial: solicitar reset de contraseña para admin@tudominio.com, capturar el token del log, cambiar la contraseña, entrar al panel como admin. Sin fuerza bruta, sin sofisticación técnica especial.

• CVSS: 9.8 (crítico)
• Versiones afectadas: anteriores a 2.9.1
• Instalaciones activas: más de 400.000 en el momento del parche
• Ataques bloqueados en el primer mes: más de 4.500 intentos confirmados por Wordfence

CVE-2024-10924 — Really Simple Security (4 millones de sitios expuestos)

El más masivo del período. Según SecurityWeek, la vulnerabilidad en el plugin Really Simple Security (anteriormente Really Simple SSL) permitía a un atacante autenticarse como cualquier usuario del sitio, incluyendo admins, con una request manipulada. El plugin tenía 4 millones de instalaciones activas al momento del descubrimiento. La gravedad: el bypass funcionaba con una única request HTTP, sin necesidad de conocer contraseñas.

• CVSS: 9.8 (crítico)
• Vector: autenticación completamente bypasseada con manipulación de headers
• Instalaciones activas: 4 millones en el momento del parche

CVE-2024-8353 — GiveWP (Donaciones – 100.000+ sitios)

PHP object injection en el plugin de donaciones más usado de WordPress. La vulnerabilidad permitía ejecución de código arbitrario sin autenticación. Si tu sitio tenía GiveWP para recibir donaciones y no estaba actualizado, cualquiera podía ejecutar comandos en el servidor. Bitdefender identificó más de 100.000 sitios vulnerables activos durante el período de explotación, muchos de ellos con actividad maliciosa confirmada.

• CVSS: 9.8 (crítico)
• Tipo: PHP object injection → RCE sin autenticación
• Afectados confirmados: 100.000+ sitios con tráfico activo

CVE-2025-5394 — Componentes de Instalación de Temas (Arbitrary File Upload)

Falla en componentes de instalación de temas que permitía file upload arbitrario. Con acceso mínimo (en algunos casos suscriptores autenticados), se podía subir un webshell PHP que el servidor ejecutaría. Afectó múltiples plugins que implementaban funciones de instalación custom, especialmente en versiones antiguas no mantenidas.

• CVSS: 8.8 (alto)
• Impacto: ejecución de código mediante carga de archivos arbitrarios
• Contexto: afectó plugins legacy con miles de instalaciones

WP-Cron: El Vector Auxiliar que Persiste

WP-Cron no es el atacante principal pero aparece constantemente como herramienta auxiliar para escalar explotaciones. El archivo wp-cron.php ejecuta tareas programadas en WordPress cada vez que alguien visita el sitio. El problema fundamental: por defecto es accesible públicamente desde cualquier navegador.

CVE-2023-22622 documentó explícitamente cómo se puede abusar de este mecanismo. Un atacante puede generar carga excesiva en el servidor (DoS distribuido) haciendo requests a wp-cron.php desde múltiples IPs. O, más grave, puede forzar la ejecución de tareas maliciosas que fueron registradas durante una intrusión anterior. El malware Monarx (mayo 2026) usa exactamente esto: crea un script que contacta a su C2 cada 6 minutos vía wp-cron, descargando payloads nuevos. Sin desactivar wp-cron, limpiar Monarx es casi imposible porque el malware se re-descarga automáticamente cada 6 minutos.

La mitigación es directa. En wp-config.php, agregá esta línea:

define('DISABLE_WP_CRON', true);

Luego configurá un cron job real del servidor (vía panel de hosting u SSH) para ejecutar wp-cron.php cada 15 minutos. Alternativamente, bloqueá el acceso externo al archivo desde el archivo .htaccess o la configuración del servidor web. Esto solo, sin hacer nada más, cierra un vector que muchos sitios tienen abierto sin ni saberlo.

Monarx: El Malware Self-Healing que Documenta el Futuro

Monarx (primer documentado masivamente en mayo 2026) es importante porque representa un cambio en la sofisticación de los ataques contra WordPress. No es un malware clásico que se instala una sola vez: es autoreplicante, contacta a un C2 cada 6 minutos, descarga payloads nuevos y se auto-remedienta si lo eliminas del servidor.

El mecanismo es relativamente simple pero efectivo. Monarx crea un script PHP (usualmente con nombre de archivo aleatorio tipo wp-cache-f8a3b.php) en carpetas de uploads o en la raíz de WordPress. Este script contacta a un servidor C2 (usualmente un dominio comprometido) cada 6 minutos. El servidor retorna instrucciones: inyectar nuevos backdoors, descargar ransomware, crear usuarios admin adicionales, etc. Si un administrador borra el archivo malicioso, la próxima vez que wp-cron.php se ejecuta, el C2 le ordena al sitio re-descargar el malware.

Por eso desactivar wp-cron es crítico para limpiar Monarx: sin la tarea de cron, el malware pierde su mecanismo de auto-remediación. Pero si wp-cron sigue activo, el atacante puede reconstruir la infección desde distancia sin tocar el servidor.

Síntomas específicos de infección Monarx:

• Archivos PHP aleatorios en /wp-content/uploads/ o raíz: busca archivos con nombres tipo wp-*.php, cache-*.php, functions-*.php
• Cuentas admin nuevas que reaparecen después de borrarlas: eliminas el usuario, pero 6 minutos después vuelve a existir
• Logs de servidor mostrando requests POST a wp-cron.php desde IPs externas: normalmente wp-cron se ejecuta internamente, no recibe requests POST desde afuera
• Dominios sospechosos en los logs: el C2 suele ser un dominio reciente o recientemente reregistrado

Cómo Explotan las Vulnerabilidades: La Cadena de Ataque Real

Tomemos el caso de CVE-2025-11833 en Post SMTP porque es el más documentado. El flujo que siguen los atacantes automatizados es este.

Primero: reconocimiento básico. El atacante escanea miles de dominios buscando si el endpoint /wp-json/post-smtp/v1/get-log retorna datos. Si responde, el sitio es vulnerable. Para esto usa herramientas como Nuclei (que tiene templates públicos para cada CVE nuevo) o scripts personalizados.

Segundo: extracción de credenciales. Una vez confirmado que el sitio es vulnerable, el atacante extrae los logs del plugin. Estos contienen todos los emails enviados, incluyendo los de reset de contraseña con tokens válidos.

Tercero: entrada al panel. Con el token en mano, hace una solicitud POST a /wp-login.php?action=rp con el token extraído. Esto resetea la contraseña del admin. Cambia la contraseña a algo conocido, entra como admin.

Cuarto: consolidación de acceso. Crea una cuenta backdoor adicional (por si la primera es detectada), activa FTP/SSH si puede, y descarga credenciales del archivo wp-config.php para acceso a la base de datos.

Quinto: operación según el objetivo. Si es spam SEO: inyecta links en posts existentes o crea posts nuevos con links a sitios afiliados. Si es distribución de malware: modifica los archivos del tema para agregar JavaScript que redirige visitantes móviles a páginas de descarga maliciosa. Si es data theft: instala un keylogger que captura credenciales de usuarios del sitio.

Todo esto automatizado. Según Patchstack, en Q1 2025 el plugin Service Finder acumuló 9 millones de intentos de explotación en pocas semanas. No es un trabajo manual artesanal: son bots que escanean dominios a la velocidad de miles por hora.

Síntomas de un WordPress Comprometido: Qué Buscar

Algunos síntomas son obvios. Otros, no tanto. Si detectás cualquiera de estos, es probable que estés comprometido.

• Cuentas admin nuevas que no creaste: entrás a Usuarios y hay uno o varios con rol «Administrador» que no reconocés. Señal de alarma máxima. Anotá la fecha de creación porque indica cuándo empezó la intrusión.
• Redirecciones inesperadas a otros sitios: visitantes (especialmente en móviles) terminan en páginas de casinos, farmacia o phishing. Lo reportan los propios usuarios o lo ves en Search Console como «redirección detectada».
• Advertencias de navegadores: Chrome o Firefox marcan el sitio como «peligroso», «sitio de phishing» o «descargó malware». Google ya lo escaneó y encontró algo malicioso.
• Caída de tráfico orgánico sin cambios de contenido: en una semana, el tráfico cae 30-70% sin que hayas tocado nada. Google puede haber desindexado páginas con spam injected en el HTML.
• Emails masivos desde tu dominio: tu servidor empieza a enviar spam automatizado y ves rebotes o quejas de abuse de los proveedores de email (Gmail, Hotmail, etc.).
• Archivos PHP raros en carpetas extrañas: archivos con nombres aleatorios (tipo wp-cache-f8a3b.php, functions-backup.php) en /wp-content/uploads/ o en la raíz de WordPress. WordPress no crea eso por defecto.
• Campos ocultos en posts: abrís un post en el editor y hay HTML inyectado que el visitante no ve (está marcado con display:none o hidden). Es iframe o script malicioso disfrazado.
• Base de datos creciendo sin explicación: el tamaño de la DB salta de 50 MB a 500 MB sin que hayas agregado contenido. El atacante está guardando datos robados o inyectando registros maliciosos.

La herramienta más confiable para un diagnóstico rápido es Wordfence (scanner gratuito). Hace un análisis completo del servidor, archivos y base de datos, buscando malware, vulnerabilidades y archivos modificados.

Tendencias de Ataques a WordPress en 2026

Más allá de los CVEs individuales, hay patrones que vemos en 2026 que son importantes entender. Los atacantes evolucionan según qué funciona.

Ataques de supply chain son el nuevo estándar. En lugar de buscar vulnerabilidades nuevas en todos los plugins, ahora comprometen repositorios o distribuidores de plugins populares. El incidente de ShapedPlugin (mayo 2026) donde backdoorearon las actualizaciones Pro es el patrón: un archivo comprometido llega a 100.000 sitios en 24 horas vía actualización automática. La defensa manual es imposible si no tenés una política de «revisar actualizaciones de plugins críticos antes de instalarlas».

Explotación masiva dentro de horas de la divulgación pública. Post SMTP: explotación dentro de 24 horas. WP2Shell: 90 minutos. Los PoCs públicos (Proof of Concept) se distribuyen en comunidades de hackers casi instantáneamente, y los bots incorporan templates de Nuclei del día mismo de la publicación. La ventana de tiempo para actualizar se redujo a horas, no días.

Multiples capas de backdoors para persistencia. Monarx ilustra esto: no instalan un solo malware, instalan 3-4 capas. Un backdoor en wp-config.php, otro en los temas, un tercero vía usuario admin, un cuarto vía archivo PHP en uploads. Si eliminas uno, los otros tres mantienen el acceso.

Ataques dirigidos a hosting de bajo costo. Hosting compartido, servidores gestionados por personal no técnico: son los blancos principales. Donweb (entre otros proveedores de Argentina) con aislamiento por cuenta y soporte técnico reduce este riesgo significativamente versus hosting compartido commodity.

Pasos de Emergencia para Recuperar tu Sitio

Si ya fuiste comprometido, el orden importa. Hacer las cosas en la secuencia equivocada puede complicar la recuperación o perder evidencia de cómo entraron.

• Paso 1: Cambiá todas las contraseñas inmediatamente. WordPress admin, base de datos (user/pass en wp-config.php), FTP/SFTP, y el panel de tu hosting. Si el atacante sigue con acceso a cualquiera de estos, todo lo demás es inútil. Hacerlo desde una máquina diferente (no desde el servidor comprometido si es posible).
• Paso 2: Tomá el sitio offline temporalmente. Si estás distribuyendo malware a visitantes, seguir online hace daño activo. Activá modo mantenimiento (plugin Maintenance Mode) o poné una página HTML estática en raíz mientras trabajás. Esto evita que Google meta más contenido malicioso al índice.
• Paso 3: Identificá la fecha del compromiso en los logs del servidor. Revisa logs de acceso (access.log) buscando requests sospechosas (POST a wp-json con patrones raros, GET a wp-cron.php desde IPs externas). Si no tenés logs activos, eso es una deuda que pagás ahora. Esto te dice cuándo empezó la intrusión.
• Paso 4: Eliminá usuarios sospechosos y plugins maliciosos. Cualquier admin que no reconocés, fuera. Cualquier plugin que no instalaste vos, fuera. Pero no borres el archivo del plugin — renombralo primero en FTP a .php.bak para evitar desactivaciones automáticas que pueden dejar trazas. Revisá también los archivos subidos recientemente (búscá modificadas después de tu fecha sospechosa).
• Paso 5: Restaurá desde backup limpio anterior a la intrusión. Acá es crítico: si tu backup más reciente es de ayer y el atacante lleva una semana activo, restaurás el sitio comprometido. Necesitás un backup anterior a la fecha que identificaste en el paso 3. Si no tenés backup limpio accesible, podés tomar el backup más reciente y limpiar manualmente todos los usuarios admin sospechosos de la base de datos usando phpMyAdmin.
• Paso 6: Actualizá TODO al mismo tiempo. WordPress core, todos los plugins, todos los temas. Después de limpiar, si no actualizás el plugin vulnerable, volvés a ser atacado en horas. Las actualizaciones automáticas deberían estar habilitadas por defecto en producción.
• Paso 7: Notificá a Google si el sitio fue marcado como peligroso. Search Console muestra el sitio como peligroso si Google detectó malware. Después de limpiar, pedís revisión manual desde la sección «Problemas de seguridad» en GSC. Google puede tardar 24-72 horas en volver a indexar.

Tabla Comparativa de Vulnerabilidades Críticas 2025-2026

CVE	Plugin / Core	Tipo	CVSS	Sitios Afectados	Estado Actual
CVE-2025-11833	Post SMTP	Auth bypass + token leak	9.8	400.000+	Parcheado en v2.9.1
CVE-2024-10924	Really Simple Security	Authentication bypass	9.8	4.000.000+	Parcheado
CVE-2024-8353	GiveWP	PHP object injection → RCE	9.8	100.000+	Parcheado
CVE-2026-3300	Everest Forms Pro	PHP injection	9.8	100.000+	Parcheado
CVE-2023-22622	WP Core (wp-cron)	DoS + task abuse	7.5	Todos los WP	Mitigación manual
CVE-2026-63030 + CVE-2026-60137	WordPress Core	RCE sin autenticación (encadenado)	9.9	Miles afectadas	Parcheado en 7.0.2

Prevención Permanente: Lo Que Realmente Funciona

Hay una brecha entre lo que la mayoría hace y lo que debería hacer. Muchos tienen Wordfence instalado pero no configuraron alertas. O tienen backups automáticos pero nunca probaron restaurar uno. La herramienta sin la configuración correcta no sirve.

Lo mínimo en 2026:

• Actualizaciones automáticas habilitadas para WordPress core y todos los plugins. Sí, automáticas, aunque a veces rompan algo. El riesgo de un ataque es mayor que el riesgo de una actualización que sale mal.
• 2FA obligatorio para admins y editores: cualquier cuenta con capacidad de escribir o editar contenido debe tener autenticación de dos factores. Si la contraseña es robada, el atacante sigue sin poder entrar.
• Backups diarios almacenados fuera del servidor: no en la misma cuenta de hosting, no en el mismo disco. En cloud (Google Drive, AWS S3, Backblaze) o en un servidor diferente.
• Alertas de login activas: cada vez que alguien accede al panel de admin, se genera una alerta por email. Si ves alertas de IPs que no reconocés, sabés que hay un problema.
• Monitoreo de integridad de archivos: Wordfence monitorea cambios en archivos core de WordPress. Si algo modifica wp-login.php o wp-config.php, te avisa en minutos.

Lo que marca la diferencia real:

• Deshabilitar la edición de plugins y temas desde el panel: agregá esta línea a wp-config.php: define('DISALLOW_FILE_EDIT', true);. Si un atacante llega al panel pero no puede editar archivos desde ahí, el daño se reduce dramáticamente.
• Desactivar wp-cron y usar cron real del servidor: ya lo mencionamos pero es crítico. define('DISABLE_WP_CRON', true); en wp-config.php + configurar un cron job en el hosting para ejecutar wp-cron.php cada 15 minutos.
• Aislar la instalación de WordPress: si estás en hosting compartido, verificá que sea «cuenta aislada» (cada cliente es una cuenta separada) versus shared hosting donde todas las cuentas comparten servidor. Una instalación comprometida en shared hosting puede comprometer otras cuentas del mismo servidor.
• Limitar intentos de login fallidos: hay plugins que bloquean IPs después de X intentos fallidos. Reduce la efectividad del ataque de fuerza bruta.

Impacto Real en Sitios Afectados

Los números abstractos no transmiten lo que significa en la práctica.

En el caso de CVE-2025-11833 (Post SMTP), Wordfence reportó más de 4.500 ataques bloqueados en el primer mes después de la divulgación pública. Pero los que NO fueron bloqueados (sitios sin Wordfence) enfrentaron escenarios graves: distribución de malware a visitantes, spam SEO masivo que les costó semanas de limpieza manual en Search Console, penalizaciones manuales de Google por contenido malicioso, y pérdida de reputación frente a usuarios que vieron advertencias de navegador.

El plugin Service Finder acumuló 9 millones de intentos de explotación en pocas semanas. Eso da una idea de la velocidad y escala con que los bots automatizados incorporan nuevas vulnerabilidades.

El downtime promedio de un sitio comprometido sin backup limpio accesible: entre 3 y 7 días hábiles para recuperación completa. Para un e-commerce, eso es daño directo calculable en pérdida de ventas. Para un blog, es indexación perdida y reputación dañada.

Errores Comunes que Empeoran la Situación

• Error 1: Instalar un plugin de seguridad sin configurarlo. Wordfence instalado en modo default no es lo mismo que Wordfence configurado con alertas por email, reglas de firewall activas y scanner automático cada 12 horas. La instalación sin configuración da falsa sensación de protección.
• Error 2: Actualizar plugins «cuando hay tiempo». CVE-2025-11833 tuvo explotaciones activas dentro de 24 horas de divulgación. Una semana de demora es una semana de ventana abierta. Las actualizaciones automáticas existen por esta razón.
• Error 3: No revocar accesos después de proyectos. Cualquiera que haya trabajado en el sitio (freelancers, diseñadores, agencias) y ya no lo hace debe tener su cuenta eliminada o desactivada. Cuentas sin uso son superficie de ataque latente.
• Error 4: Restaurar el backup más reciente sin verificar fecha de compromiso. Si el atacante lleva una semana activo y tu backup más reciente es de ayer, restaurás el sitio comprometido. Necesitás identificar la fecha aproximada del compromiso primero.
• Error 5: Ignorar alertas de Google Search Console. GSC envía avisos de seguridad cuando detecta malware. Muchos admins no revisan GSC regularmente y se enteran del problema por usuarios que les avisan que el navegador bloquea el sitio.
• Error 6: No cambiar wp-admin a URL personalizada. Es cosmético pero reduce escaneos automatizados. Cambiar /wp-admin/ a /gestion/ (o cualquier otra URL) hace que los bots pierdan tiempo buscando el panel.

Preguntas Frecuentes

¿Cómo se produce el secuestro de cuenta admin en WordPress?

El vector más común es la explotación de vulnerabilidades en plugins. CVE-2025-11833 es el ejemplo: el atacante lee logs del plugin sin autenticación, obtiene un token de reset de contraseña, y cambia la contraseña del admin. Otras vías incluyen credenciales robadas por phishing, contraseñas débiles con fuerza bruta, y SQL injection en plugins de formularios mal escritos.

¿Cómo sé si mi WordPress fue comprometido por CVE-2025-11833?

Primero: verificá si tenés Post SMTP instalado en una versión anterior a 2.9.1. Si es así, actualizá inmediatamente. Luego: revisa en el log de actividad de WordPress (plugin Activity Log) cuentas admin creadas en fechas que no reconocés. Wordfence hace un scanner completo para identificar archivos modificados o código malicioso.

¿Cuál es la diferencia entre domain takeover y account takeover?

Domain takeover implica control del dominio a nivel DNS: el atacante puede apuntar el dominio a otro servidor. Account takeover es control del panel de WordPress con el dominio apuntando al mismo lugar. El segundo es mucho más frecuente en 2025-2026 y es lo que documentan la mayoría de CVEs.

¿Cómo recupero mi sitio hackeado?

La secuencia correcta es: cambiar todas las contraseñas (WP, base de datos, FTP, hosting), identificar la fecha del compromiso en logs del servidor, restaurar un backup anterior a esa fecha, eliminar usuarios admin no reconocidos, actualizar todos los plugins y core, y pedir revisión de seguridad a Google desde Search Console si el sitio fue marcado como peligroso.

¿WP-Cron es un vector de ataque real o solo teórico?

Es real. CVE-2023-22622 documenta su uso para generar carga de servidor (DoS). Pero lo más grave es que los atacantes lo usan para registrar tareas maliciosas recurrentes. La mitigación: define('DISABLE_WP_CRON', true); en wp-config.php + cron job real del servidor.

¿Qué es Monarx y cómo me afecta?

Monarx es un malware self-healing documentado masivamente en mayo 2026. Se reinstala automáticamente si lo eliminás, contactando un C2 cada 6 minutos para recibir instrucciones. La única forma de limpiarlo es desactivar wp-cron (el vector de reinfección) y restaurar desde backup limpio.

¿Mi hosting afecta el riesgo de ser hackeado?

Sí, parcialmente. Hosting compartido donde múltiples clientes comparten servidor eleva el riesgo. Una cuenta comprometida puede comprometer otras. Hosting aislado por cuenta (como oferece Donweb) reduce este riesgo porque cada cliente tiene su entorno separado.

Conclusión

El secuestro de WordPress por vulnerabilidad de plugin no es un problema de nicho: CVE-2024-10924 por sí solo expuso 4 millones de instalaciones. La velocidad de explotación después de la divulgación pública se mide en horas, no en días, y los bots no distinguen entre sitios grandes y pequeños.

Lo que cambió es la automatización: los atacantes tienen templates listos para cada CVE nuevo y escanean internet de forma masiva. La asimetría es brutal: ellos automatizan el ataque, vos tenés que actualizar manualmente cada plugin.

La respuesta práctica es reducir esa asimetría: actualizaciones automáticas, monitoreo con alertas reales, backups probados y 2FA para admins. No es garantía absoluta, pero sube el costo del ataque al punto donde los bots automatizados pasan al siguiente sitio de la lista.

Si tenés Post SMTP, Really Simple Security, GiveWP o TranslatePress instalados: actualizá ahora, antes de seguir leyendo. La ventana de seguridad está cerrada.

Fuentes

• Wordfence — CVE-2025-11833: Account Takeover en Post SMTP (400K sitios)
• Patchstack — Q1 2025: Vulnerabilidades WordPress más explotadas
• SecurityWeek — CVE-2024-10924: Falla crítica expuso 4 millones de sitios WordPress
• Bitdefender — CVE-2024-8353: GiveWP object injection afecta 100K+ sitios
• Dark Reading — Malware Monarx: self-healing WordPress infections (mayo 2026)
• NVD (National Vulnerability Database) — Detalles técnicos de CVEs listados
• TechRadar — Campaña StopAndProtect: WordPress como infraestructura C2 (agosto 2026)