Thanks for the alert!

I have removed the compromised releases. The uploader is the account of the long term co-author of Cemu. As an immediate measure I have removed their access to the repo and reached out to him to clarify how exactly this could have happened. Thanks again for reporting this. Will investigate further

Update: Files have been restored to a good version. If you downloaded either the Ubuntu or AppImage version of Cemu 2.6 between 6th May and the time this issue was posted then you are affected. In this case read my my second response in this issue

How screwed am I if I downloaded and ran AppImage today prior to being taken down?

From preliminary analysis it seems that mostly it is trying to spread itself rather than cause direct damage, it does that by stealing SSH keys, github tokens and a lot of other passwords or keys that they can then use to infect more packages or software releases. This is likely also how we got affected. The other Cemu author (MangleSpec/Petergov) ran software in WSL which was compromised through which they got hold of his github token. At least that is our leading theory.

HOWEVER if your region is Israel (it detects this via keyboard layout and timezone settings), then it will have a random chance to wipe your filesystem (subprocess.run(["rm", "-rf", "/*"])) every time you start the compromised software.

So my immediate advice is this:

1. Delete the compromised Cemu files (Cemu-2.6-x86_64.AppImage and cemu-2.6-ubuntu-22.04-x64.zip). Note: You are not affected if you downloaded before 6th May.
2. Reset all your passwords, ssh keys and service tokens
3. Block IP 83.142.209.194 just in case. This is hardcoded and used as a remote endpoint

In our case it's the Linux releases Cemu-2.6-x86_64.AppImage and cemu-2.6-ubuntu-22.04-x64.zip that got compromised. Windows and MacOS releases are unaffected as well as the flatpak version of Cemu. The compromised ubuntu and appimage zip have been online for 5-6 days (they were taken offline 10 minutes after this issue was posted and I am in the process of restoring the good files).

More info: https://rentry.org/cemu-security-psa

this is actually the same attack : https://fxtwitter.com/MsftSecIntel/status/2054041471280423424
same behavior against israeli users, same IP

and this recent supply chain attack also used transformers as part of the payload, so maybe related idk ?
https://safedep.io/mass-npm-supply-chain-attack-tanstack-mistral/

Would it be a good idea to bump the release number of the restored AppImage to trigger installers like emudeck to re-download it?

Would a user be meaningfully affected if they had EmuDeck download the affected AppImage as part of a mass update but never ran Cemu between then and now?

subprocess.run(["rm", "-rf", "/*"])

If this was the exact command it would have failed because you'd need --no-preserver-root lmao

Would a user be meaningfully affected if they had EmuDeck download the affected AppImage as part of a mass update but never ran Cemu between then and now?

I would like to know as well

subprocess.run(["rm", "-rf", "/*"])

If this was the exact command it would have failed because you'd need --no-preserver-root lmao

