On November 2, 1988, the entire Internet consisted of roughly 60,000 connected computers worldwide — barely a fraction of what a single office building runs today. That night, without anyone planning it, about 10% of that entire network stopped working. It wasn’t a hardware failure or a blackout. It was a program under 100 lines long, written by a graduate student who just wanted to measure how many machines were really out there.
An experiment, not an attack
Robert Tappan Morris was 23 and studying at Cornell when he wrote what we now know as the “Morris Worm.” His intent, as he later explained, wasn’t destructive: he wanted a program that would copy itself from machine to machine across the network without doing any harm, purely to estimate the real size of the Internet.
To spread, the program exploited three flaws that were already known at the time:
- A forgotten debug mode left enabled in
sendmail, the program handling email on most Unix servers. - A buffer overflow in the
fingercommand, which allowed arbitrary code execution by sending input longer than expected. - Weak or reused passwords, which the worm brute-forced against a short list of common ones.
None of these three flaws was a secret. System administrators knew about them. Nobody just expected someone would bother chaining all three together at that scale.
The bug that turned it into a disaster
Here’s the part almost nobody remembers: Morris had actually tried to prevent chaos. The worm checked whether a machine was already infected before infecting it again, so it wouldn’t overload it with duplicate copies of itself.
The problem is that Morris worried administrators might make their systems “lie” and claim to already be infected, as a trick to shake off the worm. So he added a rule: even if a machine claimed to be infected already, the program would reinstall itself anyway 1 out of every 7 times, “just in case.”
That single decision — meant as a safeguard — is what broke everything. On networks with many interconnected machines, the same machine could receive the worm over and over from dozens of different neighbors. Each reinfection spawned another process, eating more memory and CPU, until computers simply stopped responding. It wasn’t an intentional denial-of-service attack: it was a resource leak caused by a poorly calibrated safety measure.
What came after
Damages were estimated, depending on the source, at somewhere between $100,000 and $10 million in lost work hours cleaning up systems at universities, military labs, and research centers across the United States. Morris became the first person ever convicted under the newly enacted U.S. Computer Fraud and Abuse Act. And as a direct result of the incident, DARPA funded the creation of the world’s first CERT (Computer Emergency Response Team) at Carnegie Mellon University — the model that nearly every incident response team in the world still follows today.
So what does this have to do with your WordPress site?
More than you’d think. Three things haven’t changed in 35 years:
- Known flaws are still attack vector number one. The Morris Worm didn’t use any secret vulnerability — it used published flaws nobody had patched in time. Today, the vast majority of compromised WordPress sites are hit through outdated plugins with already-published CVEs, not exotic techniques.
- Automated scale is the norm, not the exception. In 1988, someone had to hand-write a program to spread across thousands of machines. Today, anyone can run a scanner that probes millions of WordPress sites for the same vulnerability without writing a single line of code.
- Even well-intentioned software can cause harm if nobody’s watching it. Morris didn’t want to bring down the Internet. His own code, left unsupervised, got away from him because of a detail that seemed reasonable on paper.
The lesson from 1988 is still the same one in 2026: the only real defense against known flaws and automated scanning is having something — or someone — watching constantly, without rest, because the other side never rests either. That’s exactly why application firewalls, automatic IP blocking systems, and real-time monitoring exist today: they don’t replace human vigilance, they make it possible at the scale the Internet has demanded ever since that November night in 1988.