Why “the first” is a trap
Ask who wrote the first computer virus and you will hear several answers, all defensible. The answer depends on what counts as a virus. Does the program have to copy itself? Spread between machines? Attach itself to other programs? Cause harm? Different early programs meet different parts of that definition, so any single “first” is a judgment call. What follows is a cautionary story about several early experiments, and how the line between a curiosity and a problem turned out to be thinner than their authors expected.
An experiment on a research network
One of the earliest self-spreading programs people point to is called Creeper. It is usually dated to the early 1970s and linked to engineers at the research firm BBN, which helped build the ARPANET. As commonly told, Creeper moved from one machine to another on that network and displayed a message along the lines of “I’m the creeper, catch me if you can.” A companion program named Reaper was then written to travel the network and remove it.
Accounts differ on details, such as exactly how Creeper moved, whether it copied itself or simply relocated, and who deserves credit. It is best understood as a demonstration of mobile code, not as malicious software. Nobody was trying to damage anything, and the network was small, with a community of researchers who largely knew one another. That trust is part of the cautionary tale. Systems designed for a friendly community were not designed for strangers who might misuse them.
From idea to nuisance
Over the following years, the idea moved from research labs toward ordinary computers. The 1980s brought programs that spread on floppy disks among personal computers, which are covered in the separate article on the idea of self-replicating programs. The important lesson from that period was less technical than social: a program written as a prank or a test could spread well beyond its author’s intentions once other people copied disks and shared software.
A worm that got out of hand
The best-known early cautionary case is the Morris worm of November 1988. It was written by Robert Tappan Morris, then a graduate student, and released onto the internet. Its author later said the goal was to gauge the size of the network, not to cause damage. The program exploited known weaknesses in widely used Unix-based systems and guessed passwords, then tried to spread to other machines.
The trouble was a design mistake: the worm could reinfect machines that already had it, and so copies piled up, slowing many systems until they became hard to use. Administrators at universities and research sites worked for days to clean up. Estimates of how many machines were affected vary between sources, so it is safest to say that a significant fraction of the then-small internet was disrupted.
The aftermath had lasting effects.
- The incident led to the creation of a computer emergency response team at Carnegie Mellon University to help coordinate responses to future problems.
- Morris was prosecuted under the Computer Fraud and Abuse Act, among the early well-known cases under that law.
- System administrators began to take patching and password quality more seriously.
- The episode became a standard teaching example about how a small coding error can scale into a large incident.
Worms in the email era
A similar pattern recurred in the 1990s as email and the web connected ordinary users. Macro viruses in office documents and mass-mailing worms such as Melissa in 1999 spread by exploiting both software features and human curiosity. People opened attachments because they seemed to come from friends. Technical defenses improved, but each wave showed that a program only needs to persuade a few people to run it, and then the rest of its reach is automatic.
What the cautionary tale teaches
Several lessons hold across the decades, and none depends on a particular “first” program.
- Self-copying code is hard to recall. Once a program replicates beyond its author’s control, good intentions do not matter. Even experiments need a plan for stopping them.
- Small bugs scale. The Morris worm’s reinfection flaw would have been minor in a single program. Replication multiplied it.
- Trust is a design choice. Early networks assumed their users were friendly, and many protocols and services lacked basic protections as a result.
- People are part of the system. Many spreading programs have relied on curiosity, trust or hurry rather than on clever technical tricks.
- Responses can be organized. Coordination centers, shared advisories and prompt patching have limited later outbreaks, though they have never ended them.
A note on handling this history
Because the subject can sound like a how-to, a word of caution is appropriate. Writing or releasing self-spreading code is illegal in many places and can cause real harm to people who had no say in the matter. Researchers who study malware work in isolated laboratory environments for exactly that reason. The history is worth knowing because it explains why systems today update automatically, why operating systems separate user accounts from administrators, and why unexpected attachments deserve suspicion.
The earliest programs were experiments by curious people, and their creators did not foresee how far or how fast copies could travel. That surprise is the real heart of the story, and it explains how the broader field of computer security came to exist.