Cleansing WordPress… the hard way
UPDATE: Since writing this post, the issue reappeared. It is now apparent the exploit was of Plesk, a very popular control panel software that hosting companies use. See http://blog.sparktrust.com/plesk-vulnerability-exploited-in-the-wild/ (which includes links to a patch released by Parallels, the company responsible for Plesk). Also see this security advisory from Parallels.
Many moons ago, I ran a very small hosting company. A few years ago, I gave that up. Hosting is pretty cheaply or freely available these days, and the mental overhead of managing servers was not something I wanted any longer. All my customers moved on with one exception. Against my better judgement , I continued to manage one renegade server that was running a far out of date piece of software (pMachine) rather than turn away a customer (and friend) that needed my help.
Running a grep for the string “=prototype” located infected files that could be manually scrubbed of the offending code. Since the WordPress instances could not be updated due to an old PHP version (required by other sites on the server), I manually replaced timthumb.php with the latest in each theme that needed it as it had known vulnerabilities.
Since I don’t have direct access to the WordPress admin of these sites, I also recommended site owners install the WordPress Exploit scanner plugin that is being kept current, as of this writing. I also strongly recommended that any sites that do not require the old PHP version be moved to new hosting.
I’m documenting this here for my own lessons-learned, as well as anyone else that may encounter a similar problem.
Upgrading and moving sites is a little bit of work. Untangling a mess of malware is far more work.