Once, I had a problem that somehow someone managed to change files of my website without FTP or SSH credentials. Probably he got in through WP (probably it wasn't a 'he', but an 'it', a bot), we said after investigation.

Anyway, since then I'm using the WordPress File Monitor plugin, which mails me when files are changed. Now, when I update plugins or themes, I first perform a scan with the file monitor, then I update and then I scan again. The monitor gives an alert because of the update, and I remove it, because 'it's because of the update'.

Now I'm wondering, if WP is especially vulnerable when updating (for example, if it would be possible that the update doesn't come from the WP servers but from a hacker), then with this I open a leak in the security of my site.
On the other hand, if the updated plugins / themes work (which I always check), and it's only the files of the plugins that are changed (which I also always check), then it's -in my opinion- not so likely that someone hacked my site during the update.

Am I doing the correct thing here, or should I check better after updating?


What you're doing at the moment is okay, but there are far far better ways to do it.

The problem of man in the middle attacks here is that to insert yourself between wordpress.org and a server at a data centre is no easy task, so this scenario is very unlikely.


If you abandon the built in updater and instead rely on git repositories to pull down your data, then you can guarantee 100% that your plugins and themes are secure, even if a man in the middle attack occurs.

This is because of the reliability promises git makes. A git repository has an SHA-1 hash which represents its VCS history, and any attempt to 'meddle' or manipulate a git repository to add code will invalidate that hash, causing git to balk. Because of this, so long as that hash is good, you can pull code changes down from anywhere, no matter how untrustworthy thanks to the cryptographic guarantee.

Here's Linus Torvalds talking about trust and reliability in Git far better than I could explain:


Once you've moved to a version controlled setup, you can set your wp-content folder etc to read only for the servers Apache/WWW/Nginx user. Should a non-git repository be corrupted or compromised, you can simply re-checkout the repository in place and undo the damage.

Provisioning/deployment tools such as Composer would also be useful here.

Note that while Git would prevent a man in the middle attack by highlighting the data inconsistencies and providing evidence of tampering, it will only guarantee you have the correct copy of the source. It doesn't prevent the original developer from having a nervous breakdown and putting a DROP ALL TABLES command in their plugin. For that we have testing in sandboxes, proofreading/code reviews, and support forums.

  • And how secure is your git? how many times do you check that no one had inserted malicious code to your git? you just create another possible point of security breach if you use git only for this purpose. – Mark Kaplun Apr 4 '14 at 10:11
  • 100%, it's cryptographically guaranteed, if someone meddled with the repository at the remote end git would see the hashes mismatch and you would know that it's not secure, and be presented with warnings stating that the changes at the remote end do not match. As Linus said, to break this you'd need to crack SHA-1 and generate code that not only did malicious things, but caused a hash collision, both things that are not possible using current technology. – Tom J Nowell Apr 4 '14 at 11:15
  • As for the trustworthiness of the source itself, it's still more secure than using the updater, as it prevents a man in the middle attack, and it doesn't add a new source for attack because what you describe is already possible without the use of git. It may actually reduce the number of links by going straight to the Github repository used by the original developer. But a malicious developer is not something that can be overcome by anything you can do short of testing and proofreading manually – Tom J Nowell Apr 4 '14 at 11:19
  • when you say git, many people think github or services like it. To use github you need a user and a password, and we all know how good is the average password, and I assume that if I have the credentials to edit the code then git will not issue any alert that the code was changed (and if there is an alert who receives it, the deployer or the admin of the git?) . git the software by itself is not a security magic bullet, it can only be secure as the server it runs on and the front-end utilities used with it, which means it might be less secure then updates from wordpress.org. – Mark Kaplun Apr 5 '14 at 6:53
  • As for MITM, it is so unlikely that anyone who can do it will wait for an update process and not conduct the attack against the WP admin account, but even if it was, since the update mechanism uses https and hopefully verifies the certificate, the attacker will need to have control over one of the CAs which means the attacker is on a scale of a state and there is not much point for most people to try to defend themselves against states. I found the question a little silly in assuming that whatever breach there is, is caused in the most secure and hard to intercept part of the upgrade process. – Mark Kaplun Apr 5 '14 at 7:02

Your update is as secure as a weakest point in your update chain. Since upgrade are done via HTTPS since 3.7 a MITM attack against wordpress.org will be so hard it is not worth your time to even consider protecting yourself against it as anyone with the resources for that will get you in one way or another.

The more problematic points are actually the accounts in wordpress.org and your account on your server. You can protect your server but you can't protect against hacking of the wordpress.org accounts and inserting malicious code in plugins and themes that you use.

Only way to be totally sure what you update the site with is by manually uploading the files to the server after you have checked them.

Side note: if files on your server where changed without ftp or ssh access then your server is not secure enough and you probably not isolating your Apache as a different user and setting the right permissions on your directories.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy