25 crazy software bugs explained

A single line of bad logic can turn everyday software into real-world catastrophe—whether that means freezing a music player, wiping out millions in trading losses, or killing people in flight. Across 25 infamous bugs, the through-line is clear: small mistakes in assumptions, data handling, timing, or unit conversions can cascade into failures that are expensive, dangerous, or both.

The tour begins with “feature” bugs that start as harmless quirks in games and consumer devices. In Sid Meier’s Civilization, Gandhi’s aggression value is treated as an unsigned integer; when diplomacy reduces it, underflow wraps the value around to a maximum, flipping a pacifist into a “diabolical thermonuclear enthusiast.” Players embraced the chaos enough that it effectively became lore. Real systems were less forgiving. Microsoft’s Zoom knockoff froze on New Year’s Eve because leap-year day counting wasn’t handled correctly, trapping the device in a loop until someone removed the battery. On Intel Pentium chips, the infamous fdiv bug produced incorrect floating-point division results due to a flawed SRT division approach with missing lookup-table entries—rare in occurrence but serious enough to trigger major PR fallout.

As the list moves into higher-stakes failures, the consequences scale quickly. A FaceTime group-call exploit on iPhone allowed an attacker to trigger audio behavior and, after dismissing the call, activate the recipient’s camera—discovered by a 14-year-old and eventually patched after it went viral. In finance, a 2024 Chase ATM glitch let people withdraw large sums immediately after depositing fake checks, leading to lawsuits and potential criminal charges. Other failures weren’t about fraud but about brittle systems: an AT&T long-distance crash in 1990 cascaded from one faulty switch rebooting neighboring switches, blocking 50 million calls. At airports, Heathrow Terminal 5’s baggage system suffered a breakdown when multiple software systems failed to coordinate, causing 500+ canceled flights, 42,000 lost bags, and a $16 million fix.

The most dramatic disasters come from unit mistakes, timing errors, and security oversights. NASA’s Mars Climate Orbiter burned up after one team used imperial units while another used metric, breaking the mission’s calculations. An Ariane 5 rocket exploded in 1996 after a conversion error turned a 64-bit floating-point value into a 16-bit integer, sending the vehicle 90° off course. Heartbleed in 2014 exposed servers running vulnerable OpenSSL implementations through a missing bounds check in the TLS heartbeat extension, letting attackers repeatedly request memory contents—leaving roughly two-thirds of internet servers at risk.

The final stretch turns deadly. Toyota’s electronic throttle control and braking logic issues led to recalls, injuries, and deaths. In aviation and defense, software misbehavior contributed to crashes and combat tragedies: a Patriot missile timing overflow killed 28 U.S. soldiers; an Aegis system display and timing lag helped lead to a civilian plane being shot down; and the Boeing 737 MAX disasters tied back to flawed sensor logic in the Maneuvering Characteristics Augmentation System. Even medical devices weren’t safe: the Therac-25 radiation machine delivered lethal doses due to race conditions and the removal of mechanical interlocks.

The common lesson is less about “bugs happen” and more about how assumptions fail under real conditions—leap years, edge-case inputs, overflow, concurrency, inconsistent sensors, and mismatched units. The stakes rise when software controls money, infrastructure, aircraft, or human bodies, making testing, validation, and defensive design non-negotiable.