The biggest vulnerabilities

From Code Red to PHP2Shell: the vulnerabilities that changed IT security, with severity, timeline from report to attack, and the figures.

Cases
20
Rated critical
8
Attacks on industrial control systems
10

Vulnerabilities

2026PHP2Shell: the flaws in PHP that put most websites at riskTwo flaws in PHP itself let attackers take over web servers without a password. The fixed PHP versions, the applications affected, and what to do now. 2023MOVEit: the file transfer flaw that Cl0p used to steal dataA flaw in the file transfer server MOVEit Transfer let the Cl0p gang steal data from 2,773 organizations. How it worked, who was hit, and what to do now. 2021Log4Shell: when a line in a log runs the attacker's codeA flaw in Log4j, a logging library for Java, let attackers take over servers with one line of text. How it worked, how far it reached, what to do now. 2021ProxyLogon: the Exchange flaws that opened mail serversFour flaws in Microsoft Exchange let attackers read mailboxes and take over mail servers without a password. How it worked, who was hit, what to do now. 2019Citrix ADC: the gateway flaw that opened internal networksIn December 2019, a flaw in Citrix's remote access gateways let attackers in without a password, with no fix for 33 days. How it worked, who was hit. 2019Exim: the email address that took over mail serversIn 2019, a flaw in the Exim mail server let attackers run commands as root by hiding them in an email address. How it worked, the worm, the fix. 2018MikroTik Winbox: the flaw that gave away router passwordsA 2018 flaw let attackers copy the passwords of MikroTik routers. Four months after the fix, 370,000 were still open and over 200,000 had been hijacked. 2018Spectre: when the speed tricks of processors leak secretsA design flaw in processors from Intel, AMD and Arm let programs read memory they should never see. How it works, what the fixes cost, and what to do now. 2018Meltdown: the processor flaw that opened protected memoryA design flaw in most Intel processors let any program read the operating system's protected memory. Why it scores only 5.6, and how the fix works. 2017NotPetya: the destructive worm hidden in a software updateA hijacked update of a Ukrainian accounting program released a worm that posed as ransomware, destroyed data and caused billions of dollars in damage. 2017WannaCry: the ransomware worm that hit the NHSA worm used a leaked NSA attack tool and a Windows flaw to lock more than 200,000 computers. How it spread, what it cost the NHS, and the fix. 2014Shellshock: the Bash flaw that let one web request run commandsA flaw in Bash, the command shell of Linux and macOS, let attackers run commands on web servers with one request. How it worked, the attacks, the fix. 2014Heartbleed: the flaw that let attackers read server memoryIn April 2014, an OpenSSL flaw let attackers read the memory of 24–55 % of popular HTTPS servers. How it worked and why patching alone was not enough. 2014NTP monlist: how time servers amplified DDoS attacksFrom December 2013, attackers abused a diagnostic command in NTP time servers to multiply their attack traffic. How it worked, and how the internet cleaned up. 2008Conficker: the worm that infected millions of Windows computersWithin a year of November 2008, Conficker infected 5 to 13 million Windows computers. How it spread and how over 100 countries joined the defense. 2008Kaminsky DNS flaw: the trick that could hijack any domainIn July 2008, a DNS flaw let attackers plant false addresses for any domain within seconds. How it worked and how vendors fixed it on a single day. 2003Blaster: the worm that hit 100,000 Windows PCs in a weekIn August 2003, the Blaster worm infected more than 100,000 Windows computers in its first week. How it spread, why it attacked Microsoft and why it stayed. 2003SQL Slammer: the worm that hit 90 % of its targets in 10 minutesIn January 2003, a worm of just 376 bytes infected more than 90 % of vulnerable Microsoft SQL servers within 10 minutes. How it spread, and what it hit. 2001Nimda: the worm that infected 160,000 computers in 7 hoursIn September 2001, the Nimda worm spread by e-mail, infected websites and attacks on web servers at once. Within 7 hours, 160,000 computers were infected. 2001Code Red: the worm that infected 359,000 servers within 14 hoursIn July 2001, the Code Red worm infected more than 359,000 computers running Microsoft's web server in under 14 hours, a month after the fix came out.

