Burnspot

Just adding that I see this toggling off when editing as well.

We are using the Enable JQuery Migrate Helper tool as well; it is a good “TEMPORARY” workaround. Looking forward to a Caldera update! ??

While the new version does finally work on one of my clients, I am not upgrading my other clients for now (going to revert that one client as well). It looks like custom coloring each individual icon might be more of a PITA now.

Update, logging in/out of admin a few times fixed it. Clue was that it worked fine for someone not logged into the site.

It FINALLY goes away after clicking the link to see the “what’s new” stuff Taco. Don’t like it, but I’m using the free version on all my clients, so guess I gotta put up with it.

I can’t get it to leave once I’ve clicked the “x” to close it. It goes away on the current window, but when you click to go somewhere else in the admin, it’s back…like a curse.

Edit – Seems to be an issue with 3.2.1; it really is sticking to every single admin screen no matter how many times I click to close it.

It looks like the QC side of things needs to tighten up a bit…

We lease the entire server and the different users are our clients. Our service provider’s been very helpful, but so far we haven’t found the ultimate source.

I’ll check out the users in WP…that’s one thing I haven’t done. One thing though is that in two instances now, we’ve had non-WP accounts pickup the bad WP files too, which is a bit odd.

Thanks!

Hi Matt, removing that folder hasn’t really stopped anything unfortunately. So far, I find new infections every morning when I wake up and check my email. The occurrences have definitely slowed down, plus I know what I’m looking for in visitor logs, so I can kill the problem the moment I see a LOCALRELAY alert pop-up in my email. I figure there’s something else in an account on the server that’s causing the problem. Unfortunately, we have around 90 accounts on the server and it’s come up clean in Maldet scans a number of times now, which leaves manual checking as the only way to track it down.

Just sent you another file from a relay alert that just occurred; Wordfence missed the file, but it’s definitely a bad one.

Funtimes…

I’ve sent it Matt, thanks!

@wfmattr – Our saga continues; however, I might have something for you to review. On another account on our server that showed signs of getting hit just tonight, I discovered a “www” folder that did not belong (the typical cPanel layout does not include a www folder within the “public_html” folder). The folder dates back to September according to the datestamp. Inside that folder lay a treasure trove of malware madness. To me, it looks like files used to setup false or appended WordPress files. The site in question is, for all intents and purposes, just a little-used companion site for one of our clients. So the additional folder would easily pass detection.

Wordfence, a free install on this particular site, did not detect this folder nor its files when set to scan beyond the WP directories. I created a zip of this entire folder before we removed it (I’m not sure I want to open it to double check the contents…in case it’s bad for this Windows system I’m using at the moment). Do you want me to send this to you for investigation? I suspect that this folder may be the root of all our problems as it’s something I’ve not seen before and some of the files lead me to believe it’s designed to infect WordPress.

@wfmattr – Matt, all of the sites I’ve been dealing with are on the same server, different users (we lease a managed WHM/cPanel server to host some of our business clients’ sites). I figured cross-pollination was at play. That said, I know of at least 2 clients with similar problems, but each are hosed on different servers (NetSol and private).

I missed the 2nd listing of the affected files WF where I could just restore the original (I usually just see that link or not in the original item)…I’ll look again next time I get positive hits (I do recall seeing yellow warnings for files I had just deleted due to red flags in the same report). Hopefully, the mis-labeling goes away in the next release. ??

The datacenter used the domlogs to trace the file changes and estimated mid-August as the time things started (the logs didn’t go back far enough to be certain).

As for the backups, our server regularly makes backups automatically; however, I went back a week and found corrupt files, so they were of no use. Luckily, I keep backups of the sites before I push them live so, apart from any subsequent updates, I have a base to work from for comparison of their wp-content directory.

If I find more php files that Wordfence missed, I’ll let you all know. At this minute, knock on wood, I think we have things settled as the visitor logs did reveal a few more things I’d missed (Localrelay alerts ceased upon their removal…alerts which started everything, lol). I won’t relax until tomorrow morning’s email is checked. ??

Yep techstacy, I already nuke all files except for the .htaccess, wp-config.php, and wp-content folders when starting cleanup operations. That’s usually good for a lot of it, but wp-content directory is a bit of a drag, especially with a lot of plugins with a billion folders (I’m looking at you NGG) that Wordfence’s report cuts off. Wordfence is good for finding a lot of the crap in the the plugins, but as I mentioned earlier, it’s often wrong about a file not being part of the plugin in question (when it’s an appended-to file), so there’s still a great deal of manual work. ??

I have noted your other methods. ??

Yea, I was suspecting a Google-side issue the more I read up on stuff. I always thought wp-admin was blocked by default by WordPress or Yoast…and Google’s not complained about that before this week.

FinestImaginary, that’s the same issue I have on the “fetch” test on Webmaster tools. Disabling WordFence “solves” the problem immediately and returns a clean render in Webmaster Tools. I should note that none of my clients are using anything beyond normal WF caching (i.e. no Falcon).