Tras los cambios solicitados a su informático, Sofía aprovechó el momento café, después del almuerzo, para revisar su sitio web. No eran cambios complejos ni una reforma profunda. Solo había pedido actualizar su currículum, publicado en su propia página profesional.

Sentada frente al portátil, tecleó las primeras letras de su dominio mientras saboreaba el primer sorbo de cafeína. Pero, pese a lo cotidiano de la escena, no ocurrió lo que esperaba.

Su sitio web no apareció.

En su lugar, una página publicitaria reclamaba su atención con banners insistentes, mensajes ajenos y llamadas a la acción que nada tenían que ver con su trabajo, su imagen ni su trayectoria. Aquella web, que hasta entonces había funcionado como un pequeño escaparate profesional, parecía haber sido sustituida por algo extraño. Algo intruso. Algo que no le pertenecía.

Así es como imagino aquel momento.

No porque Sofía me lo describiera exactamente con esas palabras, sino porque el aviso llegó el 20 de marzo de 2019, a las 14:18 horas, en forma de audio de WhatsApp. En el archivo de conversación exportado, el contenido del audio no aparece transcrito, pero sí queda registrado el momento y la respuesta posterior: minutos después, el problema estaba identificado y solucionado. En el chat quedó anotado que “se trataba de un plugin cuyo código había sido hackeado” y que bastó actualizarlo para dejar la web funcionando de nuevo.

No fue un ataque personal, fue una web vulnerable

Aquello no era una avería corriente. Tampoco era, como muchas personas podrían imaginar en un primer impulso, un ataque dirigido personalmente contra Sofía. Su web no había sido elegida por ser suya. Simplemente, había sido encontrada.

Y esa diferencia es importante.

En seguridad web, muchas infecciones no empiezan con alguien sentado frente a varias pantallas buscando una víctima concreta. Empiezan con bots. Programas automatizados que recorren Internet buscando versiones vulnerables de plugins, temas o instalaciones mal mantenidas. No preguntan quién eres. No leen tu biografía. No valoran si tu web es grande, pequeña, famosa o recién nacida. Solo buscan una puerta mal cerrada.

Qué era Easy WP SMTP y por qué importaba

En este caso, todo apuntaba una vulnerabilidad de Easy WP SMTP, un plugin muy utilizado en WordPress para configurar el envío de correos desde el sitio web mediante servidores SMTP. En aquel momento, no era una herramienta marginal: Wordfence hablaba de más de 300.000 instalaciones activas cuando publicó su alerta sobre los ataques.

La vulnerabilidad afectaba a la versión 1.3.9 del plugin. El fallo permitía que un atacante no autenticado modificara opciones internas de WordPress. Dicho de forma menos técnica: alguien desde fuera podía alterar configuraciones delicadas del sitio sin tener usuario ni contraseña. En determinados escenarios, esa modificación podía facilitar la creación de usuarios administradores o la inyección de código malicioso.

La carrera entre el parche y los atacantes

La actualización correctiva, la versión 1.3.9.1, fue publicada el 17 de marzo de 2019. Pero en seguridad existe una carrera incómoda y silenciosa: cuando se publica un parche, los administradores deben aplicarlo cuanto antes; mientras tanto, los atacantes analizan qué se ha corregido y tratan de explotar el fallo antes de que miles de webs estén actualizadas. WPScan recoge precisamente que el cambio de la versión 1.3.9.1 corregía una vulnerabilidad relacionada con la importación y exportación de ajustes del plugin.

Wordfence avisó el 20 de marzo de 2019 de que los atacantes ya estaban abusando de esa vulnerabilidad recién parcheada. Sucuri, al día siguiente, describió el caso como una vulnerabilidad crítica explotada en sitios reales y explicó que podía desembocar en el compromiso completo de la web afectada.

Ese mismo 20 de marzo, Sofía me avisó.

La primera medida: copia de seguridad antes de tocar nada

La primera decisión pasó por no tocar nada a ciegas. Antes de intervenir, realicé una copia de seguridad del sitio web. Cuando una web muestra signos de infección, la tentación puede ser entrar corriendo a borrar archivos como quien apaga un fuego con las manos. Pero conviene conservar una copia del estado inicial, porque puede servir para analizar qué ha pasado, recuperar datos o reconstruir el incidente si algo sale mal durante la limpieza.

Después accedí al alojamiento y contacté con el servicio técnico. Fueron ellos quienes me pusieron sobre la pista de Easy WP SMTP. La vulnerabilidad ya era conocida, se estaba comentando en el ecosistema WordPress y los ataques habían empezado a multiplicarse. No era un caso aislado. Era una oleada.

La solución inmediata: actualizar el plugin

La solución inmediata fue tan sencilla como urgente: actualizar el plugin.

Y funcionó.

A las 14:39 escribí a Sofía para decirle que ya estaba arreglado. Un minuto después le expliqué que el origen había sido un plugin cuyo código había sido comprometido y que la nueva versión había solucionado el problema.

Pero cerrar la puerta después de encontrarla forzada no significa que la casa esté protegida.

Después del incidente: reforzar la seguridad

Por eso, tras resolver el incidente, decidí instalar un plugin de seguridad para WordPress. La idea era vigilar accesos no autorizados, añadir medidas de protección adicionales y tener más visibilidad sobre lo que estaba ocurriendo alrededor del sitio web. Se lo comuniqué a Sofía ese mismo día, explicándole que el sistema ayudaría a controlar posibles accesos indebidos y reforzaría la seguridad general.

Ese movimiento abrió otra historia: la de los intentos de acceso por fuerza bruta.

Porque cuando se instala un sistema de seguridad y empiezan a llegar notificaciones, muchos clientes descubren algo incómodo: los ataques no siempre son excepcionales. A veces estaban ocurriendo todo el tiempo, solo que nadie los estaba mirando.

Pero ese será otro expediente.

La lección del caso Easy WP SMTP

El caso de Easy WP SMTP deja una enseñanza muy clara: WordPress no es inseguro por naturaleza, pero su seguridad depende de todo lo que se instala sobre él. El núcleo de WordPress puede estar actualizado y bien mantenido, pero un plugin vulnerable puede convertirse en una rendija suficiente para que entren scripts, redirecciones, usuarios fantasma o campañas de spam.

La web de Sofía no cayó porque fuera especialmente valiosa para un ciberdelincuente. Cayó porque formaba parte de un ecosistema enorme, popular y constantemente rastreado por bots. Y esa es precisamente la realidad que muchos propietarios de sitios web desconocen: una página pequeña también puede ser atacada, no por su fama, sino por su versión.

Los ciberdelincuentes no siempre buscan nombres. Muchas veces buscan números de versión.

Por eso, mantener una web en WordPress no consiste solo en publicar contenido, cambiar una foto o renovar el dominio una vez al año. También implica revisar plugins, aplicar actualizaciones, hacer copias de seguridad, controlar accesos y entender que cada componente externo añade funcionalidad, sí, pero también responsabilidad.

Aquel día, por suerte, el daño fue reversible. Una actualización bastó para recuperar la normalidad. Pero el aviso quedó ahí, como una nota pegada en la puerta del servidor: incluso una web tranquila, personal y aparentemente inocente puede verse arrastrada por una campaña global de explotación automática.

No era una película de hackers. Era WordPress, marzo de 2019, un plugin vulnerable y una taza de café interrumpida por una página publicitaria.