The cases and the criteria they meet

NameYearCVSSReachMass exploitationDamageExtraordinary response
Code Red200110.0 met met metnot met
Nimda20017.5 met metnot metnot met
SQL Slammer20037.5not met met metnot met
Blaster20037.5 met metnot met met
Kaminsky DNS20086.8 metnot metnot met met
Conficker200810.0 met metnot met met
NTP monlist20145.0 met metnot met met
Heartbleed20147.5 metnot metnot met met
Shellshock20149.8 met metnot metnot met
WannaCry20178.8 met met met met
NotPetya20178.8not met met metnot met
Meltdown20185.6 metnot metnot met met
Spectre20185.6 metnot metnot met met
MikroTik Winbox20189.1 met metnot metnot met
Exim20199.8 met metnot metnot met
Citrix ADC20199.8 met met met met
ProxyLogon20219.8 met metnot met met
Log4Shell202110.0not met metnot met met
MOVEit Transfer20239.8not met met metnot met
PHP2Shell20269.8 metnot metnot met met
Severity score of the main CVE
Code Red10.0
Conficker10.0
Log4Shell10.0
Shellshock9.8
Exim9.8
Citrix ADC9.8
ProxyLogon9.8
MOVEit Transfer9.8
PHP2Shell9.8
MikroTik Winbox9.1
WannaCry8.8
NotPetya8.8
Nimda7.5
SQL Slammer7.5
Blaster7.5
Heartbleed7.5
Kaminsky DNS6.8
Meltdown5.6
Spectre5.6
NTP monlist5.0

CVSS base scores from the US National Vulnerability Database. Older entries carry version 2 scores, which use a different scale.

Every case from 2000 to 2026

VulnerabilitiesAttacks on industrial control systems

200020052010201520202025Code RedNimdaSQL SlammerBlasterKaminsky DNSConfickerNTP monlistHeartbleedShellshockWannaCryNotPetyaMeltdownSpectreMikroTik WinboxEximCitrix ADCProxyLogonLog4ShellMOVEit TransferPHP2ShellStuxnetHavexBlackEnergyIndustroyerTRISISEKANSIndustroyer2PIPEDREAMFuxnetFrostyGoop

Attacks on industrial control systems

Attacks that reached industrial control systems, documented in public technical analyses: what happened, how the attackers got in, and what it did to the process.

2024Destruction

Fuxnet

sensor gateways bricked — Claroty's estimate (attackers claimed about 1,700)
500+
sensors the attackers claimed destroyed; Claroty believes they likely survived
87,000

In April 2024 a group calling itself Blackjack said it had wrecked Moscollector. The Moscow company monitors the city’s underground water and sewage network. The malware, which the attackers called Fuxnet, ran on the network’s sensor gateways. These small Linux computers gather readings from thousands of underground sensors over a serial standard called M-Bus. On each gateway it cut off remote access, deleted parts of the file system, and rewrote the flash memory until it failed.

It also flooded the M-Bus wiring with junk, hoping to damage the sensors too. How Blackjack first got in is not documented. The group claimed access since June 2023. The attackers claimed 87,000 destroyed sensors and 30 terabytes wiped. The security firm Claroty analyzed the malware and the leaked data. It estimates that only a little over 500 gateways were bricked and that the sensors likely survived. Claroty reports that Blackjack is believed to be linked to Ukrainian intelligence. No government has confirmed this.

Names
Fuxnet (Blackjack)
Target
Moscollector, a Moscow company that monitors underground water and sewage infrastructure
Attributed to
Blackjack (Claroty reports Blackjack as believed linked to Ukrainian intelligence; no government has confirmed this)
Way in
Not public
Protocols
M-Bus
Systems attacked
Linux sensor gateways (MPSB and TMSB) and a 3G router, linked to sensors over the M-Bus serial protocol

