Pipdig plugin contained malicious code



There is no way to understate the severity of what Pipdig did. They inserted obfuscated code into a plugin that is included with all their themes (so I guess it’s like a site-specific plugin) that was installed we can presume on thousands of their customer’s websites to DDoS a competitor. The targeted competitor asked Wordfence not to be named so I’m not naming them here although they are still listed in the Jemjabella blog.

The malicious code also had a backdoor with the ability to silently change administrator passwords of Pipdig’s clients at any time, if instructed to using a text file on pipdig’s website.

The malicious code could also wipe a website’s entire database if the file at https://pipdigz.co.uk/p3/id39dqm3c0.txt contained their website’s url. This may have been used to destroy sites that pipdig found using pirated themes, since their license does not allow re-use or distribution (this is not the norm, obviously, most ready-made theme developers license them under GPL). In any case it is pure evil - who’s to say for example that the authorised website administrator was the one to wrongly install it? Maybe an honest mistake was made.

Another part of the code would search for and replace links to blogerize.com with Pipdig - this is clearly an attempt at SEO by generating legitimate back-links, as well as stealing traffic directed to this competitor.

Another part of the code would run a dns lookup on the site’s host name, and if found to be hosted by lyricalhost.com would then phone home to Pipdig, presumably so they could harvest their customers by bringing them across to their own hosting (or sending those customers to a host they are colluding with).

Finally the plugin would deactivate a bunch of other plugins from other developers, including Hello Dolly. I’m not entirely sure why, but could be to artificially create the impression that the newly installed pipdig theme is faster then whatever the client was previously using.


The plugin was self-hosted. However pipdig does have a number of plugins hosted on wordpress.org.

A simple reactionary measure, that we might see (might not) would be to see pipdig banned permanently from wordpress.org. But a more pertinent question is this: should plugin updates be allowed only through an official channel? I think that the answer is yes - of course a developer could still program in a backdoor to update from their own server, that’s literally impossible to prevent, and if a theme developer really wanted to they could just put all their code into functions.php instead - however a policy could be made to ensure that anyone found circumventing an official plugin update path would find themselves blacklisted from ClassicPress.

Obviously I’m thinking about the future, when ClassicPress has its own plugin repository, a time when the Wordpress plugin repository would be disabled by default. The level of plugin safety will always be a compromise, it’s unrealistic to expect a team of experts to peer-review each plugin and update before publication, however it’s totally unacceptable to see plugins from an individual or company who were proven to be distributing malware being left up.


Yes, this is certainly a serious breach and it raises lots of questions, eg could CP prevent this from happening in the first place, and what would we do if it does happen?

I was thinking about this “peer-review” idea today. Since CP is marketing itself as a business-focused CMS and saying they will put the emphasis on security, I’m wondering if it may be possible to somehow assess a limited number of plugins. We can’t do all of them of course… but maybe there could be a small range of necessary plugins that have been examined and given the CP “stamp of approval”.

I have no idea if this is possible or how it would work, but I would certainly make a point of only using the “CP-approved” plugins on all my sites. Obviously if people want to install whatever other plugin they find they can do that, but it would be at their own risk.


Yes interesting the language that you use there. I hesitated to say “breach” myself since, well, PHP is fully capable of doing all kinds of malevolent doings in the wrong hands. And giving the benefit of the doubt, this kind of breach could potentially be the work of a single disgruntled employee (although if it was the parts of the code that “phone home” would point to an external server). You get my point, pipdig has a right to defend themselves, perhaps their server was hacked or something. But assuming that they can’t produce any compelling exonerating evidence it’s certainly a breach of trust, and of reasonable expectations that their customers/clients have, and (assuming no defence and after going through due process) they certainly have no business in having their plugins hosted on an official platform.

1 Like

We discussed this on Slack last night, and this morning I updated the plugin directory design notes. One of the most important issues is that we don’t do anything that will tempt someone to point lawyers in our direction - hopefully @timkaye will have some comments later.

One other thing to note: we’re building a directory, not a repository - there’s been much discussion about that on other threads.