We had a site affected by the recent (and well publicised) $zend_frame named Wordpress exploit. The site was running on a 3rd party server but the exploit had opened the server up and every virtualhost on the server was affected. On closer inspection approx 31k per magento store infected by the initial one-liner contained at the top of each PHP file.
The impact on the site was dramatic and it took the site off-line for a number of hours until we could clean the site. This was only a stop-gap of course until we could create a new server with an updated Magento and set of extensions.
The ultimate fix after a series of backups was the following command that uses sed to remove the PHP block associated with the exploit:
sed -i 's///g' `grep -l zend_framework * -R`
Adding a "time" to command resulted in the 31k files taking 3 minutes but it actually failed because there were too many files to process:
# time sed -i 's///g' `grep -l zend_framework * -R` -bash: /bin/sed: Argument list too long real 3m58.676s user 0m2.180s sys 0m8.493s
So, with a little further experimentation we reached this using find and a combo xargs pipe:
find ./ -name "*.php" -print0 -type f | xargs -0 sed -i 's///g'
And you only need the following to check to see if it worked:
find ./ -name "*.php" -print0 -type f | xargs -0 grep -l "zend_framework"
Other system sanity checks include:
find ./ -name "*.php" -print0 -type f | xargs -0 grep "base64_decode" | less
find ./ -name "*.php" -print0 -type f | xargs -0 grep "eval(" | less