2024Disruption

FrostyGoop / BUSTLEBERM

apartment buildings left without heating (Dragos)
600+
that the heating stayed off, in sub-zero cold (Dragos)
~2 days

In January 2024, during a sub-zero winter, more than 600 apartment buildings in a Ukrainian city lost heating for almost two days. According to Dragos, the city was Lviv. The malware behind the outage, later named FrostyGoop, is a small program that talks to heating controllers over Modbus TCP. This plain, widely used protocol sends commands on port 502, usually without a password. FrostyGoop read and changed the controllers’ holding registers, the memory slots that hold their settings. It also downgraded their software so they could no longer report their status.

That left operators without a clear view while the controllers ran on wrong information. Dragos reconstructs the likely entry. Months earlier, the attackers exploited a flaw in an internet-facing router, planted a web tunnel reached over Tor, and stole Windows credentials. The network was flat, with nothing separating the controllers, so they could be reached directly. Dragos does not attribute the attack. It notes only connections to Moscow-based addresses during the incident.

Names
FrostyGoop (Dragos), BUSTLEBERM (Mandiant)
Target
A district heating company in Lviv, Ukraine
Attributed to
Not attributed (Dragos saw connections to Moscow-based addresses but does not attribute the attack)
Way in
Internet-facing router, Stolen credentials
Protocols
Modbus TCP
Systems attacked
ENCO heating controllers, reached over Modbus TCP on port 502

2022Disruption

Industroyer2

power outages — the attack was stopped in time (CERT-UA)
0
industrial protocol it used, down from four in the 2016 version (ESET)
1

On April 8, 2022, the group Sandworm tried to switch off part of Ukraine’s power grid. Its tool, named Industroyer2 by the security firm ESET, was a stripped-down successor to the Industroyer malware from 2016. It spoke only one industrial protocol, IEC 104. The target substations’ addresses and switching commands sat inside the program itself, so it was built for one specific utility. Separate ‘wiper’ malware was lined up to destroy the utility’s Windows, Linux and Solaris servers at the same time.

How the attackers first entered is not public, but they already held administrator access. They pushed the malware out through Windows Group Policy and set a scheduled task to run it that evening. CERT-UA, Ukraine’s incident team, says the network had been compromised since at least February 2022. It also says the plan was stopped in time and no outage occurred. CERT-UA attributes the attack to Sandworm (UAC-0082); ESET assesses this with high confidence.

Names
Industroyer2 (ESET), INDUSTROYER.V2 (Mandiant)
Target
A Ukrainian electricity utility; its high-voltage substations
Attributed to
Sandworm (CERT-UA attributes it to Sandworm (UAC-0082); ESET assesses this with high confidence)
Way in
Not public
Protocols
IEC 104
Systems attacked
High-voltage substation equipment, commanded over the IEC 104 protocol

2022Disruption

PIPEDREAM / INCONTROLLER

times it was used — the toolkit was found before any attack (Dragos)
0
the seventh known piece of ICS-specific malware, by Dragos's count
7

PIPEDREAM is a case with no victim. In early 2022 the security firms Dragos and Mandiant analyzed a complete attack toolkit. A state-backed group had built it to find and take over industrial controllers. Dragos called it PIPEDREAM, Mandiant INCONTROLLER. On April 13, 2022, four US agencies published a joint advisory, AA22-103A. By Dragos’s count it is the seventh known piece of ICS-specific malware, and the first found before an attack.

The toolkit is modular. Some parts get a foothold on Windows and gain deep access through a signed-but-flawed driver. Others speak the industrial protocols CODESYS, Modbus, OPC UA and Omron FINS to scan, log into, reprogram or crash controllers. It came with modules for Schneider Electric and Omron equipment. Dragos assesses with high confidence that a state built it and tracks the developer as CHERNOVITE. No country was named, and Mandiant called its links to Russia circumstantial.

