{"slug": "dolphin-progress-release-2609", "title": "Dolphin Progress Release 2609", "summary": "Dolphin Emulator released version 2609, which adds NetPlay support to its Android build and addresses an AI-driven wave of vulnerability reports plus a macOS buildbot cryptominer compromise that the project says did not affect any builds. The project said people are using AI to mass-scan open source projects for potential vulnerabilities and overwhelm its volunteer team with verbose reports, forcing effort into patching and workflow changes, while a macOS vulnerability briefly let a generic cryptominer compromise the macOS buildbot. Developer tom-pratt built the Android NetPlay GUI across several pull requests using Jetpack Compose, bringing lockstep NetPlay to Android for the first time.", "body_md": "Welcome to Dolphin 2609's accompanying Progress Report! Like everyone else, we've been doing our best to weather the Techpocalypse brought on by AI, but it's really come after us in the past few months. Our website has been up and down repeatedly lately, as our defenses are barely holding out under the endless bombardment. But now AI has started to come for the emulator directly, with people using AI to mass-scan open source projects for potential vulnerabilities and overwhelm our volunteer team with very verbose reports.  Though draining, once these vulnerabilities are out there, we can't ignore them. A lot of effort has had to be diverted to deal with them, both in patching them and adjusting our workflows to better manage them. For more information, zip directly to that section with [this link here](#brace-for-impact-the-ai-vulnerability-reporting-wave-crashes-into-dolphin).\n\nBut that's not all. A vulnerability in macOS allowed our macOS buildbot to be briefly compromised by a generic cryptominer attack.  We'll skip the quick summary and just point you toward the full story below, which you can reach by [clicking here](#the-macos-cryptominer-incident).  The important thing is that we have determined that **no builds were compromised**.\n\nWe really just want to keep making Dolphin better. Fortunately, despite these headaches and roadbumps, there are still quite a few notable changes to go through, so let's get to it.\n\n### **Notable Changes**[¶](#notable-changes)\n\nAll changes below are available in Release 2609.\n\n#### **[2606-91 - Android NetPlay](https://dolphin-emu.org/download/dev/master/2606-91/)**  by  **[tom-pratt](https://github.com/tom-pratt)**[¶](#2606-91-android-netplay-by-tom-pratt)\n\n[2606-91 - Android NetPlay](https://dolphin-emu.org/download/dev/master/2606-91/)\n\n[tom-pratt](https://github.com/tom-pratt)\n\nUnder the hood, our mobile and desktop builds are almost identical. Dolphin is simply Dolphin; the only difference is the UI that lays on top. Despite this, our Android release doesn't have feature parity with our flagship desktop builds.  A lot of features that are missing in the Android GUI that are present in the desktop GUI are mostly missing because they'd be difficult to implement *or* would have limited value on Android.\n\nNetPlay once fell into *both* camps.\n\nFor those unaware, Dolphin has [lockstep NetPlay](https://dolphin-emu.org/docs/guides/netplay-guide/) available to allow for online play in games that only had local multiplayer.  Lockstep NetPlay requires *perfect* synchronization between each instance, and thus Dolphin has to run in a deterministic mode.  This means forcing Single Core (or using a slower and even hackier version of Dual Core), setting the same starting time/seed, and making sure the same inputs make it to every machine.  Optionally, save data and cheats can also be synchronized for use on NetPlay. If done right, each instance of the emulator will stay synchronized with no further intervention, with Dolphin only passing inputs.\n\nAll of these complexities make NetPlay an enticing, but often cumbersome-to-use feature. And given that it would be annoying to create a good GUI for NetPlay on Android and it would make games run slower on already limited hardware, there was no rush to implement it on Android.\n\nIn the 2020s, the scales started to tilt in the other direction.  Android devices have gotten stronger and stronger, and though CPU governors and GPU drivers still confound us, many flagship devices can run games in Single Core just fine.  Additionally, [Jetpack Compose](https://developer.android.com/compose) for Android allows for easier and faster development of Android GUIs.\n\nWanting to share some of his favorite childhood experiences with his own kids, **[tom-pratt](https://github.com/tom-pratt)** stepped up to the challenge.  Using Compose, he built up the NetPlay Android GUI across several pull requests, with an initial bare bones implementation.  This made it easier to review and eventually merge, and was quickly followed up with more features, such as [controller port configuration](https://github.com/dolphin-emu/dolphin/pull/14750) for the host, that brings it closer to parity with the desktop implementation.\n\nAnd now, as of Dolphin 2609, NetPlay is ready for Android users!\n\nCurrently, Android NetPlay requires users to be on a standard network (Wi-Fi, Ethernet, etc), but work has been started on adding support for Wi-Fi Direct, which would allow Android NetPlay to function between nearby devices with *no* network, similar to how the Nintendo DS's local Wi-Fi play worked.\n\n*Note*:  Using NetPlay over *mobile data* is not recommended.  Even if you can get it to work, the packet loss and latency are not particularly suitable for lockstep multiplayer.\n\n##### **Cross Platform NetPlay**[¶](#cross-platform-netplay)\n\nCan Android and desktop Dolphin play together with NetPlay? Yes, they can! Players can mix and match devices with whatever they have, so phones and laptops can play together just fine! However, there are some limitations that must be kept in mind.\n\nMost full-size desktops use x86-64 processors, while most phones use ARM processors, and Dolphin uses different JITs depending on the host CPU. While our ARM64 and x86-64 JITs are very similar, they are not completely identical, and those JIT differences are likely to cause desyncs. Mixing and matching CPU architectures isn't a guaranteed failure though - whether these differences lead to a desync or not depends on what instructions games use and in what order.\n\nIgnoring the JIT problem, there is one more major source of potential desyncs:  *the Framebuffer!*  Games that use EFB Access and/or Store EFB/XFB Copies to RAM can get different results from different graphics drivers.  If these results mismatch *at all*, even if it doesn't directly affect game logic, a timebase desync will usually be reported.  Often this won't outright break NetPlay (at least immediately), but if the difference becomes big enough, the instances will diverge.  Given how *special* Adreno and Mali drivers are, there may even be problems when playing between different kinds of phones in those games!\n\nIn many games, none of these limitations will come into play. Even the differences in the JITs may not end up mattering. However, keep these factors in mind if everything is set up correctly and you're still experiencing desyncs.\n\n#### **[2603-394](https://dolphin-emu.org/download/dev/master/2603-394/) and [2606-121](https://dolphin-emu.org/download/dev/master/2606-121/) - Add XFB Resolution OSD Display** by  **[elyashue](https://github.com/elyashue) and [JosJuice](https://github.com/JosJuice)**[¶](#2603-394-and-2606-121-add-xfb-resolution-osd-display-by-elyashue-and-josjuice)\n\n[2603-394](https://dolphin-emu.org/download/dev/master/2603-394/)and\n\n[2606-121](https://dolphin-emu.org/download/dev/master/2606-121/)- Add XFB Resolution OSD Display\n\n[elyashue](https://github.com/elyashue)and\n\n[JosJuice](https://github.com/JosJuice)\n\nAs we have covered [a few](https://dolphin-emu.org/blog/2015/08/01/dolphin-progress-report-july-2015/#40-7138-pixel-aspect-ratio-adjustment-vi-scaling-fix-by-mirrorbender) [times](https://dolphin-emu.org/blog/2023/05/21/dolphin-progress-report-february-march-april-2023/#new-post-processing-shaders) [before](https://dolphin-emu.org/blog/2023/11/25/dolphin-progress-report-august-september-and-october-2023/#what-is-output-resampling), GameCube and Wii games were made with analog displays in mind, where [overscanning](https://en.wikipedia.org/wiki/Overscan) the edges of the screen away was the norm and the pixels didn't even need to be square! Since the only requirement was \"close enough\", GameCube and Wii games usually render *around* 640x480, but the exact rendering resolution will vary from game to game and even *scene to scene*.\n\nGiven this vague resolution reality, some users wanted a tool to know the exact resolution that a game was running at, but Dolphin didn't really have a way to tell them. The best existing method was to take a screenshot at *Raw Internal Resolution*, but that doesn't tell you what a game is doing right now, only what the game *was* doing when you took that shot. Plus, you have to check the screenshot to see the dimensions.\n\nThis simple change allows users to know in real time what a game is doing with resolution. Go to Config > On Screen Display and turn on \"Show XFB Resolution\", and the game's current resolution will be shown in our on-screen overlay. Now as games change resolutions, you can see exactly what is happening, as it happens!\n\nHere are some NTSC examples.\n\nThe GameCube and Wii use non-square pixels, so the aspect ratio is not defined by the rendering resolution. With this new feature, you can see that for yourself in games like [F-Zero GX](https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX).\n\nAs expected, 640x480 is prevalent across the GameCube and Wii library.\n\n640x456 is common on Nintendo-developed Wii games.\n\nThe NES and SNES had a vertical resolution of 224 lines. This legacy can be found on the GameCube and Wii in the many games that use the doubling of that vertical resolution: 448.\n\nBut ultimately, games can do whatever they want!\n\nGames can even change resolution during play! Rogue Leader uses 640x450 for normal gameplay. But its cutscenes are anti-aliased, which increases the memory needed per pixel, so cutscenes use a smaller framebuffer size of 640x304. This also gives these scenes a cinematic aspect ratio of 2.1:1 - turning a technical detail into a visual flourish is exactly what we've come to expect from Factor 5.\n\nAs should be pretty clear from the thumbnails, the statistic shown is specifically the resolution the game is telling the emulated console to output (XFB resolution), not what Dolphin is actually presenting. Dolphin's aspect ratio compensation, internal resolution multipliers, and output presentation after resampling are not demonstrated by this feature.\n\n#### **[2606-186 - Android: Route DolphinBar Balance Board to the Balance Board slot](https://dolphin-emu.org/download/dev/master/2606-186/)**  by **[tommywaaf](https://github.com/tommywaaf)**[¶](#2606-186-android-route-dolphinbar-balance-board-to-the-balance-board-slot-by-tommywaaf)\n\n[2606-186 - Android: Route DolphinBar Balance Board to the Balance Board slot](https://dolphin-emu.org/download/dev/master/2606-186/)\n\n[tommywaaf](https://github.com/tommywaaf)\n\nWhen Dolphin on Android was being prototyped back in 2012, Wii Remote support was easy - use Dolphin's Real Wii Remote feature to connect it through the device's on-board Bluetooth adapter. Simple. Unfortunately, the [Google Graveyard](https://killedbygoogle.com/) beat us to the punch. Android 4.2.1 made changes to the Bluetooth stack to improve Bluetooth controller support, and in the process [broke Wii Remote support](https://issuetracker.google.com/issues/36966083) *entirely*. Since Android 4.2.1, no Android device has been able to use Wii Remotes with their native Bluetooth connection. So when Dolphin on Android Beta became available to the public in 2013, there was no way to use Wii Remotes.\n\nFortunately, the Mayflash DolphinBar came to the rescue. By integrating its own Bluetooth radio and passing HID reports directly to Dolphin, the Mayflash DolphinBar could allow Wii Remotes to connect even on uncooperative operating systems and Bluetooth stacks. [In 4.0-8877, Dolphin Android gained the ability to connect to the Mayflash DolphinBar](https://dolphin-emu.org/blog/2016/03/01/dolphin-progress-report-february-2016/#40-8877-android-implement-support-for-real-wiimotes-with-the-dolphinbar-by-sonicadvance1-and-40-8886-android-add-ui-support-for-newly-implemented-dolphinbar-support-by-sigmabeta), finally allowing this tentpole feature to work on Android.\n\nBut something was missing in that update. The Wii Balance Board didn't work!\n\nAfter Nintendo's grand experiment to expand beyond the standard gamer audience proved tremendously successful, Nintendo noticed that many people were using its new console's revolutionary motion controls for regular exercise. Naturally, Nintendo responded with a peripheral made specifically for that: the Wii Balance Board. [Effectively four pressure sensors inside a big flat Wii Remote that you stand on](https://wiibrew.org/wiki/Wii_Balance_Board), the Balance Board itself is incredibly simple, but it opened the doors to fitness software so successful that the Balance Board was *genuinely* [used in hospitals for physical therapy](https://www.patriotledger.com/story/lifestyle/health-fitness/2011/02/10/nintendo-wii-helps-patients-rehab/37945537007/)! It was less successful outside of fitness, with Balance Board support in games like [Super Monkey Ball: Step & Roll](https://wiki.dolphin-emu.org/index.php?title=Super_Monkey_Ball:_Step_%26_Roll) and [Skate It](https://wiki.dolphin-emu.org/index.php?title=Skate_It) mostly receiving a \"meh\" response from players, though it did establish a strong niche in party games.\n\nSince the Wii Balance Board is basically just a Wii Remote, it was pretty trivial for Dolphin to support. Once Dolphin added the Balance Board device ID to its Real Wii Remote code, it connected just like a Wii Remote would. The same applies to the Mayflash DolphinBar. The Balance Board can connect to the Mayflash DolphinBar, and Dolphin can detect the Balance Board through it. Simple.\n\nOn Android though? The fun fitness-focused peripheral was able to connect to the Mayflash DolphinBar just fine, but *Dolphin on Android simply didn't look for it*, making the peripheral unusable and all of the games that required it unplayable! Where the code for the check should have been was simply `// TODO`. Oops.\n\nA simple four line change makes Dolphin on Android aware that the Balance Board exists, allowing the peripheral and the [135 games](<https://wiki.dolphin-emu.org/index.php?title=Category:Wii_Balance_Board_(Input_supported)>) that can use it to finally be playable in their balanced form for the first time ever on Dolphin Android.\n\nAt long last, you can use the Wii Balance Board with the device you take everywhere! It's *very* portable, as the Wii Balance Board only weighs as much as four laptops!\n\nIf you carry a Wii Balance Board in your backback, you can now play [Wii Fit Plus's](https://wiki.dolphin-emu.org/index.php?title=Wii_Fit_Plus) *[Bird's-Eye Bull's-Eye](https://wiisports.fandom.com/wiki/Bird%27s-Eye_Bull%27s-Eye)* whenever the fancy takes you! At school, in the library, even at the park!\n\n#### **[2606-215 - CMake: Replace the Visual Studio project](https://dolphin-emu.org/download/dev/master/2606-215/)**  by **[JoshuaVandaele](https://github.com/JoshuaVandaele)**[¶](#2606-215-cmake-replace-the-visual-studio-project-by-joshuavandaele)\n\n[2606-215 - CMake: Replace the Visual Studio project](https://dolphin-emu.org/download/dev/master/2606-215/)\n\n[JoshuaVandaele](https://github.com/JoshuaVandaele)\n\n[CMake](https://en.wikipedia.org/wiki/CMake) is a core component of Dolphin's build infrastructure. It's what's known as a \"meta build system\" - rather than building anything itself, CMake writes out the project files that other tools then use to actually do the building. This heavily simplifies our build system and allows us to easily support many combinations of operating systems and build tools. We can generate [Makefiles](<https://en.wikipedia.org/wiki/Make_(software)>), [Ninja build files](<https://en.wikipedia.org/wiki/Ninja_(build_system)>), [Xcode projects](https://developer.apple.com/xcode/) and more with just a single CMake script!\n\nHowever, there has long been an outlier in our infrastructure: Windows. While CMake supports generating [Visual Studio](https://en.wikipedia.org/wiki/Visual_Studio) projects on Windows, Dolphin has always been built with our own *custom* Visual Studio project files. Even after [CMake was introduced to Dolphin's repo in 2013](https://github.com/dolphin-emu/dolphin/commit/b75a805859507b99b39a77bdeae102b5721d3a45), it was never used for our Windows builds. The decision to continue using our custom Visual Studio project has placed a long-term maintenance burden on the project. By having two separate build systems co-exist simultaneously, we're effectively *doubling* the work involved when someone adds or removes source code files, all for *one* operating system.\n\nThis has now changed! Dolphin now uses CMake on *all* platforms, with our Windows builds being built with a Visual Studio project file that is generated by CMake. By having CMake handle the Visual Studio stuff for us, we were able to remove **over 12,000 lines** of Visual Studio-specific build files, making our lives much easier.  During this process, we also updated our Visual Studio version to the recently released Visual Studio 2026.\n\nBut how does all this impact users? Ideally, it shouldn't have any impact at all. The VS2026 update is the only thing that might affect anyone, as we are now using a newer version of the Visual C++ runtime. If you use our updater, it'll download the latest Visual C++ Redistributable for you automatically and all you'll need to do is press \"Continue\" on the installer. However, if you are updating your Dolphin instance manually, you may need to download and install the latest version of the Visual C++ Redistributable yourself. You can find a handy link [right here](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist#visual-c-v14-redistributable) (download the `X64` version, or `ARM64` if you are using Windows on ARM).\n\nOne thing of note: as part of this change, DSPTool is no longer being shipped with our Windows builds. You can compile this developer tool yourself if it is useful to you.\n\n#### **[2606-321 - Android: Add global settings search](https://dolphin-emu.org/download/dev/master/2606-321/)**  by **[Simonx22](https://github.com/Simonx22)**[¶](#2606-321-android-add-global-settings-search-by-simonx22)\n\n[2606-321 - Android: Add global settings search](https://dolphin-emu.org/download/dev/master/2606-321/)\n\n[Simonx22](https://github.com/Simonx22)\n\nThis change adds a search field to Dolphin's settings on Android. With our settings buried in submenu after submenu on Android, the ability to do a quick search for exactly the setting you are looking for is *so nice.* Just type part of the setting name, then tap a search result to jump directly to the right submenu.\n\n#### **[2606-97](https://dolphin-emu.org/download/dev/master/2606-97/)**, **[2606-132](https://dolphin-emu.org/download/dev/master/2606-132/)**, and **[2606-328](https://dolphin-emu.org/download/dev/master/2606-328/)** - **Android Rumble Fixes** by **[JosJuice](https://github.com/JosJuice)**[¶](#2606-97-2606-132-and-2606-328-android-rumble-fixes-by-josjuice)\n\n[2606-97](https://dolphin-emu.org/download/dev/master/2606-97/)\n\n[2606-132](https://dolphin-emu.org/download/dev/master/2606-132/)\n\n[2606-328](https://dolphin-emu.org/download/dev/master/2606-328/)\n\n[JosJuice](https://github.com/JosJuice)\n\n**[JosJuice](https://github.com/JosJuice)** fixed three rumble issues in Android that combined make rumble substantially better on that OS.\n\nOn Android, all vibration has to go through an API called [VibratorManager](https://developer.android.com/reference/android/os/VibratorManager). However, Dolphin's handling of it was wrong ever since [the 2023 input code rewrite](https://dolphin-emu.org/blog/2023/05/21/dolphin-progress-report-february-march-april-2023/#50-18920-rewrite-android-input-handling-by-josjuice). We would fetch the list of vibrator IDs correctly, but instead of passing a vibrator ID to the VibratorManager, we passed the index of the ID in the list. This happened to work on most devices because the only vibrator had both an ID and an index of 0. But users of Retroid devices weren't as lucky - the ID there is 1. Dolphin would try to request the vibrator that has ID 0, but since there was no vibrator with that ID, no vibrations would happen. [2606-97](https://dolphin-emu.org/download/dev/master/2606-97/) correctly passes the ID as we should, and vibration should work on all devices that support rumble. (Your Nvidia Shield TV won't rumble even if you want it to, because it lacks the necessary hardware!)\n\nAs of [2606-132](https://dolphin-emu.org/download/dev/master/2606-132/), Dolphin now uses the [vibration attribute](https://developer.android.com/reference/android/os/VibrationAttributes) [USAGE_MEDIA](https://developer.android.com/reference/android/os/VibrationAttributes#USAGE_MEDIA). This tells VibratorManager that our vibrations are for games and not touch feedback. With this change, users who disable touch feedback in their Android settings will no longer *also* be disabling all rumble in Dolphin. If you prefer to play your games without rumble, you can still unmap rumble in Dolphin's controller settings.\n\nGameCube and Wii games use a variety of different rumble lengths, but Dolphin used to ignore this on Android and vibrate for exactly 100 ms for any and all vibrations. The reason comes down to a mismatch in how Android handles rumble. A GameCube controller or Wii Remote starts rumbling when an \"on\" command is sent, and stops when an \"off\" command is sent. Games can delay the off command to get a longer rumble, or even switch back and forth between on and off to get a weaker rumble, but no matter what, the game has to send an off command eventually to make the rumbling stop. Android, on the other hand, requires apps to say up front how long a vibration should last. Because Dolphin can't look into the future to know when the game will send its off command, we used to simply tell Android to vibrate for 100 milliseconds. With [2606-328](https://dolphin-emu.org/download/dev/master/2606-328/) and newer, whenever a game asks for rumble, Dolphin tells Android to vibrate for *10 seconds*, and when the game says to stop rumbling, Dolphin tells Android to *cancel* the vibration. With this, GameCube and Wii rumble feels much closer to the original intent.\n\n### **This Release's Contributors...**[¶](#this-releases-contributors)\n\nSpecial thanks to [all of the contributors](https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2026-06-25&to=2026-09-22&type=c) that incremented Dolphin by 388 commits after Release 2606!\n\n### Brace for Impact! - The AI vulnerability reporting wave crashes into Dolphin[¶](#brace-for-impact-the-ai-vulnerability-reporting-wave-crashes-into-dolphin)\n\nIn 2024, we received one report about a security issue in Dolphin, and it was notable enough that it got [its own Progress Report section](https://dolphin-emu.org/blog/2024/04/30/dolphin-progress-report-february-march-and-april-2024/#50-21264-core-fix-ipl-device-m_cursor-overflow-by-josjuice). In 2025, we received zero reports. In 2026, we've received more than 10 reports, *and that's only so far*. Something has changed, and reading the reports makes it obvious: it's AI.\n\nLLMs and the tooling built around them have become better and better at finding security issues in software. A person who's interested in finding vulnerabilities can spin up AI agents and leave them running to discover issues on their own, and because of the subsidized prices that AI companies are offering for now, it's relatively affordable. This capability is both a good and a bad thing. On one hand, attackers can now find vulnerabilities more easily. On the other hand, defenders can *also* find vulnerabilities more easily, helping them keep software secure... But the number of vulnerabilities being found means a lot of time has to be spent validating, triaging and fixing them. In Dolphin, that all falls on our volunteers.\n\nAs with most things AI nowdays, not only are LLMs leading to more reports, but also longer, worse and outright incorrect reports. For example, curl has gotten so many bad reports that they announced [an end to paying out bug bounties](https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/), and later, [a vacation for the maintainers](https://daniel.haxx.se/blog/2026/06/15/curl-summer-of-bliss/). Google Chrome has vastly more resources and uses less confrontative wording in blog posts, but they too are announcing bug bounty changes, like [\"revising our program scope\" and \"shifting our program's focus to prioritize concrete proof that a bug exists\"](https://bughunters.google.com/blog/evolving-the-android-chrome-vrps-for-the-ai-era). Due to the sheer volume of security issues being found, they're even going to [make two security releases per week](https://blog.google/security/chrome-stronger-with-every-update/).\n\nAs for Dolphin, almost all the writeups we've received this year were clearly written by AI, containing an overkill amount of detail. But fortunately, nobody has sent us complete hallucinations (yet)! Every report contained some kind of valid bug, with some being more exploitable than others. Most of them were simple buffer overflows like the one reported back in 2024, and those are easy for us to understand and fix.\n\nStill, this is an order of magnitude more security reports than we've ever had to deal with before, and security bugs come with extra coordination constraints. Publishing a security bug means attackers can start trying to exploit it, so we want to minimize the gap between making a bug public and making a release that includes the fix. Unfortunately, this is basically the opposite of how we're used to working. Uploading a patch that fixes a bug reveals what the bug is, but we normally fix bugs by uploading a patch as soon as we have one and then waiting days or weeks for someone else to review it, usually without taking into account when the next release will be. This year we've tried a few different ways of handling this, like reviewing patches in private, starting a normal review process once the next release is a few days away, and in some cases (mostly for less serious bugs), doing things more or less as usual. So far we haven't settled on any particular process, but it's something we'll continue thinking about.\n\nMaking changes right before a release means the new code doesn't get as much testing as it otherwise would have, and we did unfortunately have issues sneak in from some of the bigger changes we made in response to security issues. [A rewrite of Wii NAND save stating](https://dolphin-emu.org/download/dev/79322e77b0fba09d5a0ae94f7e7f5a4ce3e33d50/) that landed in Dolphin 2606 broke loading save states in certain Wii games like Donkey Kong Country Returns (fixed in Dolphin [2606-292](https://dolphin-emu.org/download/dev/cd3ea814628d36939340ef67a6edb19e6b094279/) and 2606a) and broke loading save states while TASing any Wii game (fixed in Dolphin [2606-379](https://dolphin-emu.org/download/dev/8f674f574adfa69f1cbb1d4b98f3149c73b9bf8b/) and 2609). [Added validity checks for DOL files](https://dolphin-emu.org/download/dev/ee5eba860d999b2bf7ca1b5011877ab4a78f56d2/) that landed in Dolphin 2606a broke loading Wii Menus that had been patched with Priiloader (fixed in Dolphin [2606-308](https://dolphin-emu.org/download/dev/a795eaf01d832b22c7c6baa30ba11fdf643a9e29/)/[2606-325](https://dolphin-emu.org/download/dev/26d5cd38bd068f878b6e64ee8b705787b3a16164/) and 2609).\n\nSecurity issues will likely keep being found in the future, so to cap off, we have two important things to say:\n\n**If you've found a security problem in Dolphin:** To handle reports in an orderly way, we recently opened up [GitHub's vulnerability reporting flow](https://github.com/dolphin-emu/dolphin/security). Please use it to report any security bugs you find! While dealing with security reports does use up some of the precious hours we're able to spend on Dolphin, we prefer fixing vulnerabilities over letting them linger. If you have a bug that isn't a security issue, please report it on the [bug tracker](https://bugs.dolphin-emu.org/projects/emulator) instead.\n\n**If you're a Dolphin user:** Please keep your Dolphin install up to date! We had several security fixes in Dolphin 2606, many additional ones in Dolphin 2606a, and a few more in Dolphin 2609. If you're running a version of Dolphin other than the latest release or a recent development build, you'll have to assume it contains known security bugs, so don't open any untrusted files with it or use it to play NetPlay with untrusted people. Fortunately, so far we haven't seen anyone trying to maliciously exploit Dolphin, but we suggest not taking any unnecessary risks.\n\n### The macOS Cryptominer Incident[¶](#the-macos-cryptominer-incident)\n\nDolphin has supported macOS for [almost as long as Dolphin has been open source](https://wiki.dolphin-emu.org/index.php?title=Notable_Removed_Features_and_Support#macosbeginnings). As part of this support, we create official macOS builds for each development and release version and post them on our website. Because a Mac is generally required to create apps for macOS, we have a partnership with [MacStadium](https://macstadium.com/), a hosting provider that specializes in cloud-based Mac infrastructure. MacStadium provides us with access to a Mac mini through their Free and Open-Source Software sponsorship program, and we use it to produce builds of Dolphin, run ARM64 unit tests, and to perform automated graphics testing through [FifoCI](https://dolphin-emu.org/blog/2015/01/25/making-developers-more-productive-dolphin-development-infrastructure/#fifoci).\n\nWhen using a Mac as a server, the [Screen Sharing](https://support.apple.com/en-us/guide/mac-help/mh14066/mac) feature is very helpful for system administrators. Screen Sharing allows one to remotely connect to a Mac and control it as if it was actually in front of them. While servers running [Unix-like](https://en.wikipedia.org/wiki/Unix-like) OSes like Linux are often solely managed through a [command line](https://en.wikipedia.org/wiki/Command-line_interface), it is more difficult to manage a Mac with a command line exclusively. Screen Sharing provides full access to the macOS [GUI](https://en.wikipedia.org/wiki/Graphical_user_interface), making many administration tasks easier. Because Macs provided through MacStadium are physically located in a data center, Screen Sharing is enabled by default on their machines.\n\n#### **The Attack**[¶](#the-attack)\n\nOn August 6, Apple released macOS Tahoe 26.6.1. The [user-facing patch notes](https://support.apple.com/en-us/122868) were rather vague, with the only listed change being \"security fixes\". [More detailed patch notes](https://support.apple.com/en-us/148170) were posted a day later, revealing that a [bug](https://nvd.nist.gov/vuln/detail/cve-2026-65400) was fixed where Screen Sharing could be manipulated into allowing someone to connect to the machine *without valid credentials*. On affected macOS versions, someone could use this vulnerability to log in as an administrator on any machine that had Screen Sharing enabled, and wreak as much havoc as they wanted. This was a *critical vulnerability* for Macs being used as servers, as these machines often have Screen Sharing enabled for management purposes and may be directly exposed to the internet.\n\nNot long after the update was released, an attacker reverse engineered the patch and figured out how the vulnerability worked. They quickly took advantage of it and [started compromising any vulnerable machine that they could find on the Internet](https://cybersecuritynews.com/hackers-exploiting-macoss-screen-sharing-service/). First, they would use Screen Sharing to add their own SSH key as an authorized key for the `root` user, allowing them to administrate the computer via the [SSH protocol](https://en.wikipedia.org/wiki/Secure_Shell). Next, they would block the Screen Sharing port with a firewall rule to prevent others from re-compromising the machine. Finally, using their new SSH entry point, the attacker would deploy a [cryptominer](https://www.akamai.com/blog/security-research/cryptominer-anatomy-internals) to mine [Monero](https://www.getmonero.org/). Even though the vulnerability was already patched in an update, this attacker was able to quickly leverage it to spread a cryptominer to tons of unpatched Macs all over the internet.\n\n#### **Compromised**[¶](#compromised)\n\nUnfortunately, due to our macOS system administrator being busy with personal matters, this important security update went unnoticed initially and our build machine was not patched in time. [MacStadium blocked Screen Sharing in their networks after the attacks ramped up](https://docs.macstadium.com/CVE-2026-65400), but this was too late for us. On August 8, the attacker compromised our macOS build machine through the Screen Sharing vulnerability. The observed payload was the same Monero cryptominer found on other affected machines. We believe that this attack was *not* targeted specifically towards Dolphin, as all indicators of compromise matched other machines infected with the cryptominer, and we did not observe any indications of data exfiltration or other payloads on the machine.\n\nWe eventually noticed that the machine was compromised on August 15 and shut it down. Because we were unaware that there was malware on the machine from August 8 to 15, we were using it during that period of time to produce new builds of Dolphin. This includes development versions between 2606-294 and 2606-302, as well as the 2606a hotfix release. Since the attacker had full control over the machine when these builds were produced, we became *very* concerned over the possibility that they could have been infected with malware.\n\nThankfully, after manually analyzing the contents of each build, we can report that **none of the builds appear to be compromised with any malware**. We also ran each build through VirusTotal and found no evidence of anything suspicious. However, if you are running any of these macOS builds, we recommend that users should update to the latest development or release version, out of an abundance of caution. We would also like to reiterate that only our macOS build machine was compromised during this incident, so users on **Windows, Android, and Linux are unaffected**.\n\n#### **Remediation**[¶](#remediation)\n\nOn August 16, we requested that MacStadium support delete all data on the Mac and re-install macOS from scratch. Our macOS build machine was eventually restored on August 18. In total, it took 4 days to fully recover from the incident. After getting access to the fresh installation of macOS on the 16th, we decided to take the time to improve our security measures. For example, we no longer expose Screen Sharing directly to the Internet and now require an additional layer of security before it can be accessed.\n\nWe have learned many lessons from this incident, and it has also motivated us to thoroughly audit our infrastructure. We will be making further improvements in the future to reduce the risk of anything like this happening again.", "url": "https://wpnews.pro/news/dolphin-progress-release-2609", "canonical_source": "https://dolphin-emu.org/blog/2026/09/24/dolphin-progress-report-release-2609/", "published_at": "2026-09-24 06:29:06+00:00", "updated_at": "2026-09-24 07:01:53.613954+00:00", "lang": "en", "topics": ["ai-crawlers", "ai-safety", "developer-tools"], "entities": ["Dolphin Emulator", "tom-pratt", "Android", "Jetpack Compose", "macOS", "NetPlay"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/dolphin-progress-release-2609", "markdown": "https://wpnews.pro/news/dolphin-progress-release-2609.md", "text": "https://wpnews.pro/news/dolphin-progress-release-2609.txt", "jsonld": "https://wpnews.pro/news/dolphin-progress-release-2609.jsonld"}}