Welcome back to the Patchstack Weekly security update! This update is for week 8 of 2022 and will dive into several vulnerabilities and talk about vulnerability risks.
This week’s vulnerability news will have a lot to cover. One WordPress plugin had a vulnerability so severe the WP.org team initiated an auto-update for all installations. Another WordPress plugin patched 7 security bugs over 2 releases, and WordPress core had a vulnerability disclosed publicly before they could release a patch.
With so much news to cover about vulnerabilities, I think it is a good week to discuss vulnerability severity and how all vulnerabilities are not equal. In this week’s knowledge share I will talk about what makes some vulnerabilities more or less severe than others, and how you can use this knowledge to prioritize patching time.
Vulnerability news
In this week’s vulnerability news we will start with Updraft Plus. This plugin offers site backups and other functionality.
The developers of this plugin patched a bug this week which could have led to any user on the website (including subscriber role users) being able to create backups of the site which is convenient, but then they could download them which is a danger.
These backup files contain sensitive information like hashes of passwords making this vulnerability a high risk for sites that have open user registration, but low or no risk for sites that only create accounts for users they trust.
Site owners should check they are up to date with this plugin and may be surprised to find out they already are. This is because a rare event happened, the WordPress.org Plugin team enabled a global auto-update for this plugin.
Sites running this plugin would update regardless of the setting in the admin dashboard. This action is only taken when the WordPress.org plugin team believes there is a significant risk in allowing sites to continue running the insecure version of the plugin.
There is one drawback when this is done if for some reason your site was running an old version and you had turned off auto-updates for this plugin, then you got the upgraded whether you liked it or not.
The WP Statistics plugin developer patched a whopping 7 vulnerabilities in their plugin this week as well.
The vulnerabilities were either Cross-Site Scripting or SQL injection, and from my view, a cluster of patches like this indicates the developer was likely working with a security auditor.
Patch clusters like this are a great thing to see, and users of this plugin can be assured this developer has been putting in extra effort to ensure the plugin is safe and secure.
- WP Statistics plugin <= 13.1.5 – Unauthenticated Stored Cross-Site Scripting 1
- WP Statistics plugin <= 13.1.5 – Unauthenticated Stored Cross-Site Scripting 2
- WP Statistics plugin <= 13.1.5 – Unauthenticated Stored Cross-Site Scripting 3
- WP Statistics plugin <= 13.1.5 – Unauthenticated Blind SQL Injection (SQLi) 1
- WP Statistics plugin <= 13.1.5 – Unauthenticated Blind SQL Injection (SQLi) 2
- WP Statistics plugin <= 13.1.5 – Unauthenticated Blind SQL Injection (SQLi) 3
- WP Statistics plugin <= 13.1.4 – Unauthenticated SQL Injection
Finally, on Friday, February 18th security researchers publicly disclosed details of a reflected Cross-Site Scripting vulnerability in WordPress 5.9. This announcement was made on the Full Disclosure email list (a list known for public disclosure of unpatched vulnerabilities; which this notification was no exception to).
Although no patch is available at this time, this vulnerability is a low risk for the following reasons:
This requires an authenticated user (author or contributor level access) to perform the attack. And this is a reflected Cross-Site Scripting vulnerability.
This means, it will only trigger once and that one time will be the response to the request where the attack is performed. So, this vulnerability allows authors or contributors to only target themselves.
Ultimately this is more of a technical vulnerability, and maybe, just maybe if a user is tricked into injecting malicious javascript into a post’s excerpt field would it pose a risk. Not a very likely scenario and why it is considered low risk.
Low risk, of course, does not mean no risk. And, knowing the WP.org core team they are likely to have a patch for this issue released shortly. All users of WordPress can expect to see a new release made available soon, possibly by the end of the week.
In fact, deciphering what makes some vulnerabilities critical while others are low risk sounds like the right sort of topic to discuss in this week’s knowledge share.
Weekly knowledge about vulnerability risks
Not all vulnerabilities are equal in risk, most notably if a vulnerability requires high-level access to the system it is not the same risk as a vulnerability that requires no authentication at all.
There is a scoring system called CVSS (Common Vulnerability Scoring System) which was designed to help add this sort of context to every CVE or vulnerability you may see.
What is a CVSS score?
A vulnerabilities CVSS score uses metrics that answer common questions like:
- In order to perform the attack, what level of authentication is needed (if any at all)?
- How complex is the attack?
- Is there any user interaction needed to perform the attack (requiring social engineering)?
- And every vulnerability needs to have an impact, such as would this allow exfiltration of data, modification of data, does it block access to the data (such as in a DoS), or does it allow any number of these three?
CVSS then calculates up these risks and provides a score between 0-10, with 0 determining no severity (and really not a vulnerability) and 10 meaning there is a critical risk in the software which could lead to complete compromise.
Learn more about the CVSS score here.
You will see a CVSS score with every vulnerability recorded in the Patchstack database. When we can, we also try to add further application-specific context, such as with WordPress components we clarify what default user roles would be needed to perform the attack, something CVSS does not cover.
This information shows up as a statement like “Requires subscriber or higher role user authentication.” on the vulnerability description page.
It is important to understand the context of a vulnerability’s risk. Without that, you could end up needlessly stressing out and performing emergency updates when risk is simply not present, or worse yet, ignoring or delaying addressing a vulnerability because it seems “medium risk” when in fact your websites are at immediate risk based on the context.
Thanks and appreciation
This week’s thanks go out to the developers of the WP statistics and Updraft Plus plugins, for patching vulnerabilities in their code. Additional a preemptive thank you is extended to the WP Core developers, who are likely working on reviewing and pushing a patch for that self-reflected XSS vulnerability in WordPress Core.
And a surprise thank you is sent out to Plesk. If you had not heard yet, Plesk released the “WordPress toolkit” in their product recently, this toolkit has a security notification feature that is powered by none other than the Patchstack Database. Users of Plesk and CPanel, can enable the WP Toolkit and stay on top of vulnerability management for all of their WordPress websites right in their hosting admin panels.
Read more about Plesk and Patchstack partnership here.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update!