Names
PIPEDREAM (Dragos), INCONTROLLER (Mandiant)
Target
No real victim; Dragos assessed likely targets as liquefied-natural-gas and electricity sites
Attributed to
CHERNOVITE (state-sponsored) (Dragos's name for the developer; no country has been named; Mandiant called links to Russia circumstantial)
Way in
Not public
Protocols
CODESYS, Modbus, OPC UA, Omron FINS
Systems attacked
Schneider Electric and Omron PLCs and servo drives, and any OPC UA server; via CODESYS, Modbus, OPC UA and Omron FINS

2020Ransomware

EKANS / Snake

Windows processes on the kill list, some of them industrial (FireEye)
1,000+
sectors Unit 42 named, from energy to healthcare
5

EKANS (the word ‘snake’ backwards) is ransomware that appeared in 2020. It runs on ordinary Windows computers, so it cannot reprogram the controllers that run machinery. Instead it goes after the Windows PCs operators use to watch and command a plant. These include the screens known as HMIs, the databases called historians, and license servers. Before encrypting their files, it stops a hard-coded list of programs so the files are no longer locked.

The security firm FireEye found that the list targets over 1,000 processes. Some of them are industrial software from vendors such as General Electric and Honeywell. EKANS also deletes the backup copies Windows keeps. How operators were first breached was never made public. EKANS is the payload dropped at the end. No group or state has been named. MITRE’s ATT&CK, citing press reports, links an EKANS infection to a temporary production loss at a Honda plant in June 2020.

Names
EKANS (Dragos), Snake
Target
Industrial organizations in several sectors, from energy to manufacturing (Unit 42)
Attributed to
Not attributed (Criminal ransomware; no government or security firm has named an operator)
Way in
Not public
Systems attacked
Windows PCs that run the control room — HMIs, historians and license servers — not the controllers themselves

2017Destruction

TRISIS / TRITON

that the targeted refinery was shut down (CISA)
several days
US electric utilities the same actors probed in 2019 (Treasury)
20

In 2017, attackers reached the safety system of a petrochemical plant in the Middle East. Its independent controllers are meant to force a process into a safe state before it turns dangerous. The malware, known as TRISIS or TRITON, was built for the plant’s Schneider Electric Triconex controllers. It spoke TriStation, their undocumented protocol, which the attackers had reverse-engineered. It wrote a hidden backdoor into a controller’s memory to alter its safety logic.

US agencies have not said how the attackers first broke in. Once inside, they reached the engineering workstation that programs the controllers and ran a tool disguised as the vendor’s own software. During the operation some controllers tripped and shut the plant down for several days, which is how the malware was found. In 2018 FireEye tied the intrusion to a Russian state institute, TsNIIKhM, with high confidence. The US sanctioned the institute in 2020. Dragos tracks the operator as XENOTIME.

Names
TRISIS (Dragos), TRITON (FireEye), HatMan (DHS NCCIC)
Target
A petrochemical plant in the Middle East (US agencies say only 'a foreign oil refinery')
Attributed to
TsNIIKhM (Russian state institute) (US sanctions name this institute; Dragos tracks the operator as XENOTIME; FireEye assessed it with high confidence)
Way in
Not public
Protocols
TriStation
Systems attacked
Schneider Electric Triconex safety controllers (a safety instrumented system, or SIS), via the undocumented TriStation protocol

2016Disruption

Industroyer / CRASHOVERRIDE

power cut to part of Kyiv (ESET)
~1 h
grid protocols the malware could speak
4

On December 17, 2016, part of Kyiv lost power for about an hour. The malware behind it, analyzed in 2017, was named Industroyer by ESET and CRASHOVERRIDE by Dragos. It was the first malware built to control grid equipment directly. Instead of a person clicking through remote-control tools, its own modules opened circuit breakers automatically. They spoke the grid’s standard protocols: IEC 60870-5-101, IEC 60870-5-104, IEC 61850 and OPC DA. How the attackers first got in was never established.

A launcher set off the payload at a chosen time. One to two hours later, a wiper destroyed files and settings to slow recovery. A separate tool could disable Siemens SIPROTEC protection relays. The US government attributes the attack to Sandworm (Russia’s GRU); Dragos tracks the operators as ELECTRUM. In 2017, ESET found no code overlap with BlackEnergy and did not attribute it.

Names
Industroyer (ESET), CRASHOVERRIDE (Dragos)
Target
A Ukrainian electrical transmission company; part of Kyiv lost power
Attributed to
Sandworm (GRU) (US government attribution; ESET did not attribute it in 2017)
Way in
Not public
Protocols
IEC 60870-5-101, IEC 60870-5-104, IEC 61850, OPC DA
Systems attacked
Substation breakers and relays, via the grid protocols IEC 60870-5-101/104, IEC 61850 and OPC DA

2015Disruption

BlackEnergy

customers lost power (US DHS)
225,000
to restore power by hand (INL)
~6 h

On December 23, 2015, three Ukrainian regional power companies lost control of their grids within about half an hour of each other. About 225,000 customers lost power (ESET counted around 230,000 people). It is the first blackout confirmed to have been caused by a cyberattack. Months earlier, spear-phishing emails with macro-laden Office files had planted the BlackEnergy malware on the office networks.

The attackers harvested credentials, then used the utilities’ own VPN and remote-control tools to reach the SCADA systems. There they opened breakers at more than 50 substations by hand. They disabled serial-to-Ethernet converters, wiped PCs with KillDisk, and flooded a call center. As a result, power had to be restored on site, which took about six hours. The US government later attributed the attack to Sandworm, a unit of Russia’s GRU.

Target
Three regional power distribution companies in Ukraine
Attributed to
Sandworm (GRU) (US government attribution; in early 2016 analysts could not yet name the operators)
Way in
Phishing email, Stolen credentials, VPN access
Systems attacked
SCADA control systems reached by remote-access tools; substation serial-to-Ethernet converters

2014Espionage

Havex

known victims worldwide (Kaspersky)
2,800+
victim organizations identified by name
101

Havex, made public in June 2014 and also tracked as Dragonfly or Energetic Bear, was a spying campaign against the energy sector. It reached victims three ways: phishing emails with booby-trapped PDF files, websites rigged to infect visitors, and, most notably, hacked download pages. At least three small makers of industrial software had their installers swapped for versions that also carried Havex. Kaspersky counted more than 2,800 victims worldwide.

Havex was a backdoor that called home and downloaded extra modules. One module searched the network for OPC servers, the Windows middleware that lets software read live data from many controllers. It copied their details back to the attackers. The scanning alone crashed some servers. Havex stole information but had no sabotage payload. In 2014 analysts disagreed on the source; in 2022 the US government attributed the campaign to Russia’s FSB.

Names
Havex, Backdoor.Oldrea (Symantec)
Target
Energy companies and makers of industrial equipment, mostly in the US and Europe
Attributed to
FSB (Russia) (In 2014 vendors saw a likely state actor; the US named Russia's FSB in 2022)
Way in
Phishing email, Compromised website, Supply chain
Protocols
OPC
Systems attacked
OPC servers, the Windows middleware that exposes live plant data to other software

2010Destruction

Stuxnet

centrifuges taken out of service at Natanz (ISIS estimate)
~1,000
computers infected worldwide by September 2010
100,000

Stuxnet, found in June 2010, is the first malware known to have damaged physical machines. It spread to about 100,000 computers in more than 150 countries. But it was built to harm one target: an Iranian uranium-enrichment plant that researchers linked to Natanz. Because the plant’s control network had no internet connection, the worm was most likely carried in on a removable drive. Then it spread on its own, using four unknown Windows flaws and the project files of Siemens Step 7 engineering software.

It loaded hidden code onto Siemens S7-300 PLCs and drove centrifuge motors far outside their normal speed. At the same time it replayed normal readings, so operators saw nothing wrong. An institute estimated that about 1,000 of 8,692 installed centrifuges were taken out of service, though the link to Stuxnet is unproven. Press reports describe a joint US-Israeli operation. No government has confirmed who built it.

Names
Stuxnet, Rootkit.TmpHider (VirusBlokAda), W32.Temphid (Symantec)
Target
A uranium-enrichment plant in Iran, linked by researchers to Natanz
Attributed to
Not officially attributed (No government has confirmed it; the attribution rests on press reports)
Way in
Removable media
Protocols
Profibus, Siemens S7
Systems attacked
Siemens S7-300 controllers and their frequency-converter drives, via Step 7 and WinCC software
How far each attack got along the kill chain
NameStage 1: intrusionStage 2: attack on the industrial process
Stuxnet 2010 5 / 8 4 / 5
Havex 2014 7 / 8 0 / 5
BlackEnergy 2015 4 / 8 4 / 5
Industroyer / CRASHOVERRIDE 2016 2 / 8 4 / 5
TRISIS / TRITON 2017 1 / 8 4 / 5
EKANS / Snake 2020 0 / 8 2 / 5
Industroyer2 2022 1 / 8 2 / 5
PIPEDREAM / INCONTROLLER 2022 0 / 8 1 / 5
Fuxnet 2024 1 / 8 4 / 5
FrostyGoop / BUSTLEBERM 2024 4 / 8 3 / 5

Each bar counts the steps of a stage that public reports describe for the attack. A short bar can also mean that a step is not documented.

How to read the cases

Each article starts with the record of the vulnerability. It lists the CVE number, the score from the US National Vulnerability Database, and the dates from the first report to the fix and the first attacks. Below that, the article explains how the flaw worked and what happened next. Charts show the figures from public reports.

The CVSS score rates how severe a vulnerability is, from 0 to 10. It does not say how often it was used in attacks. Some of the most damaging cases here have medium scores.

How a vulnerability gets on this list

This list is not a database of every vulnerability: tens of thousands receive a CVE number each year. It keeps only the cases that shook the whole system. A vulnerability is listed only if it meets all three basic conditions and at least two of the four magnitude criteria.

Basic conditions

  1. A specific flaw in a widely used product or component, with a public record: a CVE number or a vendor advisory. Malware counts through the flaw it used.
  2. Many independent operators affected, in many countries, not the customers of a single company.
  3. Documented by primary sources: vendor advisories, government agencies, or measurement studies.

Magnitude criteria (at least two)

CriterionMet when
Reachmeasurements found at least 100,000 affected systems, or the flaw sits in a component that runs on at least a tenth of all systems of its kind, such as processors, web servers, or websites
Mass exploitationattacks in the wild hit at least 1,000 organizations or 100,000 systems, or a worm spread on its own
Damagedocumented damage of at least one billion US dollars, outages of critical services such as hospitals, power, or transport, or data of at least ten million people
Extraordinary responsemeasures beyond routine patching: the highest warning level of a national cyber agency, a government emergency directive, fixes in all major operating systems at once, or coordination across industries and countries

A high severity score alone is not enough. Meltdown has a CVSS score of 5.6 and is on the list; many flaws with a score of 10 are not. Each case page shows which criteria the case meets and why.

Known, but not on the list

These vulnerabilities made headlines but meet fewer than two of the four magnitude criteria.

NameYearMain CVEWhy not
xz Utils backdoor2024CVE-2024-3094Found before it reached stable releases of the major Linux distributions; no known attacks, no damage. It meets only the response criterion: a near miss.
TunnelVision2024CVE-2024-3661Lets an attacker in the same local network route traffic around a VPN; no mass attacks, no reported damage, no extraordinary response.