high
CVE
Not assigned
CWE
CWE-506, CWE-494
Affected Surface
Cemu v2.6 Cemu-2.6-x86_64.AppImage uploaded on 2026-05-08, Cemu v2.6 cemu-2.6-ubuntu-22.04-x64.zip uploaded on 2026-05-07, Linux users who downloaded and ran the compromised Cemu v2.6 AppImage or Ubuntu ZIP between 2026-05-06 and 2026-05-12, Steam Deck and EmuDeck-style setups that fetched Cemu Linux assets directly from the GitHub release, GitHub release asset publishing workflows that allow human tokens to replace release binaries
Cemu, the open-source Wii U emulator, had two Linux assets on its official v2.6 GitHub release replaced with malware in early May 2026. The compromised files were not typosquats or third-party mirrors; they were hosted under the real cemu-project/Cemu release, with the original Linux assets deleted and re-uploaded by a long-term contributor account.
Datadog Security Labs linked the malicious Cemu assets to the same Python payload family used in the May 11 TeamPCP campaign that hit TanStack, Mistral AI, Guardrails AI, UiPath, OpenSearch, and other npm and PyPI packages. In Cemu’s case, the attacker moved from package registries to GitHub Releases, turning a trusted binary download channel into the delivery mechanism.
Affected projects and files
The affected project is cemu-project/Cemu, specifically the Linux release assets for Cemu v2.6:
Cemu-2.6-x86_64.AppImage, re-uploaded on 2026-05-08 with SHA-256d07a29c4458d00e42d5d9e6345932592e91644d6b821bacdb7a543c628e0b41a.cemu-2.6-ubuntu-22.04-x64.zip, re-uploaded on 2026-05-07 with SHA-256f140e76236b96adf7cdc796227af9808665143bc674debb77729fa3e4b8327cc.
The Cemu maintainers said users are affected if they downloaded either Linux asset between 6 May and the time the issue was reported on 12 May 2026, then ran the compromised binary. Windows, macOS, and Flatpak releases were reported as unaffected. Users who only downloaded the file but never ran it had exposure to a malicious file but did not execute the payload according to maintainer guidance.
The AppImage had roughly 19,897 downloads and the Ubuntu ZIP roughly 1,957 downloads when the issue was reported. Datadog found that prior Cemu release assets were uploaded by github-actions[bot]; these two v2.6 Linux assets were unusual because they were uploaded by the MangelSpec user account more than a year after the original release.
What changed in the release assets
Datadog extracted the compromised AppImage and found a foreign Python zipapp at:
squashfs-root/usr/share/Cemu/scripts/startup.pyz
That path does not exist in legitimate Cemu builds, and Cemu does not normally ship a Python dependency graph. The startup.pyz payload in the AppImage was byte-for-byte identical to transformers.pyz, the Python payload used by the broader TanStack and Mistral campaign.
The Ubuntu ZIP carried a similar startup.pyz payload with a more evasive first-run behavior. Datadog described a sentinel file at /tmp/.transformers: the first execution creates the marker and exits, while later executions run the credential-stealing payload. That kind of two-stage gate can reduce observable behavior in sandboxes that execute a sample only once.
Payload behavior
Public analysis describes broad credential collection across developer and cloud environments:
- SSH keys, GitHub tokens, Git credentials, npm or service tokens, and local password material.
- AWS, Azure, and GCP credentials and secrets.
- Kubernetes service-account and cluster secrets.
- HashiCorp Vault tokens and secrets.
- Password-manager artifacts such as 1Password, Bitwarden,
gopass, andpass.
The payload also contains propagation logic. Cemu maintainers said the likely initial compromise was that a long-term Cemu co-author ran compromised software in WSL, leading to theft of a GitHub token that could replace release assets. That matches the wider campaign’s goal: harvest credentials that can be used to compromise more packages, repositories, or release channels.
The malware used 83.142.209[.]194 as a hardcoded endpoint, and Datadog reported fallback exfiltration through GitHub-based dead drops. Some variants include geofenced destructive behavior for Israeli or Iranian environments, including attempted filesystem deletion and siren playback. Cemu maintainers noted that the Cemu-specific destructive command appeared malformed in their sample, but users should not rely on that implementation mistake as a safety boundary.
Why this matters
This incident is a reminder that software supply chain risk is not limited to package-manager install hooks. GitHub Releases, CI-produced artifacts, AppImage downloads, IDE plugin bundles, and update managers are all software distribution channels.
The Cemu compromise also differs from the npm and PyPI legs of the TeamPCP wave in an important way: the release swap did not appear to go through CI. Datadog reported no relevant deploy workflow run and no changed Git tag. The likely path was direct GitHub Releases API access with a human account or token. That bypasses controls that only verify source tags or workflow provenance.
For developers and application-security teams, the practical lesson is to verify release asset provenance, not just source code provenance. A tag can be unchanged while binary assets attached to that tag have been replaced.
Detection
Search endpoints and download caches for the compromised hashes:
d07a29c4458d00e42d5d9e6345932592e91644d6b821bacdb7a543c628e0b41a
f140e76236b96adf7cdc796227af9808665143bc674debb77729fa3e4b8327cc
0f35abda19fb69430c32228465396094b866d887427bf551e353ab31256a9dd6
1bf72f05191d849049d4a38fced2277ac5cfc54b7ae591f564e7a14add7c886d
Look for the payload files and markers described publicly:
startup.pyzinside Cemu application directories./tmp/.transformers./tmp/transformers.pyz.pgmonitor.py.pgsql-monitor.service.
Network telemetry should flag connections to 83.142.209[.]194, especially from developer workstations, Steam Deck devices, CI runners, or hosts that recently ran Cemu. Review GitHub audit logs for unexpected release-asset deletion and upload events, particularly when the uploader is a human account on assets that are normally created by automation.
Remediation
If a user ran the compromised Cemu Linux asset, treat the host as compromised:
- Delete the compromised Cemu files and install only restored clean assets.
- Rotate SSH keys, GitHub tokens, package-registry tokens, cloud credentials, Vault tokens, Kubernetes credentials, and passwords reachable from the host.
- Revoke active GitHub sessions and audit recent GitHub release, repository, package, and workflow activity.
- Remove suspicious persistence such as
pgsql-monitor.servicebefore reconnecting the host to sensitive networks. - Consider rebuilding the host where high-value credentials were present.
For project maintainers, protect GitHub Releases as a production deployment surface:
- Prefer release assets generated and uploaded only by hardened CI workflows.
- Remove or tightly scope human ability to delete and replace release assets.
- Monitor release-asset uploader, digest, and timestamp changes.
- Publish expected hashes separately, and alert when an existing release asset changes after initial publication.
- Use short-lived, least-privilege tokens for release operations and rotate contributor tokens after any workstation compromise.
Security teams should add release-asset changes to supply-chain monitoring. Lockfiles and package advisories will not catch a compromised AppImage or ZIP downloaded from a GitHub release page.