But we aren’t experiencing any other problems – I mean, no ads, no re-directs, no other characteristics but the errors that make our site not render on any version of IE. It renders fine in all other browsers. We also have VERY strong passwords and we went through all our files and found nothing suspicious.
While it’s true that simple “backdoors” often take the form of hidden admin users, generally complex backdoor code is simpler than that. It simply gives the attacker the means to any PHP code they like, usually through the use of the eval command.
I am just going off the eval command which is not part of wp. Ask your host if anyone else on the shared server has problems.
Steph’s site (also mine) was probably hacked over a year ago, and we’ve probably just been backing up/restoring the hack along with the site when we “fix” it.
We’re currently in the process of restoring the site again, with fresh copies of everything.
The only “issue” I anticipate is cleaning the db (it has over 2900 posts…at least 90 of which have an iFrame exploit in them….is there some automated way to remove these things from a MySQL db?
(@fedupsteph)
12 years, 9 months ago
We were using 3.1.4 despite the fact that it has some problems with IE9 when administrating. I worked around this by using an earlier version of IE when administering the site; the site had no rendering issues.
We upgraded to WP 3.2 a few weeks ago when it became available and our site would no longer render in various browsers (Chrome, Firefox, Opera, etc.); it was however, fine in IE9 and the former administrating problems appeared to be solved but having a good chunk of our audience unable to view the website properly was a problem. So, we reverted back to 3.1.4. This seemed to solve the issue.
The ‘fix’ supposedly came in with WP 3.2.1 so we upgraded to this – but now, our site will not render in IE (not in ANY version, going all the way back to IE6) but it does render fine in other browsers (Firefox, Chrome, Opera). In addition to the rendering being all screwed up, the following errors appear on our RSS feed:
Warning: Cannot modify header information – headers already sent by (output started at /home2/fedupusa/public_html/index.php(1) : eval()’d code:37) in /home2/fedupusa/public_html/wp-includes/feed-rss2.php on line 8
http://FedUpUSA.org The Con of the Century Fri, 15 Jul 2011 21:32:28 +0000 en hourly 1 http://wordpress.org/?v=3.1.4 http://FedUpUSA.org/2011/07/site-restoration-in-progress/ http://FedUpUSA.org/2011/07/site-restoration-in-progress/#comments Fri, 15 Jul 2011 21:06:57 +0000 FedUpUSA http://FedUpUSA.org/?p=6
and
]]> http://FedUpUSA.org/2011/07/site-restoration-in-progress/feed/ 0 http://FedUpUSA.org/2011/07/breaking-usa-ratings-put-on-credit-watch-negative/ http://FedUpUSA.org/2011/07/breaking-usa-ratings-put-on-credit-watch-negative/#comments Fri, 15 Jul 2011 05:17:52 +0000 FedUpUSA http://www.FedUpUSA.org/?p=18359
So far we have uninstalled and reinstalled 3.2.1 and then tried the same procedure with 3.2 and then finally, reverted back to 3.1.4. For a short time, the site renders properly in all browsers, but within hours it goes back to rendering all screwed up in all versions of IE. The error just continually regenerates itelf over and over and over again.
Is this a known problem? Can we fix this some how? Also, we never allow comments on our site and have always just used the ‘no comments’ selection on the Dashboard tools, but this selection seems to be gone and ‘comments’ seems to be part of the error that is appearing, in addition to some sort of issue with rendering ‘headers.’
And yes, we have done all this:
Our host is Host Monster. While we are not sure whether they are running the proper versions of PHP and SQL, the fact that we have now reverted to 3.1.4 and we are still getting the errors repeatedly, sort of indicates this doesn’t have anything to do with our host.