scottmliddell

After trying all the available solutions to this, I finally found the problem. For reasons best known to my hosting company, the underlying MySQL database had no space left ( in fact is was over the available allocation ). After a bit of pain and migration to larger database with space available, the upgrade went fine.

Nothing on the file system was changed and it was a complete DB migration so I’m fairly sure that the “Another update is currently in progress.” was resulting from a failure into insert into a “full” DB.

Mark has confirmed that Wordfence has been updated to protect against this exploit.

I raised a ticket with Wordfence and sent them the infected index.php.
I did a test and Wordfence did pick it elsewhere (because of difference with repository files), just not, it seems, in index.php…

ok, so, I think I’ve found it and it was, erm, hiding in plain sight in the root index.php – a big nasty slug of encoded junk, I found it using the grep tip in the comments of this article…

https://blog.sucuri.net/2014/01/recent-optmizepress-vulnerability-being-mass-infected.html

it makes sense it was there as if it wasn’t in .htaccess it couldn’t be many other places, I suppose I didn’t look because the scan was clean ( fairly poor excuse! )

so, I still dunno how it got there and I really don’t know how WordFence doesn’t spot it, is there a way of submitting stuff to the WordFence guys?

cheers Lee, had done the recursive grep but not with any encoding, will try that, have just exported the whole DB too so i can search that!

Thanks all.

The effect seems to be exactly the same as the Avast article but with a different root cause, the redirect is even to the same IP, but I’ve grep’d the whole file system and there isn’t a file with the IP in it. Also, I’m not running OptimizePress, so there is another vulnerability that WordFence can’t see that isn’t from that plugin doing the same thing, it is mobile only and it seems only on 1st access…

I’ll keep looking!

Only have it on two sites and both have exactly the same behaviour.

I have the same issue on a couple of sites.

When I try to reauthorise I get kicked back to admin dashboard.

When I try to make any changes to settings I get kicked back to login page ( so I can’t enable logging ).

Any help very welcome!

Same thing just happened to me but I think I’ve got it all cleared up.

First thing, make sure you can manage your site via Google Webmaster Tools.

I did a full reinstall of WordPress and requested a review of the site affected – after that they were clean.

Still not found out what got hacked but it looks like it was in core WordPress but this seemed to clean it up.

If you look at your source look for Javascript chunks that have an eval in them that are heavily obfuscated, that’s what Webmaster tools spotted on one of my sites and I proved then I could remove it with a reinstall.

May not be the same issue as you yours but worth a go.

OK, I know what causes it now…

I had 3 categories + uncategorized and everything is fine…

If I add one more category, the dashboard only shows the latest post. If I delete the 4th category, the dashboard shows all posts again.

Anyone else seen this? Is it a bug?

I just switched to another YAPB compatible theme and all is well, the HTTP 500 is resolved so was definitely being caused by Grain 0.3 r2.

Would still prefer to use Grain if anyone know what’s wrong…