TL;DR – If you’re running a WordPress site and have enabled the JetPack plugin, quickly log in to your site’s control panel right now and turn off its “sharing buttons” feature. It’s a major security risk that could make your site blacklisted for sending spam e-mail. This vulnerability was observed on WordPress 4.8 / JetPack 5.0. If your website has a similar feature that can send e-mail to an arbitrary address, make sure you disable that as well.

More details follows.

Not too long ago, I’ve received a complaint from my web host admins that I’ve been sending too many e-mails. Naturally I’ve responded that I haven’t been sending e-mails through the site – mailing lists are handled via MailChimp and the site’s e-mail functions are handled via Gmail for Business (I’ve switched the domain’s mail exchange records to point to GMail).

Upon further investigation into the error logs, we found a number of rapid HTTP POST calls made into a particular article in the WordPress site. I find it quite peculiar since it’s not normal for WordPress articles to be the target of POST requests – only the XML-RPC or Admin Console endpoints are supposed to handle POST requests. Articles and Pages are typically read-only. However JetPack’s social sharing buttons adds a functionality for POST requests for sharing articles. Whenever there is a “share=email” POST parameter, JetPack would send an the page to an e-mail address specified in another variable. Essentially my page was exploited to become a spam-bot and spamming a number of QQ e-mail addresses. Interestingly, most of the rapid HTTP POST calls were made from IP addresses in China as well. That is, both the original spammer and the target were also from China.

I’ve narrowed down the root cause using a combination of the Stop Emails plugin (by Sal Ferrarello) and searching the HTML sources of the site.  The “Stop Emails” plugin disables all e-mail from WordPress and logs the request for sending those e-mail for later inspection. That enabled me to find the POST variable (the one named “share”) and the source articles that triggers the e-mail. Then I ran a text search for the variable name on an offline copy of the website using Sublime Text – I’ve downloaded the entire site, including cached pages. From the cached pages (courtesy of the WP SuperCache plugin), that “share” variable is handled by a piece of code called “ShareDaddy”.  Googling around revealed that “ShareDaddy” belongs to the JetPack plugin. That’s where I discovered that JetPack was the component that sent those e-mails. It was the “social sharing” feature that allows visitors to send an e-mail containing a link to the page. This is the feature that was exploited and hijacked to become a spambot.

Apparently as of JetPack 5.0, there was nothing that prevents this sharing feature from being scripted and send numerous e-mails from the web server. In response, I’ve disabled the entire “sharing buttons” feature and it seems that the e-mail sending stopped. The Stop Emails plugin seems to stop logging e-mail errors as well – at least as of this writing.

Frankly I doubt the usefulness of these social sharing functions being offered from a web page. One reason is that they are not always available for every site. Even if they are offered those “social media” buttons are never at “the same place” in the page, rendering muscle memory useless. I guess when sharing, most users would just copy everything that’s in the address bar and then paste it into whatever message (or social media post) they were composing. As for myself, I tend to use Safari’s “Share” button when sharing pages as e-mail or to social media since I know where to find that button (in the window’s toolbar) and I don’t need to worry about having to fill in a login box just to share something.

To recap, you will want to take a look of your own websites and disable all visitor-accessible functions that can send e-mail anywhere. If you really need this feature, at least you should guard that functionality with a CAPTCHA and some kind of rate-limiting. Otherwise you could limit the destination addresses of these e-mail forms — you might not want a CAPTCHA for feedback forms, since you might fear that it hinders visitors from sending feedbacks. But if the destination address is always your own e-mail – likely your support/feedback addresses – at least no one else will get spammed, and you can handle these by using filters.

Why should you care about this? Why prevent your website from being used as a spambot? Mostly to prevent getting your IP address blacklisted as a spam source — this would be detrimental to legitimate e-mail that your site may need to send. Furthermore it would help reduce the processing load in your servers — capacity that could otherwise be used for serving legitimate visitors. Getting blacklisted could also affect your search engine rankings — although I’m pretty sure that neither Google nor Bing would deny nor confirm that possibility.

Until next time, stay safe!

---