Stuxnet 'reconstruction' on GitHub is not a leak

The Stuxnet source code has not leaked. That has not stopped a repository on GitHub from being passed around this week as though it had. What actually exists is a project called Sadpainy/Stuxnet, created on 6 September 2026, which its own README describes as a reconstruction assembled from decompiled binaries rather than anything lifted from the people who built the worm.

By 17 September it had 518 stars, 97 forks and an AGPL-3.0 licence, and it had been pushed to within hours of that count. On Hacker News, where it was posted as a Show HN on 7 September, the thread reached 179 points and 51 comments — and a fair number of those comments were people explaining, in detail, why they did not believe it.

What is the Stuxnet repository on GitHub?

It is a reconstruction, by an account calling itself Sadpainy, of the worm that wrecked centrifuges at Iran's Natanz enrichment plant. The repository description reads: “Stuxnet, Here reproduced by me, Only researchs for educations purposes. It set work on Windows XP and Windows 7 only.” The README is more careful, calling the work “a strictly educational and research-oriented reconstruction” and stating plainly that it “is not intended to be used for any malicious purposes, nor is it a deployable piece of malware.”

Structurally, it looks like the Stuxnet that analysts have described for sixteen years. There is a loader and dropper, the MRxCls.sys and MRxNet.sys rootkit drivers that hide files, processes and registry keys, propagation through USB link files, print spoolers and peer-to-peer connections, and a payload that rewrites Siemens PLC block logic in OB1 and OB35 to mess with motor frequencies on SIMATIC WinCC, Step 7 and S7-300 and S7-400 hardware. Whether any of it compiles, runs, or does what it claims is a separate question, and nobody outside that thread has answered it publicly.

Where did the repository come from?

The account published it on 6 September and posted it to Hacker News the next day under the title “Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon”. It sat there for nine days doing normal Hacker News numbers before mainstream outlets found it on 16 September and started writing up the return of Stuxnet. The original worm has not returned, and the repository has not changed that: it is five megabytes of source files on a public code host.

Is it the real Stuxnet source?

No, and there is a clean technical reason to say so. Stuxnet was uncovered on 17 June 2010 by the Belarusian security firm VirusBlokAda, which named it Rootkit.Tmphider. Symantec called it W32.Temphid, then settled on W32.Stuxnet, and the name stuck because it is a better name. The people who wrote the worm were long finished by then. So a genuine build would not carry the word “Stuxnet” inside it, and this one does — commenters on the Hacker News thread pointed at lines such as a Windows Run registry key literally named Stuxnet as proof that the code was written after the fact by somebody who had read the same public write-ups as everyone else.

What do developers say about it?

The scepticism is not subtle. One commenter described the whole thing as “slop, it's all concatenated into a single file and most probably not based on the actual malware”, while another noted that whoever spent the compute on the reverse engineering could have spent some of it documenting the result instead. Others found the exercise interesting anyway — 15,000 lines is a lot of code to poke through, as one put it — and a few picked over whether USB propagation would ever have worked without a compromised reseller in the supply chain.

Has something like this happened before?

Repeatedly. Christian Roggia's open-myrtus published a dropper decompilation of the worm, which has been forked into a long chain of repositories; research-virus/stuxnet, which carries the malware's other public name MyRTUs, has been on GitHub since 2015 with more than 1,300 stars; and micrictor/stuxnet has hosted a decompile since 2014. Every one of those was a community reconstruction from samples, and every one of them came with the same caveat — the original source is not in public hands and never has been.

Why does this matter?

Because Stuxnet is the one piece of malware that earned its reputation twice: on the technical shelf, as the first known cyber-weapon to cause physical destruction, and on the geopolitical one, as the opening chapter of state-sponsored sabotage of industrial control systems. Reports credit it with infecting more than 200,000 computers and damaging roughly a fifth of Iran's nuclear centrifuges. A repository that claims to carry that weapon recreated, complete with a compiled-looking file tree, is exactly the form of bait that security teams have spent the past year warning about: the file that looks like research, gets downloaded by somebody curious, and turns out to be neither.

Our opinion

The interesting failure here is not that somebody faked Stuxnet. It is that the ecosystem rewarded the fake before it checked it. 518 stars is not a security audit, and the timing tells its own story: a repository that sat quietly for nine days went viral the moment outlets started calling it a leak, which means the distribution was driven by the headline and not by anyone's ability to read the code. That is a bad habit for an industry that now writes malware with chatbots — if we cannot tell an AI-assisted approximation of a 2010 cyber-weapon from the real thing, the next repository to clear 500 stars will not be harmless, and the difference will be discovered by whoever runs it in a virtual machine against their own curiosity. Both the author and the amplifier got what they wanted this time. That will not always be true.