gsh1923

Thank you for this reply, the domain was without SSL and only http.

I also found that adding the following to my wp-config file also had a beneficial effect.

define(‘ADMIN_COOKIE_PATH’, ‘/’);
define(‘COOKIE_DOMAIN’, ”);
define(‘COOKIEPATH’, ”);
define(‘SITECOOKIEPATH’, ”);

Hi there.

Nice plugin, actually only ever needed to use the exclude post ID from sitemap, and was a bit gutted that I only learnt about this post-update when I saw a whole lot of pages in the sitemap that shouldn’t be there.

You are clearly new to all this but I reckon you’ll probably be causing a few headaches for unsuspecting people that didn’t try and find out why it looked like your plugin simply stopped working after it was updated.

Also on your sales pages for licenses it does not say whether your licence is yearly or not which I think is a bit of a problem.

Thank you for taking the time to explain what you mean, and I now see your point. I also think that I need to read a bit more about WP ROLES because from what you are saying it seems that only Admin’s will see the new default user role change and if that is the case then as you say, it doesn’t matter what is done to hide that, it’s going to be easy to over-ride.

Thank you both again.

Hi Jarret,

Thanks for your reply.

I understand your reply but not the bit where you say about “the least of my worries” because all of what you have said I am familiar with from a security side. If what you are saying is that once a user has admin access they can then pretty much do what they want to do on the website is that what you mean?

In our case we reverted the WP installation to a time that was safely before the vulnerability and then ran date checks against the files on ftp to make sure there were no out of sync last updated modifications that would suggest some WP admin code changes via a file manager plugin that could have been installed via WP Admin.

Perhaps you are saying that with an Admin permission account it is then possible to PHP execute queries via the browser that would add code injections to the WP plugins, is that what you mean? Or are you simply saying that because you are an admin you can recurse to WP plugin directories and add a piece of PHP that will have some kind of desired outcome for the hacker?

If you are not saying this then I think that having the ability to block out the changing of the “New Default User Role” so that the only way this might be changed is by accessing wp-config over FTP could have prevented this attack further.

It seems to me that in the scheme of handing over the keys to your website, the “New Default User Role” is a great target for hackers, and would seem a pretty easy thing to hack to and automate, but if it wasn’t there there would be nothing that hacking software could anchor to.

Sorry if I have missed your point, but I wanted to clarify my own position to make sure it had been understood.