WordPress and Update Signing

Matt Mullenweg
5 min readFeb 14, 2017


What do you think of signing WP updates?

It’s a good idea and would be a nice additional precautionary measure for our update system.

But I heard WordPress doesn’t care about security?!

Nothing could be further from the truth. Everyone involved takes their responsibility very seriously, and the growth of WordPress has meant many thoughtful, hard-working people have gotten involved and think of the security of WP sites holistically, from every angle.

What is update signing?

Update signing is a way to verify that update code comes from the expected source. For WP, whenever your WP install gets an update, it would check the update against some code which says whether it really came from WordPress.org (that it’s signed).

So if my WordPress were hacked it would fix it?

No, it wouldn’t. It only checks that the update is signed, and that check could be ignored if your site was already hacked.

So it protects me if WordPress.org gets hacked?

No, it wouldn’t. If someone compromised all of WP.org they could legitimately sign a bad update, and send it out.

So what exactly does it stop?

It could stop a man in the middle attack, where someone modifies the update files on the network in between your blog and WordPress.org, or it could stop a situation where the part of .org that serves the update is compromised but the signing part isn’t, and someone decided to send out updates even though they know they’ll be rejected.

How many WP sites have been hacked that way?

As far as we’re aware, none.

Hasn’t the WordPress.org update server been hacked already?

There was a bug in the code found last year that was privately disclosed and fixed; however, it would have been difficult to exploit the bug without being detected.

How would you know if the update server was compromised?

It would be unwise to say exactly, but there are numerous internal and external ways of monitoring it, and notifying 24/7 staff if something happens. Additionally, many of the sites receiving the bad update would raise the alarm, as all major WP hosts scan their hosted sites for issues. We’re not banking on it never happening, we’re trying to make sure that if a compromise ever happens it’s fixed as quickly as possible so the attack surface is minimized.

What would you do if the update server was compromised?

We would turn it off really quickly, notify the world there was an issue, fix the problem, turn it back on, and notify the specific sites or hosts as able.

How many sites could get a bad update?

It would depend, but the best estimate based on hypotheticals is in the tens of thousands.

But wait, I thought 27% of the web runs WP?!

Given all the internal and external monitoring in place, it’s highly unlikely bad updates could be served for more than a few hours. Even if the update server were compromised for days, not every site auto-updates.

Are there easier ways to hack tens of thousands of WP sites?

Undeniably. A major security vendor recently said that 15% of the sites they fix each day are compromised because of TimThumb or Revslider issues alone, in addition to issues in third-party plugins and themes. For example, a widespread TimThumb vulnerability was discovered and fixed in 2012. To put it another way, you don’t need to break into Fort Knox when there are duffel bags of cash sitting around in unlocked cars.

What are the biggest issues to WordPress security?

A good order of priority based on impact would be:

  1. Sites not updating core.
  2. Sites not updating plugins.
  3. Sites not updating themes.
  4. Weak passwords, without brute-force protection or two-factor authentication.
  5. Hosts (professional or ad-hoc) not scanning and fixing sites.
  6. Hypothetical issues not seen in practice, which distract from the above existing priorities.

How did that guy want you to do update signing?

He wrote an experimental PHP port of a cryptography library. Add those several thousand lines of code to WordPress, plus some code to do the checking, then updates would be checked. Libsodium looks solid with a 27–0 vote, but the PHP port hasn’t had as many eyes on it yet.

Shouldn’t that be audited first?

Yes, and I offered to donate to the audit, just the day before he published the post.

But when the code’s ready and audited, couldn’t you just merge it pretty easily and be done?

No, you would also need to do some significant work on the server side to isolate the signing from the update server, so it’s worthwhile in the first place.

And then all WordPresses would be protected?

No, only the ones that get whatever new version of WordPress has that new cryptographic library and the update checking. We would need to continue serving updates without the signing checked to all previous versions of WordPress, because it’s important for them to get the update that fixes a real-world known issue rather than not get an update because of a theoretical attack.

But wait, if the update server was compromised couldn’t it still serve bad updates to older versions of WordPress?


So WordPress isn’t going to do update signing?

We will at some point; as said above it’s a good idea — can’t hurt, might help. There are, however, some more important security issues in front of it, that impact millions of sites in the real world, so we are prioritizing those issues above a nice-to-have, defense in depth effort. A good approach would be to build the server side first, because doing that properly, say with an HSM, is the difficult and important part; then get the packages signed; then test out verification in a plugin because we don’t want to break auto-updates; and then finally merge into core and set the client to reject non-signed updates. On the client side we need to pick a cryptography library, and get it audited.

If you don’t get what you want exactly when you want it from open source contributors, is it a good idea to vilify the people who were trying to help you?

Where I grew up, we say “you catch more flies with honey than vinegar.” Being involved in open source for more than a decade, you develop a thick skin. We’ll try to not let a decent idea be sullied by the messenger.

Why is this on Medium?

Seems to be the most popular place for rants like this. I also wanted to try out the famous Medium editor. 😀



Matt Mullenweg

WordPress, Automattic, Jetpack, WooCommerce, Akismet, Gravatar...