El 2 de noviembre de 1988, Internet tenía unos 60.000 ordenadores conectados en todo el mundo — apenas una fracción de un solo edificio de oficinas hoy. Esa noche, sin que nadie lo hubiera planeado, alrededor del 10% de esa red entera dejó de funcionar. No fue un fallo de hardware ni un apagón. Fue un programa de menos de 100 líneas escrito por un estudiante de posgrado que solo quería medir cuánta gente había realmente conectada.
Un experimento, no un ataque
Robert Tappan Morris tenía 23 años y estudiaba en Cornell cuando escribió lo que hoy conocemos como el «gusano Morris». Su intención, según él mismo explicó después, no era destructiva: quería crear un programa que se copiara a sí mismo de ordenador en ordenador a través de la red, sin hacer nada dañino, solo para estimar el tamaño real de Internet.
Para propagarse, el programa aprovechaba tres fallos ya conocidos en la época:
- Un modo de depuración olvidado activado en
sendmail, el programa que gestionaba el correo electrónico en la mayoría de los servidores Unix. - Un desbordamiento de búfer en el comando
finger, que permitía ejecutar código arbitrario enviando una entrada más larga de lo esperado. - Contraseñas débiles o reutilizadas, que el gusano probaba a fuerza bruta contra una lista corta de las más comunes.
Ninguno de estos tres fallos era un secreto. Los administradores de sistemas los conocían. Simplemente nadie pensó que alguien se molestaría en encadenarlos los tres a la vez, a esa escala.
El error que lo convirtió en un desastre
Aquí está la parte que casi nadie recuerda: Morris SÍ había pensado en evitar el caos. El gusano comprobaba si una máquina ya estaba infectada antes de intentar infectarla de nuevo, para no saturarla con copias duplicadas de sí mismo.
El problema es que Morris temió que los administradores pudieran hacer que sus sistemas «mintieran» diciendo que ya estaban infectados, como truco para librarse del gusano. Así que añadió una regla: incluso si una máquina decía estar ya infectada, el programa se reinstalaba de todos modos 1 de cada 7 veces, «por si acaso».
Esa única decisión — pensada como una medida de seguridad — fue la que lo rompió todo. En redes con muchas máquinas conectadas entre sí, la misma máquina podía recibir el gusano una y otra vez desde decenas de vecinos distintos. Cada reinfección lanzaba otro proceso, que consumía más memoria y CPU, hasta que los ordenadores simplemente dejaban de responder. No fue un ataque de denegación de servicio intencionado: fue una fuga de recursos causada por una salvaguarda mal calibrada.
Lo que vino después
El daño se estimó, según las fuentes, entre 100.000 y 10 millones de dólares en horas de trabajo perdidas limpiando sistemas en universidades, laboratorios militares y centros de investigación de todo Estados Unidos. Morris se convirtió en la primera persona condenada bajo la recién estrenada Computer Fraud and Abuse Act de EE. UU. Y como consecuencia directa del incidente, DARPA financió la creación del primer CERT (Computer Emergency Response Team) de la historia, en la Universidad Carnegie Mellon — el modelo que hoy siguen prácticamente todos los equipos de respuesta a incidentes del mundo.
¿Y qué tiene esto que ver con tu WordPress?
Más de lo que parece. Tres cosas no han cambiado en 35 años:
- Los fallos conocidos siguen siendo el vector número uno. El gusano Morris no usó ninguna vulnerabilidad secreta — usó fallos publicados que nadie había parcheado a tiempo. Hoy, la inmensa mayoría de los WordPress comprometidos lo son por plugins desactualizados con CVEs ya publicados, no por técnicas exóticas.
- La escala automatizada es la norma, no la excepción. En 1988 hacía falta escribir un programa a mano para propagarse por miles de máquinas. Hoy, cualquiera puede lanzar un escáner que sondea millones de sitios WordPress en busca de la misma vulnerabilidad, sin escribir una sola línea de código.
- Hasta el software bien intencionado puede hacer daño si nadie lo vigila. Morris no quería tumbar Internet. Su propio código, sin supervisión, se le fue de las manos por un detalle que parecía razonable sobre el papel.
La lección de 1988 sigue siendo la misma que en 2026: la única defensa real contra fallos conocidos y escaneo automatizado es que algo — o alguien — esté vigilando de forma constante, sin descanso, porque el otro lado tampoco descansa. Por eso existen hoy los firewalls de aplicación, los sistemas de bloqueo automático de IPs y el monitoreo en tiempo real: no reemplazan la vigilancia humana, la hacen posible a la escala que Internet exige desde aquella noche de noviembre de 1988.