Welcome back to the Patchstack Weekly Security Update! This update is for week 35 of 2022.
This week’s vulnerability roundup will feature three plugins that did not receive patches for serious bugs found in their code recently and one plugin that patched an arbitrary options table update bug.
But first, in this week’s knowledge share, in which I will talk about the time we have to apply a patch. Tracking this as a metric of “time to patch” can help you quantify if you need more help with your security program or are attending to serious issues faster than the attackers can target your sites.
The time to patch
The time it takes to patch can mean the difference between a compromise or not.
When asked “how long does it take us to apply security patches?” every organization, every site owner, and every agency will have a different answer, but they should have an answer. That answer is the mean time to patch value.
Having someone responsible for applying patches, is a great way to be certain of this answer. Leaving this up to hope, is a dangerous choice.
Automatic updates make the time-to-patch as fast as it can be. I encourage site owners who have no one responsible for patching, to enable these automatic updates. We also have these available in Patchstack Developer and Business plans, and they can be customized to only update vulnerable plugins.
But, I have paid close enough attention to the data to know a good percentage of WordPress site owners opt out of automatic updates, and choose manual updates. This knowledge is most applicable to you, the manual updaters.
Calculating the time to patch is easy, it only requires record keeping. Everyone updates their software when they see updates are available, and the only step you need to add is to keep a record of how long since the patch was made available until it was applied.
The time it takes to apply each patch may vary based on the patch too. Feature-only patches will be a lower priority than security-related patches. Be sure to make a note when you keep the record if it was a feature patch or a security patch. If it was a security patch, make a note of the severity rating.
Scheduling patch days simplifies this process. Ideally, patch days should be once a week or every other week, the more frequent the better. Always leave time on your schedule for emergency patches though, a critical security risk should not wait more than a few days.
How fast do I need to patch?
Knowing how fast to patch, is based on another metric, the attacker’s metric of time-to-weaponize.
This “time-to-weaponize” depends on a lot of factors. The severity of the vulnerability is a key metric because high severity bugs tend to mean a successful attack results in a full site compromise.
Authentication requirements are also important. The necessity to have a valid user account on a website to perform the attack significantly reduces the risks for any site that only has trusted users. That said, if a WordPress site allows subscribers to create accounts, those are still accounts and some attacks need only subscriber access to perform the attack.
The Patchstack database makes a note of the authentication level needed for every WordPress related vulnerability reported in it. The Patchstack plugin can help you identify if any of your WordPress websites are running known insecure code while having a paid Patchstack App plan can buy you vital time via vPatches which can protect your websites from attacks until you can attend to applying the security patch on your website.
How fast are vulnerabilities exploited?
Ten years ago, I observed active attacks against open-source software. I tracked attacks and noticed a trend at that time – it only took a few days to detect a newly released vulnerability. After a few weeks to 2 months, it was guaranteed that an unauthenticated security bug would be widely attempted to be exploited.
These numbers are old, but the point remains – patch early, and patch often.
The most serious security bug I need to mention is an unauthenticated arbitrary option table update security bug in the alphabetic-pagination plugin. Sites running this plugin need to update as soon as possible.
Unauthenticated option table update security bugs are serious issues for WordPress websites. I will be talking about securely updating wp_options table values and their risks at the upcoming WordCamp US workshop Making security simple for plugin and theme developers in a few weeks, but if you can not wait until then you can read or listen about it on Patchstack Weekly episode 27 How to update wp_options securely
Now, on to some more grim news. The following three plugins have security bugs in them that are related to broken or missing access controls. Unfortunately in all three cases, the developers have not provided a patch yet and the projects may have been abandoned. This is a reminder that even if your organization’s time-to-patch is fast, you still need a patch to be made available from the developer. Otherwise, with no patch available, then your only option is to disable these insecure plugins and look for alternatives.
Thanks and appreciation
This week’s thanks goes out to the developers of the alphabetic pagination plugin. Thank you for pushing the patch which in your own words: Sanitizes early, Escapes late, and always validates. I like the cut of your jib.
Further special thanks to the WordCamp US organizer team, and the help they have provided me in the last few weeks as I prepare my slides. Not to mention all of the efforts they have put in to organize the event coming up in San Diego, California September 9th through 11th.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!