Security concerns on using Update Manager without a dedicated site

I’ll mention (for the 3rd time) that you don’t need a dedicated site or server to run the Update Manager. If you don’t want to use it for other reasons, that’s fine – but, that’s still not a valid reason.

Yes, CP needs its own update mechanism. However, releasing plugins to be used in production environments without any ability to update is irresponsible. If you inadvertently introduced a vulnerability in the plugin code, the users would be stuck with it and have no way to even know it existed until they got hacked.


That’s right.
It’s the reason why I push them to WP repo or don’t publish them at all for official use as long we don’t have a updater on our end.

The thing with the server is… single or not, I need to manage it.

The security of either sub- or main install is a concern, along with one more place to check.
If my site, or any of the single sites, gets hacked so be it. But I don’t want to take the responsibility of potentially shipping some stuff to users due to an eventual breach.

Am I overthinking this?

1 Like

“Managing” the plugin doesn’t amount to much. You just add the data (which is almost a direct copy/paste from the readme.txt file,) and the Update Manager runs on its own without further intervention from you. :wink:

IMO, yes. However, if you’re not comfortable using the plugin, then that is a valid reason to not use it. I just wanted to be sure you’re not wanting to use it for an actual reason and not a perceived reason.

I don’t want to use plugins which aren’t going to receive updates from somewhere.

The Update Manager plugin is the best option available until CP has it’s own. It is one plugin you need to install and keep one endpoint per plugin which will receive updates which needs to be updated whenever a new version is released.


But you already have a website that you manage, yes? So, this is just a plugin on your website like any other plugin. No extra management, no extra servers, no extra burden. As long as your website is secure then the update manager is secure.

I got this working and use it to push updates to a few personal plugins that I use on all my sites. And if I can get it working then it really can’t be that hard. :slightly_smiling_face:

But I’m happy to add this one to that and link it to my GitHub repo and handle the installs. I didn’t really want to get into providing public plugins because I don’t know enough about them, especially re security. But this one looks simple enough and it is the sort of thing people will download, use once then delete. Also I can test out the whole directory submission thing too.

1 Like

I think his point is what you said here “As long as your website is secure then the update manager is secure.”
He doesn’t want the responsibility for other people’s sites possibly updating an exploit from his site that got hacked. I don’t blame him. I wouldn’t want that responsibility either, and I don’t really trust plugins with that Update Manager in them because of that.


Yep, fair enough. If that’s the reason I can see that. It was just the talk about needing yet another website/server that made us think he wasn’t understanding how it worked.


You are not thinking this 100% thru :grinning:

O don’t run a cc or wc shop myself.
Thus plugin install means plugin installed for nothing.

Same for contact form, maintenance plugin.
First I don’t need, second I need every couple months only.

And no website is secure.

Now if it happens to be hacked to me I’m liable.
If it happens to wp they’re liable.

That’s a huge difference of how much responsibility you’ve to take.
Developing a plugin is already work enough

For me, it’s pretty clear why it’s a bad idea and I’d prefer asking the user to install the git hub updater plugin which at least takes off security/responsibilities concerns and also doesn’t require me to install said plugin

1 Like

Yes, I understand your view.

But it’s interesting to note that Joy says this:

Whereas I would never install a plugin that says this:

:thinking: It makes me think the current arrangement has some problems.

A doubt rises here… does your updater actually ship updates it gets from git?
Because you say only the readme needs to be changed, so is it that the actual code is pulled from git and shipped to the client?
It just does that based on readme info you change in the server?
Thus the risk of shipping compromised code is not present?

Or does it ship the code you have on your server?

I never used your plugin so I’m not sure how it does that. Of course if it gets the update from git itself it’s much less an issue than I thought (apart of the fact that I wouldn’t install the plugin I don’t actually use, like say maintenance mode or this cc plugin checker which basically assumes a a wc/cc install)

Serve updates from GitHub, your own site, or somewhere in the cloud.

I guess it does… so it’s of course not a concern of website being hacked.
I missed that part somehow in the readme.

No, it only handles the request. It doesn’t ship code necessarily (it only does if you have the file location actually on your server, but most people would have it in a GitHub repo). So the plugin is checking with the Update Manager to see if the version has changed. If it has, it notifies the user that a plugin needs updating. When you hit update it pulls the file from GitHib down to the user.

1 Like

I was thinking about how a hacker could misuse this. I guess they would have to get admin access to your site, first change the download address to somewhere with a corrupted version of your plugin, then change the version number so the update was pushed through but came from a different location.

Yeah, my concern was about if it gets files from your site.

The scenario you describe thou is probably also possible if they get that sort of access (which would also be necessary to actually compromise files).

I have the admin area of the site that runs Update Manager locked to my fixed IP address. Everyone else gets a 403.


In order to cause problems, a rogue actor would need to have admin capabilities on your site in order to re-point the data to a malicious file via the admin interface.

Of course, if someone has direct access to your database, they can do it that way… but, if someone has direct access to your database, then Update Manager would be the least of your worries. :wink:


If you mean legally “liable,” that’s not true. That’s the point of making clear that no warranty is provided with the plugin. It immunizes providers from liability for unintentionally causing harm.


Indeed, I didn’t even know gpl disclaims all warranties or liabilities unless required by local law (which I have no idea what it would mean, but I assume “local law” is like “distribution of prohibited content” or else stuff prohibited in an eventual local law, which a plugin would rarely do)


Hope this solves your problem @smileBeda!

I’ve just pushed a tweak in the UpdateClient library in the secured branch.
In the client you can now configure the beginning of an URL that is checked against the URL that is returned from Update Manager.

So if you configure

const SECURE_SOURCE = '';

and someone hijack Update manager and send an url like https://mal.ware/ no update is shown.

Note that the check is something like this:
strpos($update_url, SECURE_SOURCE) === 0

I’ll be very happy if you can give it a try :wink:


Yes, this works for me. You can either put in the first part of the path eg

const SECURE_SOURCE = '';

or the full path…

const SECURE_SOURCE = '';

I am downloading this one from my own server, but if you were using:

it would certainly lock it to your own GitHib account.

I was just thinking through what would happen if you do ever need to change this yourself? You can’t push through a change to the update client from a new location to update the new location. I guess the new location would get pushed through in an update, and then future updates would come from the new repo (I’m just imagining the scenario if updates do eventually move from personal repos to some CP central server).

Nice work! :clap: