Welcome back to the Patchstack Weekly Security Update! This update is for week 15 of 2022 and will talk about WordPress security history.
This week is a special episode. There were not many critical vulnerabilities to cover this week. So I will skip the vulnerability news and share with you, a lesson about WordPress security history over the last 18 years. My hope is that by knowing this history, we can learn some lessons along the way.
Of course, there were some interesting vulnerabilities this week. If you would like to check them out, please go to the Patchstack Database.
WordPress security history
Learning how the project matured
I love a good history lesson, and I hope you do too. History is how we can reflect on where we have come from, learn from past experience, and use that knowledge to help us make decisions in the present for the future.
So let’s get started back in May 2005, when WordPress.org’s blog has its first publicly announced security release.
2003 – 2006: Handling the first security bugs
WordPress security release (1.5.1.2) was announced in a post with the simple title: Security Update by Matt Mullenweg himself.
This post goes into detail about the risk, and how users can manually upload the WordPress core software by overwriting old files. Yes, you heard me right, I said overwrite the files, Updates at this time, were done manually by overwriting or editing files.
Imagine you are part of the user base at that time, manually updating files to apply security patches. This was just how it was done at the time, and we should be appreciative of how far the software has come since then!
A few years pass, and the development team continues to release security patches in this manner.
2007 – 2012: Updates get improved
The WordPress CMS software’s popularity was booming by 2007. The project had millions of installations worldwide, WordCamps had just started being organized and were already taking place all over the world. This popularity though wasn’t limited to just users, it also became popular with attackers as well.
2007 saw a spike of 40 new security bugs reported in WordPress core software based on the number of CVEs released that year.
The developers were kept busy patching these security bugs, and they started adding more security features. One of these new features was adding update notifications in WordPress 2.3. To be clear, it was just a notification, the update process was still handled manually as I described a minute ago.
It would take just over a year, with the release of WordPress 2.7. that an update button was added. Finally, users no longer had to manually upload and overwrite files, but they could now update their WordPress core version directly in the wp-admin dashboard.
This feature though still required users to log in and click buttons to run the update process on their sites. It progressed, but not enough.
I say this because in 2009 Matt wrote a post titled How to Keep WordPress Secure and it included a warning to users on the importance of updating.
Matt details that there is a worm (we call these bots nowadays) actively targeting a vulnerability in WordPress core. The vulnerability was patched by the core developers, in fact, it was patched 2 releases prior. But, sites were getting compromised, because the sites were running an out-of-date and insecure version of WordPress.
The bot is having success because users were not updating. Safety and security are just a few clicks away. But, those clicks, needs to be clicked before the bots could find the website.
Matt’s own words summarize this best:
Please upgrade, it’s the only way we can help each other.This plea, might not have reached everyone running a WordPress website. But, I believe it shows the project cared about security, it shows Matt cares about sites getting hacked and wanted it to stop, and it shows there was a problem.
Like most problems, it had a solution. But, that solution, wasn’t known in 2009, it would, however, arrive 4 years later in 2013.
2013 – 2016: The solution and growing the team
With the release of WordPress 3.7, site owners finally could opt-in to automated updates that would be performed in the background, these updates required no interaction from a user, once opted in. WordPress core could finally update itself and its components.
This, in my opinion, was one of the most important security-related features added to WordPress’s core codebase.
Users did not have to rush to apply patches, updates happened automagically, in the background. Most importantly, it meant updates happen faster than attackers could weaponize a newly released vulnerability.
Years passed and security bugs were reported directly to the WordPress security team. The developers continued to patch the reported security bugs at regular intervals. Every site that opted-in for automated updates meant fewer sites getting hacked.
The project even grew its security team, in 2015 announcing an official “Security Czar” role initially filled by Nikolay Bachiyski. Nikolay held this role for 2 years, guiding the project’s security efforts and helping developers handle security bugs.
2017 – Present, a new era: bug bounties
In early 2017, WordPress announced a new WordPress Security Czar: Aaron Campbell. Aaron stated he would pick up where Nikolay left off, and help get WordPress using a bug bounty platform.
Aaron was successful with his goal in only a few short months when WordPress joined the HackerOne program in May.
2017 also brought the most CVEs ever reported against WordPress, with 46 reported against the project it surpassed 2007 by 6 additional CVEs. But, a decade had passed. The project’s security approach had matured a lot, and those 46 CVEs were reported privately, through the bug bounty program.
While the patches were written by a team of developers. these patches were effortlessly making it onto WordPress websites worldwide with no interaction needed from the users. Sites were getting secured effortlessly.
This brings us to today. The WordPress project can be seen as having a mature security posture, WordPress security history has certainly come a long way from 2005 and manually overwriting files.
The project now benefits from a handful of key elements that make a mature security model. Some were known right away, but some were learned and added as the project grew:
- Clearly communicates security releases/issues publicly.
- Has a public point of contact to handle security reports.
- End users can easily apply updates, and opt-in to having these updates run without their interaction.
- Has sufficient resources to review and address security reports.
- Runs a bug bounty program, incentivizing researchers to look for security bugs.
It took years of continuous improvement, identifying pain points, and problems that need solutions. The project’s leadership and members continuously improved themselves, sort of like those automatic updates they added in 2013.
There is a caveat I should mention though, this was the history of WordPress core and not the whole WordPress ecosystem.
There are thousands of additional projects that make up the WordPress ecosystem. From themes and plugins, and now blocks and patterns, these projects still lack the level of security maturity that WordPress core has built for itself.
That is where the Patchstack Alliance comes in. A bug bounty program started in 2021, a bug bounty program for open-source developers who need extra help, assisting them with security bug validation, review, tracking, and reporting.
A guiding light to help even the smallest open-source projects, gain a mature security model without the years of trial and error.
The Patchstack plugin plays a role here too, it helps clearly notify users when they are running insecure components and allows them to update components automatically only when security issues are present.
This is something uniquely different from just knowing or applying an update if there is an update, something that is needed in the WordPress community.
I hope this WordPress security history lesson has been useful, insightful, or at least a little entertaining. Remember, the point of history is to reflect on where we have come from, and learn from the experience of ourselves and others, to help guide us in making decisions in the present for the future.
Thanks and appreciation
This week’s thanks go out to Matt Mullenweg and all of the WordPress.org teams for the past 18 years. There are too many of you to name, too many people who contributed and helped. I thank you all.
Special thanks to the WordPress.org website maintainers too. The blog posts from forever ago are all still accessible, I encountered zero dead links, and that provided me with a wealth of knowledge about the project’s history.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update!
