Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter entilza72

    (@entilza72)

    Hi again – Refreshing the mobile friendly test page now shows the page as “Mobile Friendly”. I have changed nothing.

    I think this may have been a release error on Google’s end with their Mobile Friendly testing tool, and that error has now been corrected.

    I still get the “resources couldn’t load” warnings, but that is not impacting the Mobile Friendly status and I am not getting warnings about links/buttons being too close together, or things not fitting on the page. I think that is an unrelated issue.

    I’m going to mark this as resolved and chalk it up to “4 hours of wild code that escaped google labs” 🙂 Thanks for looking at it Ben.

    Ent.

    Thread Starter entilza72

    (@entilza72)

    Hi Ben – thanks for taking a look.

    “Other” error? – thanks google 🙂

    I’m the host. 🙂 And there’s no reason those elements can’t load, anyone/anything should be able to load them just fine. There’s no ‘bots file. I’ll take a deeper look, but it doesn’t make sense at this stage.

    I can see the banner is the problem with the width issue, as I expected.

    I’ll update and report back, but I suspect google’s changes to button spacing will still be an issue once the “other” errors are taken care of.

    Thread Starter entilza72

    (@entilza72)

    Clarification: when I said they “share a common DB”, I meant they connect to the same instance. They have different DB users, and use different databases on that host – so technically, the do NOT share a common DB.

    Ent.

    @useshots – mine was world read. Not good practice, but I believe these servers are jailed and it is not possible for a user to cd into your file structure, or read a file if they know where it is. I have changed to my local user rw (rw—- or 500) just in case.

    @rgbk – it occured with my 3.0.1 site. I logged a job over 24 hrs ago. The official line over a day ago was this was a WordPress exploit, not an mt problem. Clearly, that is incorrect.

    @khawkins98 – yeah, I figure I updated to 3.0.1 on that date.

    @traversal – my mt wp site has been crawling since day one. Often can take up to 10 seconds to begin serving. Strangely, non-wp content can begin serving in around 2 seconds.

    rgbk, it’s simple:

    If it was a plug-in, or wordpress, or any other common object, then we would be seeing this on other hosts too.

    No one is reporting this issue on any other host.

    Only Media Temple GS (Grid Service) customers are complaining. I think that pretty clearly points the finger at a vulnerability directly related to that host. Try googling for more info (as I did) and you will find very little info, except pointing to media temple’s site, blogs/tweets from media temple users, and this thread.

    I suspect customer databases are being manipulated without using wordpress (ie: the exploit is not occuring via wordpress), although I do note with great suspicion that all my wp php files were altered on 31 July. Possibly that was the WP 3.0.1 update though.

    Cheers,
    Entilza

    I agree, I think it is the host. I too run WP on mt and I had the same hack.

    I cleaned the site as per the instructions.

    A few hours later I checked my site again, and it had the same redirect. I checked the db again and lo – it was hacked again (either that, or the first round cleaning was not successful despite me checking). Cleaned again.

    This begs the question. How is this happening? No information is available.

    We are not seeing it on other hosts, so I am guessing this is an exploit due to Media Temple’s setup. I am guessing the exposure is occuring on the database, not via the WP application.

    Cheers,
    Entilza

Viewing 6 replies - 1 through 6 (of 6 total)