Dolphin Progress Release 2609

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.

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 . But 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 . We 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. Notable Changes ¶ notable-changes All changes below are available in Release 2609. 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 2606-91 - Android NetPlay https://dolphin-emu.org/download/dev/master/2606-91/ tom-pratt https://github.com/tom-pratt Under 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. NetPlay once fell into both camps. For 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. All 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. In 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. Wanting 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. And now, as of Dolphin 2609, NetPlay is ready for Android users Currently, 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. 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. Cross Platform NetPlay ¶ cross-platform-netplay Can 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. Most 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. Ignoring 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 In 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. 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 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 elyashue https://github.com/elyashue and JosJuice https://github.com/JosJuice As 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 . Given 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. This 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 Here are some NTSC examples. The 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 . As expected, 640x480 is prevalent across the GameCube and Wii library. 640x456 is common on Nintendo-developed Wii games. The 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. But ultimately, games can do whatever they want Games 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. As 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. 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 2606-186 - Android: Route DolphinBar Balance Board to the Balance Board slot https://dolphin-emu.org/download/dev/master/2606-186/ tommywaaf https://github.com/tommywaaf When 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. Fortunately, 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. But something was missing in that update. The Wii Balance Board didn't work After 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. Since 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. On 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. A 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. At 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 If 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 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 2606-215 - CMake: Replace the Visual Studio project https://dolphin-emu.org/download/dev/master/2606-215/ JoshuaVandaele https://github.com/JoshuaVandaele 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 However, 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. This 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. But 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 . One 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. 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 2606-321 - Android: Add global settings search https://dolphin-emu.org/download/dev/master/2606-321/ Simonx22 https://github.com/Simonx22 This 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. 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 2606-97 https://dolphin-emu.org/download/dev/master/2606-97/ 2606-132 https://dolphin-emu.org/download/dev/master/2606-132/ 2606-328 https://dolphin-emu.org/download/dev/master/2606-328/ JosJuice https://github.com/JosJuice JosJuice https://github.com/JosJuice fixed three rumble issues in Android that combined make rumble substantially better on that OS. On 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 As 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. GameCube 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. This Release's Contributors... ¶ this-releases-contributors Special 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 Brace for Impact - The AI vulnerability reporting wave crashes into Dolphin ¶ brace-for-impact-the-ai-vulnerability-reporting-wave-crashes-into-dolphin In 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. LLMs 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. As 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/ . As 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. Still, 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. Making 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 . Security issues will likely keep being found in the future, so to cap off, we have two important things to say: 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. 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. The macOS Cryptominer Incident ¶ the-macos-cryptominer-incident Dolphin 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 . When 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. The Attack ¶ the-attack On 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. Not 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. Compromised ¶ compromised Unfortunately, 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. We 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. Thankfully, 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 . Remediation ¶ remediation On 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. We 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.