Résumé
Stuxnet, uncovered in June 2010, was the first malware built to break things in the physical world, and it rewrote the rules of conflict between states. Widely understood to be a joint US and Israeli operation codenamed "Olympic Games," it had one target: the air-gapped industrial controllers running the gas centrifuges at Iran's Natanz uranium-enrichment plant. Stuxnet crossed the air gap on USB drives, used four Windows zero-days to spread, and signed its kernel drivers with code-signing certificates stolen from two Taiwanese hardware makers so Windows loaded them without complaint. Once it found a machine running Siemens Step7 software, it reprogrammed the controllers to spin the centrifuges to destructive speeds while replaying recorded "everything is normal" readings back to the engineers watching the screens. It quietly wrecked roughly a thousand centrifuges, set Iran's program back about a year, and then escaped to infect more than 100,000 computers worldwide, proving once and for all that an isolated network is not an immune one.
How it worked
Stuxnet's genius was patience, and it ran in two stages.
The first stage was getting in and spreading. Natanz was air-gapped, so Stuxnet was built to travel on removable media: a single infected USB drive was enough. It exploited a zero-day in how Windows rendered shortcut (.LNK) files (CVE-2010-2568), so simply viewing the contents of an infected drive in Windows Explorer triggered remote code execution, with no clicks required. From that first machine it used three more zero-days (a Print Spooler flaw and two privilege-escalation bugs) plus a hard-coded password in Siemens' WinCC database to move quietly across the internal network and burrow into engineering workstations. To slip past antivirus, its kernel drivers were signed with valid certificates stolen from the chipmakers Realtek and JMicron.
The second stage was sabotage, and it only fired on the exact system it was hunting. Stuxnet ignored everything until it found Siemens Step7 software talking to a specific model of programmable logic controller (PLC) wired to a specific arrangement of centrifuge frequency-converter drives: the fingerprint of Natanz. Only then did it act. It injected its own code between the control software and the PLC, becoming a man in the middle, and hid behind a rootkit that concealed both its Windows files and the rogue logic it loaded onto the controller itself. Stuxnet actually carried two sabotage routines over its lifetime: an earlier one that quietly over-pressurised the centrifuges by manipulating their isolation valves, and the better-known one that attacked rotor speeds. The speed attack drove the rotors far outside their safe band, briefly up to 1,410 Hz, which spins an IR-1's aluminium rotor at roughly 443 metres per second, past the metal's structural limit, and then slammed them down toward a near-stop, all while recording about 21 seconds of normal sensor data and replaying it on a loop to operators and safety systems. The engineers saw green dashboards while their centrifuges shook themselves to pieces.
The damage
Iran never confirmed the full toll, but the numbers leaked out anyway. In late 2009 and early 2010, inspectors from the International Atomic Energy Agency watched Iran quietly decommission and replace about 1,000 IR-1 centrifuges at the Natanz Fuel Enrichment Plant, roughly a fifth of the machines in operation. Analysts at the Institute for Science and International Security tied the breakage to Stuxnet and estimated it set the enrichment program back by around a year. The attack was effective precisely because it was slow and deniable: instead of one dramatic explosion, centrifuges failed at an unusual rate over months, and Iran's engineers spent that time chasing ghosts, blaming bad parts, bad operators, and bad luck. That misdirection was worth as much as the broken hardware.
Stuxnet's one real mistake was getting out. A later, more aggressive variant spread beyond Natanz and onto the public internet, which is how the rest of the world found it. By the time it was catalogued it had infected well over 100,000 machines across more than 150 countries, with roughly 60% of the infections in Iran. None of those collateral infections did anything; the payload stayed inert outside Natanz. But the escape is what turned a secret operation into the most studied piece of malware in history.
Who built it, and why
Officially, no government has claimed Stuxnet. Unofficially, the consensus is firm. In 2012 The New York Times reported that Stuxnet was the centerpiece of a US-Israeli program codenamed "Olympic Games," begun under President George W. Bush around 2006 and accelerated under President Obama, built jointly by the US National Security Agency and Israel's signals-intelligence Unit 8200. The strategic logic was to set back Iran's nuclear ambitions without an airstrike that could ignite a regional war: a weapon that left no fingerprints and could be plausibly blamed on faulty equipment.
It was discovered almost by accident. In June 2010 a small Belarusian antivirus firm, VirusBlokAda, was called in to investigate Iranian computers that kept crashing and rebooting, and its engineer Sergey Ulasen traced the fault to an anomalous but validly signed driver, the loose thread that unravelled the whole operation. What they found was unlike anything before it, and as Symantec, Kaspersky, and the German control-systems researcher Ralph Langner pulled it apart over the following months, the picture sharpened into a precision-guided digital weapon aimed at a single facility.
Why Stuxnet still matters
Stuxnet is the line that divides cybersecurity into a before and an after. Before, a "cyberattack" meant stolen data or downtime. After, it meant a machine could be made to physically destroy itself. Stuxnet proved that code can have the effect of a bomb, and that the most isolated, most critical systems in the world, the ones running power grids, pipelines, water treatment and factories, were reachable.
The descendants arrived on schedule. Industroyer cut power in Kyiv in 2016; Triton (also called Trisis) reached into the safety-instrumented systems of a Saudi petrochemical plant in 2017, the systems whose entire purpose is to prevent an explosion; Industroyer2 was aimed at Ukraine's grid again in 2022. An entire discipline, operational-technology (OT) and industrial-control-system (ICS) security, exists in its current form largely because Stuxnet showed what was at stake. And it left a lesson that keeps getting relearned: an air gap is a control, not a force field. Anything a human can carry across it, a worm can ride.
Comment le corriger
- Re-image any controller or engineering workstation suspected of infection from known-good media; against a rootkit this capable, on-disk integrity cannot be trusted.
- Revoke and reissue any code-signing certificates and keys that may have been stolen, and rebuild and re-sign artifacts from a clean pipeline.
- Compare PLC and controller logic against a trusted, offline baseline and restore verified Step7 or ladder code; assume the live controller is lying about its own state.
- Reconstruct the intrusion path (which USB, which workstation) from host and removable-media logs before reconnecting any OT segment.
Comment l’éviter
- Treat an air gap as one layer, not a guarantee: control and scan removable media, disable USB autorun on OT hosts, and assume something will eventually cross the gap.
- Allowlist exactly which signed code may run on engineering workstations, and alert on drivers or binaries signed by unexpected vendors.
- Segment and monitor the OT network, and alert when controller logic, setpoints, or drive frequencies change outside an approved maintenance window.
- Keep verified offline backups of PLC programs and HMI configurations, so tampered logic can be caught by comparison and rolled back.
- Patch the IT systems on the OT boundary promptly; Stuxnet reached the controllers by riding ordinary Windows zero-days through the engineering network.
Références
Vulnérabilités liées
Tout Infra →- HIGHINFRA-USBLITER8-2026
usbliter8, published on 18 June 2026 by a research group called Paradigm Shift, is an unpatchable BootROM exploit for Apple's A12 and A13 chips, the silicon inside the iPhone XS, XR and 11 families plus the Apple Watch Series 4 and 5. It is the long-awaited successor to checkm8, the 2019 exploit that broke every Apple chip from the A5 to the A11 and was assumed to be the end of that road. The bug lives in the SecureROM, the very first code an Apple device runs at power on, which is etched into the silicon at the factory and can never be altered by any software update. usbliter8 abuses a hardware flaw in the Synopsys DWC2 USB controller: a mismatch in how the controller tracks its DMA memory while buffering USB Setup packets lets an attacker walk a write pointer backwards through memory and overwrite arbitrary SRAM, ending in full code execution inside the most trusted code on the chip. From there it can boot unsigned firmware and step outside Apple's chain of trust entirely, stamping the string PWND into the device's USB serial number as proof of control. The catch is that it is not a remote attack: it needs physical possession of the device, DFU recovery mode, a USB connection and a small RP2350 microcontroller board, and nothing it changes survives a reboot. It also does not break the Secure Enclave, so a device protected by a strong passcode keeps its user data encrypted even after the boot chain has been taken over. Apple cannot repair the affected chips; the only real remedy is newer hardware, because the A14 and later configure the controller correctly and are out of reach.
- HIGHCVE-2026-31431
Copy Fail (CVE-2026-31431), disclosed on 29 April 2026 by the security firm Theori, is a Linux kernel flaw that turns any unprivileged local user into root with a 732-byte Python script and no luck required. Despite a name that sounds like a clipboard bug, it has nothing to do with copy and paste: it is a failed copy deep in the kernel's crypto code. A nine-year-old optimization in the AF_ALG crypto socket interface let an attacker steer the kernel into writing four attacker-chosen bytes into the page cache, the in-memory copy of files that the CPU actually executes. Patch the cached pages of a setuid-root binary like /usr/bin/su, run it, and you are root. The exploit is a straight-line logic flaw with no race condition and no hardcoded kernel addresses, so the exact same script runs at roughly 100 percent reliability across Ubuntu, RHEL, SUSE, Amazon Linux and every other distribution built since 2017. Worse, because the page cache is shared by the whole machine, it crosses container boundaries: one poisoned page in a Kubernetes pod can compromise neighbouring tenants and the host. The disk file is never touched, so file-integrity scanners stay silent. It rates CVSS 7.8 (High), was added to CISA's Known Exploited Vulnerabilities catalog on 1 May 2026, and is notable for how it was found: an AI-assisted code scan surfaced a bug that had been silently exploitable for nearly a decade in about one hour.
- CRITICALCVE-2025-1974
IngressNightmare was a chain of five vulnerabilities in the Ingress-NGINX Controller for Kubernetes disclosed on 24 March 2025 by the Wiz Research team, the most severe being CVE-2025-1974 (CVSS 9.8), which enabled unauthenticated remote code execution from the pod network. Wiz estimated about 43% of cloud environments were vulnerable and identified over 6,500 publicly exposed clusters, including Fortune 500 organizations. The controller's validating admission webhook ran as an unauthenticated HTTP endpoint reachable by any workload on the pod network, accepting attacker-supplied AdmissionReview requests containing crafted Ingress objects. The supporting CVEs (CVE-2025-24514 auth-url, CVE-2025-1097 auth-tls-match-cn, CVE-2025-1098 mirror UID, CVE-2025-24513 path bypass) injected unsanitized NGINX configuration directives via annotations into a temporary config the controller validated with nginx -t. The attacker uploaded a shared-library payload by abusing NGINX client-body buffering (an oversized Content-Length keeps the request file descriptor open in ProcFS) and then used the injected ssl_engine directive to load that library during validation, achieving code execution in the controller pod whose service account could read all cluster secrets across namespaces, enabling full cluster takeover.
- HIGHCLOUD-ENVFILE-EXTORTION-2024
On August 15, 2024, Palo Alto Networks Unit 42 detailed a large-scale extortion campaign that compromised cloud environments by harvesting exposed environment variable files. Attackers scanned at least 110,000 domains and collected over 90,000 unique variables, including roughly 7,000 cloud service credentials and 1,515 social media credentials, with their infrastructure probing around 230 million targets. The vector was a web server misconfiguration: .env files inside the web root were served as plaintext over HTTP because the servers had no rule denying access to dotfiles, exposing the long-lived AWS IAM access keys hardcoded inside. The initial IAM principals lacked full admin but retained permission to create roles and users, so attackers called CreateRole and attached AdministratorAccess to escalate, then spun up Lambda functions across regions to automate further internet-wide scanning. They used the victims' own AWS accounts to exfiltrate and delete S3 objects, then uploaded ransom notes demanding payment. The failure chain combined exposed dotfiles, long-lived hardcoded credentials, and over-permissioned IAM, not any cloud-provider flaw.
- CRITICALCLOUD-BUCKET-MONOPOLY-2024
In research disclosed to AWS on February 16, 2024 and presented at Black Hat USA and DEF CON 32 in August 2024, Aqua Security's Nautilus team described a class of S3 bucket-name takeover attacks they called Bucket Monopoly, affecting CloudFormation, Glue, EMR, SageMaker, Service Catalog, and CodeStar. These services auto-created S3 buckets with predictable names built from static prefixes plus the account ID and region, such as cf-templates-{hash}-{region}, aws-glue-assets-{account-id}-{region}, and sagemaker-{region}-{account-id}, where account IDs are discoverable from ARNs, access keys, and public repos. Because S3 bucket names are globally unique, an attacker could pre-create a victim's predictably named bucket in a region the victim had not yet used (a Shadow Resource), then the victim's service would later read attacker-controlled content from it. This enabled data tampering, information disclosure, remote code execution by injecting malicious Glue or CloudFormation content, and in some cases full account takeover via planted admin roles; AWS remediated by adding randomized suffixes to bucket names and enforcing aws:ResourceAccount conditions. The class also covers reuse of abandoned or dangling bucket names that a victim configuration still references.
- HIGHCVE-2024-6387
A signal-handler race condition in OpenSSH's server (sshd) on glibc-based Linux. If a client fails to authenticate within the LoginGraceTime window, the SIGALRM handler calls async-signal-unsafe functions, which an attacker can interrupt at a precise moment to corrupt the heap and achieve unauthenticated remote code execution as root. It is a regression of the 2006 CVE-2006-5051, reintroduced in OpenSSH 8.5p1. Exploitation is non-trivial, requiring thousands of race attempts, but Qualys reported roughly 4.8 million internet-exposed instances as potentially affected.