In 1985, a software race condition in a radiation therapy device called the Therac-25 began silently killing cancer patients — delivering radiation doses up to 100 times the therapeutic level. Six patients were overdosed. At least three died. The root causes were not exotic: reused code, removed hardware interlocks, a single unreviewed programmer, and a manufacturer so confident in their software that they dismissed every patient complaint for nineteen months.
Nearly four decades later, the healthcare sector is deploying millions of connected medical devices — insulin pumps, infusion systems, patient monitors, and implantables — many of which repeat every structural failure the Therac-25 made famous. Software-only safety controls. Legacy firmware reused without re-testing. Security alert fatigue. Vendor overconfidence.
Sean Satterlee, Senior Principal Penetration Tester at Device Recon Labs, walked CYBR.HAK.CON attendees through how the industry got here and why the next Therac-25 may already be deployed. His presentation, “Ghosts in the Machine: The Therac-25 Affair,” was not simply a history lesson. It was a warning about the modern collision of cybersecurity, embedded systems, healthcare infrastructure, and patient safety.
When a Medical Device Became a Weapon
The Therac-25 was introduced in 1982 as AECL’s flagship linear accelerator, designed to deliver radiation therapy through both X-ray and electron beam modes. Unlike earlier models, however, the Therac-25 removed hardware safety interlocks and relied heavily on software controls.
That decision proved catastrophic.
Between 1985 and 1987, six known radiation overdoses occurred across North America. In some cases, patients received doses estimated at 100 times the intended therapeutic level.
Satterlee walked attendees through several of the most infamous incidents, including the case of Ray Cox in Tyler, Texas. Cox arrived for what should have been a routine treatment for a tumor near his spine. Instead, after a race condition was triggered during data entry, the machine delivered a massive overdose of radiation.
Cox reportedly saw a blue flash and screamed in pain. Because the intercom and monitoring systems were malfunctioning, the technician could not hear him clearly and activated the beam a second time. Hospital staff later told him the event was “all in his head.” He died months later from complications linked to the overdose.
The machine displayed only a cryptic error code: “Malfunction 54.”
More from CYBR.HAK.CON:
Bill Brenner
Bill Brenner
Two Bugs. Nineteen Months. Multiple Deaths.
Satterlee broke the Therac-25 failures into two core software defects: a race condition and an integer overflow vulnerability.
The race condition occurred when operators rapidly edited treatment settings. Internal software tasks fell out of synchronization, allowing the machine to fire a high-powered electron beam without the beam-flattening hardware properly positioned.
The second issue involved a one-byte counter variable called “Class3.” Every 256th increment caused the counter to roll over to zero — the same value the software used to indicate the system was ready for treatment. If timing aligned in exactly the wrong way, the machine bypassed safety checks entirely.
Compounding those technical flaws were organizational failures that now feel painfully familiar to modern cybersecurity professionals. Hardware interlocks had been removed to save cost and complexity. More than 50% of the codebase had been reused from earlier Therac systems without proper regression testing. The software itself was written by a single programmer in PDP-11 assembly and was never independently reviewed.
Most damningly, AECL repeatedly dismissed reports from hospitals and patients, insisting overdoses were impossible even after multiple incidents had already occurred.
Why the Story Still Matters
The presentation’s most unsettling point was that Therac-25 was not a bizarre historical anomaly. It was an early preview of problems healthcare still struggles with today.
Satterlee drew direct parallels between Therac-era failures and modern medical device ecosystems. Software-only safety controls now appear in connected insulin pumps and infusion systems. Legacy firmware and RTOS platforms are routinely reused across device generations. Security alerts are often suppressed because clinicians already suffer from overwhelming alert fatigue. Vendors continue making questionable “air gap” claims about devices that still use Bluetooth, Wi-Fi, NFC, or LTE communications.
Meanwhile, the attack surface surrounding modern healthcare devices has exploded.
Today’s medical device ecosystems include mobile companion applications, cloud backends, wireless radios, APIs, embedded operating systems, EHR integrations, and remote telemetry platforms. Every one of those components introduces additional pathways for compromise.
The numbers reflect the scale of the problem. According to statistics highlighted during the presentation, 83% of healthcare organizations experienced a cyberattack in the past year, more than 1,300 medical device CVEs were published in 2023 alone, and 53% of connected medical devices still run unsupported operating systems.
In other words, the industry has dramatically increased connectivity while still struggling with many of the same structural weaknesses that helped create the Therac-25 disaster.
Testing Like an Adversary
One of the presentation’s strongest sections focused on how healthcare organizations and manufacturers must rethink testing methodologies.
Satterlee argued that modern medical device security requires full adversarial testing, not checkbox compliance. That includes firmware extraction, binary analysis, fuzzing, wireless testing, API abuse scenarios, replay attacks, privilege escalation attempts, and clinical environment simulations.
Importantly, he stressed that race conditions and timing-dependent failures like those found in Therac-25 are exactly the types of bugs traditional QA processes often miss. Those flaws typically surface only under stress testing, malformed inputs, or adversarial simulation.
His warning was blunt: never trust the phrase “we couldn’t reproduce it.”
The FDA has evolved significantly since the 1980s, particularly with modern Secure Product Development Framework (SPDF) guidance and new requirements surrounding threat modeling, SBOMs, coordinated disclosure, and independent testing. But Satterlee made clear that regulation alone cannot solve the problem if organizations continue treating security as secondary to feature velocity, convenience, or cost savings.
The Next Therac-25
Satterlee closed with a message that landed hard in a room full of hackers and security professionals: Therac-25 was not a freak accident. It was the predictable outcome of systemic failures that still exist today.
The industry’s challenge is no longer theoretical. Connected healthcare devices now operate inside cloud-connected ecosystems with exponentially larger attack surfaces and significantly more sophisticated adversaries.
Which means the real question is no longer whether another Therac-25-style failure is possible.
The question is whether defenders identify it before patients do.
