On July 16, 2010, Microsoft published Security Advisory 2286198 for a Windows shortcut-handling flaw, CVE-2010-2568, after researchers Sergey Ulasen and Oleg Kupreev of VirusBlokAda reported it. A worm was already using it, and no patch was yet available—which makes that date an exact, defensible anchor for a component of one of the most studied malware operations in history. But the single advisory concealed something larger: Stuxnet was carrying four previously undisclosed Windows exploits at once.
The most important framing point comes first. Stuxnet was not a vulnerability. It was a malware campaign and a cyber-physical sabotage operation that used several vulnerabilities. Calling Stuxnet "a bug" misses the entire architecture. This entry focuses on the four requested Windows zero-days that made up its delivery system.
The four flaws divided labor cleanly across the intrusion lifecycle—initial execution, network spread, and privilege escalation:
| CVE | Component & class | Operational role |
|---|---|---|
CVE-2010-2568 | Windows Shell shortcut-icon parsing; remote code execution | Ran code when Explorer displayed a malicious shortcut icon, enabling spread via removable media and browsed folders. |
CVE-2010-2729 | Windows Print Spooler; remote code execution | Supported network propagation and lateral movement. |
CVE-2010-2743 | Windows kernel-mode driver (keyboard-layout handling); local privilege escalation | Raised privileges after code was already running on a host. |
CVE-2010-2744 | Windows kernel-mode driver (window-class handling); local privilege escalation | Provided a second route to elevated system rights. |
CVE-2010-2568 affected all then-supported Windows versions listed in bulletin MS10-046: Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2. Microsoft rated that bulletin Critical. The supplied evidence does not provide a consistent authoritative CVSS set for all four historical CVEs, and it would be wrong to borrow the severity of MS10-046 for the other three—their scores would need to come from the individual NVD or vendor records.
Stuxnet's wider toolset touched other vulnerabilities too, including CVE-2010-3338 in Task Scheduler, Siemens CVE-2010-2772 and the previously patched MS08-067 flaw. Those belong in the story as context, not silently added to the four-zero-day profile.
The engineering design distributed responsibilities across the bugs. CVE-2010-2568 solved the removable-media problem: Windows Explorer read shortcut metadata to decide which icon to display, and a specially crafted .LNK file could cause code execution during that icon display. The victim did not have to deliberately launch a malicious executable—simply browsing an infected location could be enough.
CVE-2010-2729 gave the worm a network route. By exploiting the Print Spooler service, Stuxnet could execute code remotely and move laterally instead of relying only on repeated USB contact. CVE-2010-2743 and CVE-2010-2744 then addressed privilege boundaries inside Windows, letting code already on a machine gain elevated rights through flaws in win32k.sys behavior.
That was the IT-stage delivery system. The OT-stage payload was entirely different in character: it searched for Siemens STEP 7 and WinCC environments, injected malicious logic into the industrial-control workflow, and manipulated frequency-converter-drive parameters. Reporting says the operation changed centrifuge speeds while concealing the manipulation from operators, presenting a false operational view. The engineering lesson is compositional—no single bug explains Stuxnet's reach. The shortcut flaw crossed removable-media boundaries, the spooler flaw widened network reach, the kernel flaws raised privileges, and the industrial payload selected and altered a physical process.
The four Windows flaws were found inside operating malware, not merely demonstrated in a lab. The supplied sources describe Stuxnet as a highly sophisticated, state-sponsored worm targeting Siemens industrial-control software used in Iranian nuclear facilities, particularly Natanz.
Attribution requires discipline here. The evidence supports the label "state-sponsored," but it does not name a specific government in a sufficiently authoritative statement to publish one. A more specific national attribution should not be added without additional evidence. Stuxnet also used digitally signed kernel-mode rootkits and anti-analysis techniques—a notable departure from ordinary malware of the period.
Reporting attributes physical centrifuge damage at Natanz to manipulation of operating speeds while the malware obscured those changes from operators. That is the central documented consequence. The supplied material does not provide an authoritative number of damaged centrifuges, infected Windows hosts or financial loss, so those figures should not be introduced.
There is also a scoping trap worth naming: the worm's propagation machinery was broader than its final target-selection logic. An infection count, if later sourced, would not equal the number of industrial systems altered or facilities physically damaged. Not every infected Windows system experienced industrial sabotage—the payload was selective even where the spread was not.
Analyzing worm samples and signed-driver rootkits belongs on air-gapped, disposable media. The Samsung T7 Portable SSD gives malware researchers fast, isolated external storage for offline reverse-engineering setups.
Amazon Affiliate Link
Microsoft's immediate response centered on CVE-2010-2568. MS10-046 was released out of band on August 2, 2010, with a recommendation for immediate installation. Interim workarounds included disabling shortcut-icon display by removing the relevant .LNK and .PIF icon-handler registry values, and disabling the WebClient service to block a likely WebDAV-based remote path.
Microsoft then issued MS10-061 for the Print Spooler vulnerability in September 2010 and MS10-073 for the two kernel privilege-escalation flaws. ICS-CERT published alerts, file hashes and mitigation information for Stuxnet components, including the signed driver files mrxnet.sys and mrxcls.sys. The patch cadence itself tells the story: a single operation forced multiple out-of-band and scheduled bulletins over months.
Stuxnet established that malware could integrate ordinary Windows exploitation with specialized knowledge of an industrial process to produce physical effects. Its four-zero-day suite also demonstrated how exploit diversity provides resilience: multiple entry, propagation and privilege routes reduced dependence on any single flaw. Burning four zero-days in one operation was itself a statement about resources and intent.
For defenders, it undermined the assumption that an air gap equals isolation. Removable media, engineering workstations and trusted industrial software formed bridges between office-style computing and control equipment. The takeaway that endured is architectural: the four zero-days were the delivery system, but the industrial process was the target—and defending the target required thinking about both worlds at once.