This morning, the screens no longer responded. In several university and military computer centers across the United States, network administrators discovered that their machines had frozen and were unable to execute any commands. No one immediately understood what was happening. Phones began ringing across buildings as administrators tried to figure out what was wrong. The symptoms were the same everywhere: an initial slowdown, followed by a complete blockage. The cause was a program that had been designed to count networked computers, but it had replicated uncontrollably in November 1988. The rate at which the program reinstalled itself was too high, leading to dozens of copies being created simultaneously on each machine. The lack of a central defense mechanism and standardized protocols made the network even more vulnerable, leading to widespread saturation. The program was not created to cause harm. It was written by an American student who wanted to estimate how many computers were connected to each other at the time. To spread, the program used known vulnerabilities that system administrators were already aware of. Once installed on a machine, it used that machine to reach out to the next one, and so on. The idea behind it did not suggest disaster. However, one design choice changed everything. To prevent an already infected machine from detecting the program and stopping further copies, the student planned for the program to reinstall itself on already affected systems. The rate chosen for these reinstallation attempts was far too high. Each machine ended up running dozens of copies of the program at the same time, each trying to spread further. This caused an immediate saturation of the network. The network of the late 1980s was not designed to handle such a sudden surge. The computers that made up the network operated on a principle of mutual trust, where each machine accepted connections from others without much suspicion. There was no central system monitoring for large-scale abnormal behavior, and no standardized procedures existed to quickly isolate a failing machine from the rest of the system. Faced with the silent multiplication of copies, administrators had no established protocol to follow—only their own judgment and improvised phone calls. Each discovered the problem on their side, unaware that other locations were experiencing the same issue at the same time. National-level coordination simply did not exist at the time. The outage marked a turning point in the history of network computing. In the months following the incident, specialized teams were created with the mission of responding to computer incidents as soon as they began. These incident response teams would later become a model adopted by many countries and institutions, far beyond the academic circles where it all started. What the student had imagined as a simple technical census became, without his intent, one of the starting points of organized cybersecurity as it is known today. The outage was not due to sabotage, but to a miscalibrated number in a line of code—a reminder that a global network can falter because of something as simple as a single, misplaced figure.