Affiliate disclosure: This guide contains affiliate links. As an Amazon Associate, we earn from qualifying purchases at no extra cost to you. Learn more.
Emulation asks you to do something the rest of computing tells you not to. You download an executable from a GitHub page run by strangers and you run it with full permissions.
Usually that is fine. The emulator scene is built on open source projects with long track records. But 2026 produced two reminders that "usually" is doing real work in that sentence, and one of them hit a project that is on this very site.
This guide covers what happened, how the scams work, and the habits that keep you safe. It takes about five minutes to learn and then costs you almost nothing.
Two Things That Happened in 2026
The Cemu compromise
In May 2026, the Linux AppImage and ZIP builds of Cemu 2.6 were replaced with malware on the project's own official GitHub repository. The bad files were live from May 6 to May 12, 2026.
This was not a fake site or a lookalike repo. It was the real project, at the real URL, serving trojanized binaries.
The attacker got in through a project contributor whose system was compromised by a poisoned Python package. That package stole the contributor's GitHub token, and the attacker used it to reupload the two Linux binaries.
The malware harvested credentials, including cloud passwords, tokens, keys, and service tokens. It also contained a destructive payload that would wipe the filesystem under certain conditions.
The Flatpak build and the Windows build were not affected. If you installed Cemu on Linux via Flatpak, or on Windows, you were never exposed.
Anyone who did run an affected build was advised to reinstall their operating system and rotate passwords, SSH keys, and service tokens.
If you followed our Cemu setup guide during that window on Linux, treat it seriously.
The fake repository campaign
Separately, security researchers at Malwarebytes reported in June 2026 that criminals are creating counterfeit GitHub repositories specifically aimed at retro gaming and homebrew communities.
The example they documented was "EQVita," presented as a free audio tool for the PlayStation Vita. It was not. It delivered SmartLoader, which then pulled down credential stealers like Lumma Stealer, targeting browser passwords, crypto wallets, and login tokens.
What makes these convincing is the polish. The fake repos have:
- Professional README files with screenshots and formatting
- AI generated descriptions written in confident marketing language
- Plausible looking version numbers, sometimes deliberately close to the real project's
- Download buttons and documentation that look exactly right
- Fabricated engagement to make the project look active and trusted
They work because homebrew communities already trust GitHub. The domain looks right, so the reflex is to click.
The Rules
1. Get the URL from the project, not from a search
Search results and video descriptions are where fake links live. Find the official site or repository once, through a trusted community wiki or the project's own documentation, and bookmark it.
For the emulators we cover, our setup guides link the official sources directly. Use those links rather than searching fresh each time.
2. Check the repo is the real one
Before downloading from any GitHub project, look at the signals a faker cannot easily manufacture:
- Commit history. Real projects have years of commits from multiple contributors. Fakes have a handful, often all on one day.
- Contributor count. A serious emulator has many. A fake has one or two accounts with no other activity.
- Issues and pull requests. Real projects have messy, ongoing discussions. Fakes have empty or artificial issue trackers.
- Account age. Click the owner. A brand new account hosting a mature looking project is a red flag.
- Stars over time. A sudden spike with no history is suspicious.
3. Know what file type you should be getting
This is the single best filter, and it is the one that catches the Vita style scam instantly.
Ask what the software actually is before you download it. A plugin for a Vita, a 3DS, or a PSP is a file that goes onto that device. It is not a Windows program. If a "Vita plugin" download hands you a .exe, that is not a mismatch to puzzle over. That is the attack.
The same logic works generally:
- Android emulators are
.apkfiles - Linux builds are usually AppImage, Flatpak, or archives
- Windows builds are
.exeor.zip - Console homebrew is
.vpk,.cia,.nro, or similar
An installer that does not match the platform it claims to target is the whole scam in one step.
4. Verify checksums when they are published
Most serious projects publish a SHA-256 hash next to each release. Comparing it takes seconds.
On Windows PowerShell:
Get-FileHash .\downloaded-file.zip -Algorithm SHA256
On Linux or macOS:
sha256sum downloaded-file.zip
Compare the output to the hash on the release page. If they differ, delete the file.
This is exactly the check that catches a Cemu style attack. When the project published its security notice, it also published the correct hashes so people could tell whether their download was clean.
The honest caveat is that if an attacker controls the release page, they may control the posted hash too. Checksums are strong against corrupted and swapped files, weaker against a fully compromised project account. They are still worth doing.
5. Prefer packaged builds where you can
The Cemu incident is instructive here. The AppImage and ZIP were compromised. The Flatpak was not.
Distribution channels that build from source and sign their packages add a layer an attacker has to defeat separately. On Linux, Flatpak from Flathub is generally safer than a loose binary. On Android, F-Droid builds from source.
This is not absolute, and packaged builds sometimes lag behind. But when both exist and you have no specific reason to need the newest build, take the packaged one.
6. Do not run emulators as administrator or root
Emulators do not need it. Neither do frontends. Malware that runs with your normal user account is bad. Malware running as root or administrator is much worse.
If something insists on elevated permissions and cannot explain why, that is a reason to stop.
7. Keep your backups separate
Your saves and save states are the irreplaceable part of all this. Keep a copy somewhere that is not attached to the machine running unknown code. Our save sync guide covers doing this in a way that survives more than just malware.
Where the Real Projects Live
Rather than list URLs that could go stale, use these habits:
- Community wikis are the best index. The Emulation General Wiki maintains lists of legitimate projects and documents known scams.
- Our setup guides link official sources for each emulator we cover, including RetroArch, PPSSPP, Dolphin, DuckStation, melonDS, Cemu, and Vita3K.
- Official Discords and subreddits for each project will tell you immediately if a lookalike is circulating.
If You Think You Ran Something Bad
Act quickly and assume the worst.
- Disconnect from the network to stop data leaving.
- Change your passwords from a different, clean device. Start with email, then anything financial, then everything reused.
- Rotate tokens and keys. SSH keys, API tokens, cloud service credentials, and anything stored in a config file on that machine.
- Enable two factor authentication anywhere it is not already on.
- Reinstall the operating system. This is what Cemu advised affected users to do, and for credential stealing malware it is the only reliable cleanup.
- Watch your accounts for the next few weeks.
Reinstalling feels dramatic. It is far less painful than discovering months later that someone has been in your accounts.
The Short Version
Most emulator downloads are completely fine. The scene is built by people who care about preservation and mostly do good work.
Five habits cover almost all of the risk. Bookmark official sources. Check that a repo has real history behind it. Make sure the file type matches the platform. Verify checksums when they are offered. Prefer Flatpak or F-Droid builds where they exist.
That is it. A few seconds per download, and you stay out of the way of the two attacks that actually happened this year.
Frequently Asked Questions
Was Cemu really infected with malware?
Yes. The Linux AppImage and ZIP builds of Cemu 2.6 on the project's official GitHub were replaced with credential stealing malware between May 6 and May 12, 2026. A contributor's GitHub token was stolen through a poisoned Python package. The Flatpak and Windows builds were not affected.
What should I do if I downloaded Cemu on Linux in May 2026?
If you downloaded the AppImage or ZIP between May 6 and May 12, 2026 and ran it, assume your credentials were exposed. Reinstall your operating system, and reset passwords, SSH keys, and service tokens from a clean device. Flatpak installs were not affected.
How can I tell if a GitHub repository is fake?
Check the commit history, contributor count, issue tracker activity, and the owner account's age. Real emulator projects have years of messy history from many people. Fakes have a polished README, a new account, and almost no real development activity behind them.
Are emulators safe to download?
Generally yes, when you get them from official sources. The risk comes from fake lookalike projects and, rarely, from compromised official builds. Verifying checksums and preferring packaged builds like Flatpak covers most of it.
Should I verify checksums for every download?
It takes about ten seconds and it is worth doing whenever a project publishes hashes. It reliably catches corrupted and swapped files. It is weaker protection if a project's own account is fully compromised, but it still helps.
Is it safer to install emulators from Flatpak or F-Droid?
Often, yes. Those channels build from source and sign their packages, which adds a layer an attacker has to defeat separately. During the Cemu incident, the Flatpak build was clean while the loose Linux binaries were not.
Related Reading
Related reading
GuideGuideGuide