Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the TidBITS Content Network for Apple consultants.

Sparkle Vulnerability Real, but Exploits Highly Unlikely

While numerous readers love our regular TidBITS Watchlist feature, in which we track notable updates for key Mac software, many apps no longer require you to go hunting for the latest versions as they’re released. Instead, these apps use an open source framework called Sparkle to check for, download, and install updates automatically.

Unfortunately, some developers haven’t been careful enough with their implementations of Sparkle, and that could put your Mac at risk of attack. Researcher Radosław Karpowicz found that many developers use unencrypted HTTP connections to their servers, which makes man-in-the-middle attacks possible. So, a bad guy could sniff out your network connection, insert malicious code, and hijack your Mac via the compromised app without triggering Apple’s Gatekeeper security feature.

Sparkle itself isn’t really doing much wrong, since using unencrypted HTTP connections violates this recommendation in its documentation: “We strongly encourage you to use HTTPS URLs for the AppCast.” Regardless, the Sparkle team has already updated Sparkle to address the vulnerability. The only problem is that getting an updated app with the new Sparkle code requires, well, getting an update, which could expose you to the vulnerability.

But don’t panic! To exploit this vulnerability, an attacker would need to be on the same network as your Mac. So if you’re safely in the confines of your home or office with an Ethernet or secure Wi-Fi connection, you have nothing to fear. Just keep letting your apps update when they want, and as long as you’re on a private network, you’ll be fine.

However, if you often use public Wi-Fi networks without also employing a VPN to secure all your network traffic, you could be at risk if there was a sufficiently capable hacker at the next table. That risk would apply for any affected app that has automatic update checking enabled and is running. However, using a VPN will keep you safe and should be standard operating procedure when using networks outside your home or office. If a VPN isn’t an option, you can also disable automatic update checking in any apps that use Sparkle, and when an update arrives, download and install it manually. Since taking advantage of this vulnerability would require a targeted attack, it’s highly unlikely that it would be used indiscriminately against people who aren’t high-profile government or corporate officials.

If you are still worried, how do you figure out which apps are vulnerable? People have offered all sorts of Terminal commands to suss out vulnerable apps, but the best one I’ve found comes from RussW, a commenter on Mac Kung Fu. His solution checks to see if the app uses both Sparkle and an insecure HTTP connection, and then it prints out a list of those apps in a fairly readable format.

Unfortunately, there are smart quotes in RussW’s text that partially break the command (thanks to reader Joe for pointing that out), so I’ve created a Pastebin link with the properly formatted command. Follow that link, copy the command under RAW Paste Data, paste the command in the Terminal window, and press Return. Terminal will list the vulnerable apps in your Applications folder.


The list may be long, but those who use public Wi-Fi networks can use it to figure out for which apps automatic updates should be disabled until a new version is available. At that point, either update manually or re-enable automatic updating only when on a trusted network. Again, this is necessary only if you’re paranoid or are concerned about using untrusted networks. And as Security Editor Rich Mogull likes to remind us, if you’re in China or are being pursued by the NSA, your data is probably already compromised.


READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <>
Special thanks to Steve Kane, Jean-Claude Riedinger, d(arter, and
William Garrett for their generous support!

Comments about Sparkle Vulnerability Real, but Exploits Highly Unlikely
(Comments are closed.)

If you're going to copy and paste RussW's terminal command, beware of smart quotes. I suppose it depends on your browser and possibly system settings, but from the provided terminal screen shot, it looks like the author of this article (Josh) got hit by it. (I think the only ramification is that the output is not as useful.)
Josh Centers  An apple icon for a TidBITS Staffer 2016-02-15 14:16
Thanks Joe! I've updated the article to add a new Pastebin link with the properly formatted command. This is why we love comments and keep them open, because we have the best readers in the business.
Brant Merryman  2016-02-15 14:51
The pastebin command yields false positives in cases where the app does not specify an info.plist key for SUFeedURL at all. Sparkle has a way in which this can be provided programmatically within the app instead. For example, I am a developer working on VyprVPN for Mac. We have two versions of our update URL depending on whether you want updates from our Beta channel or Production channel (which you can change in the preferences). Both versions of our feed URL (and the relevant URLs in the app cast) use https, yet our app is flagged by the pastebin command. I noticed other false positives such as the app "Rescue Time". I just wanted to put this out there so people don't panic unnecessarily. Also, you should point out that under El Capitan AppKit disables http requests made with the NSURLConnection API, so users on 10.11 are safe in any case.
Adam Engst  An apple icon for a TidBITS Staffer 2016-02-15 16:29
Thanks for the details - sorry that command yields false positives. Do you know of a variant that won't?

Also, the original researcher said he confirmed the vulnerability in El Capitan.
Brant Merryman  2016-02-17 15:40
Unfortunately I don't know of a variant that won't yield false positives since if an app is using the delegate method to assign the feed URL, there isn't a way to easily parse this in a manner similar to the terminal command. Though certainly if the app directly uses SUFeedURL and you see http:// there, then its really vulnerable. Lack of a SUFeedURL would indicate that you don't have enough information to tell. The researcher suggests using Wireshark which works, but is hard if you aren't familiar with Wireshark.

I am not sure why Apple Transport Security would not protect against this, but I will check with the researcher and ask if he had to do anything to get around ATS. It really ought to be blocking retrieval using NSURLDownload which is what Sparkle uses to retrieve the app cast.
John Robinson  An apple icon for a TidBITS Supporter 2016-02-15 15:10
Found this item in the terminal searches from links in the article. What is it?

h t t p : / / www. p r o d u c t u r l s u p p o r t . c o m/ c g i - b i n / c s c g i . p l ? f = r e g x &p = E XU&v = 1 2 . 0 &o =M
Al Varnell  2016-02-15 19:08
Phil Stokes who is a colleague of mine has modified his DetectX utility to help identify such files. It clearly identifies those that might be false positives. Donation-ware at You must check the box in Preferences for "Check 3rd Party Apps for Sparkle vulnerability" to scan for those results.
Tom Saxton  An apple icon for a TidBITS Contributor 2016-02-15 21:03
The command line search says TurboTax 2012 through 2015 are all vulnerable. You'd think Intuit would have a better grip on security.
your terminal command did not check my Utilities folder. so I made this one up:

for app in /Applications/Utilities/*/Contents/Frameworks/Sparkle.framework; do plist=${app/Frameworks\/Sparkle.framework/Info.plist}; url=`defaults read "$plist" SUFeedURL 2>/dev/null`; if [[ $url != "https"* ]]; then echo ${app/.app*/} " and plist=$plist"; fi; done
David  An apple icon for a TidBITS Contributor 2016-02-16 16:49
You know, Sparkle's software has really been declining in the last few years.