It runs rm -rf /* which the glob is expanded by the shell to every directory/file in /

So it runs rm -rf /bin /lib /usr /home /var /etc, etc

I assume it runs this as the user that executed the malware and not as root, which means it only deletes what your user has write access to. Similar to the infamous Steam bug. Worst case scenario you delete all your backups and external drives if you had them mounted.

Would a user be meaningfully affected if they had EmuDeck download the affected AppImage as part of a mass update but never ran Cemu between then and now?

Yes you would have a compromised version of Cemu which you should uninstall immediately. No you aren't affected if you didn't open the file.

subprocess.run(["rm", "-rf", "/*"])

If this was the exact command it would have failed because you'd need --no-preserver-root lmao

It runs rm -rf /* which the glob is expanded by the shell to every directory/file in /

So it runs rm -rf /bin /lib /usr /home /var /etc, etc

I assume it runs this as the user that executed the malware and not as root, which means it only deletes what your user has write access to. Similar to the infamous Steam bug. Worst case scenario you delete all your backups and external drives if you had them mounted.

Not sure about the implementation of subprocess.run(), but theres also a chance that there is no glob expansion since that would require the command to be run in a shell that does it.

Yeah I guess I never mentioned but I already deleted the compromised appimage when the I saw the hashes matched the bad set, I’ll check with the gyrodsu folks on that, still wondering about the tools folder, I’ve seen exactly one person mention it on Reddit and am trying to see if anyone else could elaborate if possible. Changed passwords and have been monitoring account activity closely but I haven’t noticed anything out of the ordinary

Not sure what the tools folder is but if you have just one of these files then you are compromised:
/tmp/.transformers
/usr/bin/pgmonitor.py
~/.local/bin/pgmonitor.py
/etc/systemd/system/pgsql-monitor.service
~/.config/systemd/user/pgsql-monitor.service
/tmp/kubectl

Yeah I guess I never mentioned but I already deleted the compromised appimage when the I saw the hashes matched the bad set, I’ll check with the gyrodsu folks on that, still wondering about the tools folder, I’ve seen exactly one person mention it on Reddit and am trying to see if anyone else could elaborate if possible. Changed passwords and have been monitoring account activity closely but I haven’t noticed anything out of the ordinary

Not sure what the tools folder is but if you have just one of these files then you are compromised: /tmp/.transformers /usr/bin/pgmonitor.py ~/.local/bin/pgmonitor.py /etc/systemd/system/pgsql-monitor.service ~/.config/systemd/user/pgsql-monitor.service /tmp/kubectl

What would you say is the best way to search for those in desktop mode? Dolphin file manager is agonizingly slow when I try and enter those into the search bar and eats up the cpu trying to search for ages.
And regarding the tools folder it’s a directory emudeck created on my microSD card that appears to house the bios checker, SRM and the compression tools

Yeah I guess I never mentioned but I already deleted the compromised appimage when the I saw the hashes matched the bad set, I’ll check with the gyrodsu folks on that, still wondering about the tools folder, I’ve seen exactly one person mention it on Reddit and am trying to see if anyone else could elaborate if possible. Changed passwords and have been monitoring account activity closely but I haven’t noticed anything out of the ordinary

Not sure what the tools folder is but if you have just one of these files then you are compromised: /tmp/.transformers /usr/bin/pgmonitor.py ~/.local/bin/pgmonitor.py /etc/systemd/system/pgsql-monitor.service ~/.config/systemd/user/pgsql-monitor.service /tmp/kubectl

What would you say is the best way to search for those in desktop mode? Dolphin file manager is agonizingly slow when I try and enter those into the search bar and eats up the cpu trying to search for ages. And regarding the tools folder it’s a directory emudeck created on my microSD card that appears to house the bios checker, SRM and the compression tools

for p in /tmp/.transformers /usr/bin/pgmonitor.py ~/.local/bin/pgmonitor.py /etc/systemd/system/pgsql-monitor.service ~/.config/systemd/user/pgsql-monitor.service /tmp/kubectl; do [ -e "$p" ] && echo "EXISTS: $p" || echo "NOT FOUND: $p"; done

just copy and paste this and pray it says not found

is cemu now safe to use again? i've been wanting to play some wii u titles

is cemu now safe to use again? i've been wanting to play some wii u titles

Yes just make sure to check the hash using the command I sent early and make sure it matches the good one.

If you have the bad hash then reinstall

There is quite a lot of information out there, but for any Arch Linux or any Arch derivative (EndeavorOS, Manjaro, CachyOS, Garuda, etc.) users who installed CEMU from the AUR, you are completely safe. The AUR builds from source, which is not where the malware took place. I had to research this myself so I am putting it in a comment here for easy access from others. Thank you to the CEMU team for fixing this issue and to DataDog for catching it.

Besides the immutable releases idea, people should think about how they manage their access tokens. It is really risky to use tokens that never expire or have more permissions than needed. It looks like an inactive dev still had full access long after they stopped contributing. Having tokens expire automatically is also a great safety net just in case a developer's laptop ever gets stolen. The GitHub docs actually mention setting strict limits to prevent these exact kinds of attacks.

Sorry for the stupid question since Im newbie. I am a Steam Deck user, If my Cemu.AppImage file properties shows created oct 9 2025 and modified oct 9 2025 but accessed may 18 2026 am I compromised? The hash is the correct one.

Sorry for the stupid question since Im newbie. I am a Steam Deck user, If my Cemu.AppImage file properties shows created oct 9 2025 and modified oct 9 2025 but accessed may 18 2026 am I compromised? The hash is the correct one.

Probably not. Check if you have any of the files I and others mentioned above. If you didn't open Cemu at the time it was compromised you should be safe.

Sorry for the stupid question since Im newbie. I am a Steam Deck user, If my Cemu.AppImage file properties shows created oct 9 2025 and modified oct 9 2025 but accessed may 18 2026 am I compromised? The hash is the correct one.

Probably not. Check if you have any of the files I and others mentioned above. If you didn't open Cemu at the time it was compromised you should be safe.

No, I dont have those files on my Deck.

To be honest, I cannot say 100% that I didnt open Cemu at all (although I dont think so bc I have not played any game). However, I would say I didnt update it, plus the dates of the file seem to indicate that I last updated it on october (when I installed it for the first time). Therefore, the hash is the safe.

I havent updated it yet, just in case I can check something.

Is this an issue if Cemu was installed via the Fedora Discover app, (installed as a flatpack)? Admittedly not super well versed in how flatpacks/snaps etc. work compared to appimages

Is this an issue if Cemu was installed via the Fedora Discover app, (installed as a flatpack)? Admittedly not super well versed in how flatpacks/snaps etc. work compared to appimages

Flatpaks aren't affected :)

@SSimco, is the android build version affected?

Android builds are not affected