Welcome back to the Patchstack Weekly Security Update! This update is for week 25 of 2022.
This week’s knowledge share will include some tips for WordPress site owners on what to look out for when choosing secure plugins.
I will also share vulnerability news, with one critical issue to discuss which may have already been patched, as well as highlighting the concerning trend of security bugs not receiving patches.
Three tips for choosing secure plugins
How can you be sure that the plugins you choose (or are already running) on your WordPress websites are safe to use, worthy of your trust, and have a mature attitude toward security?
These tips will help you answer those critical questions. They will also help you avoid the plugins that may be hiding security patches or plugins which may have been abandoned.
1. Check if the developer is active in the project
Developers for open source projects are giving their time to build a project that is likely available at no cost to the users.
An open-source plugin could be written in someone’s spare time, or be someone’s full-time job, and both are great.
What you want to avoid, is a project that has been abandoned.
Here are some places to look to see how active the developer(s) are in the project they released:
- Last commit time
You can see this on the WordPress.org repository description as “Last updated”. - Check support forums activity
Another check that’s easily available in the WordPress.org repository, under the “Support” tab. Click on it and see when the last support ticket was responded to (keep in mind, a response is what you’re looking for, abandoned projects will have lots of people asking for help, but no recent responses from the developer.) - Check the project’s website
Since not all WordPress plugins are in the WordPress.org repository, you may want to check if the project has an active website or social media page. They may even have their own support forums or an email list where you can receive updates.
2. Look at how the developer communicates security
I talked about the importance of Communicating Security before, and included an example of what happens when developers hide security patches.
Spoiler: it means fewer people patch or it takes longer for them to apply the security patch. Which is not a good thing.
Vendors with a mature security practice communicate security issues clearly when they come up.
For example, Microsoft has an unofficial “Patch Tuesday” and WordPress.org writes a Security Release blog post for every security release.
Most open-source and smaller projects can show they have a mature security practice by simply including security patch notes in the project’s changelogs.
You can check the plugin’s changelogs in the WordPress.org Repository easily by clicking on the “Development” tab.
If the plugin is available through another marketplace, such as Envato, you can still find a changelog, but it may be at the bottom of the plugin’s description, or on the plugin’s website or GitHub. Do a little digging, and bookmark the page when you find the project’s changelog.
It will be worth it, so you can frequently check back for security issues.
3. Check if the project has a vulnerability disclosure policy
A vulnerability disclosure policy is the peak of security maturity.
These policies outline how security researchers should communicate with the project if a security bug is found.
Projects that have a vulnerability disclosure policy receive security reports in private and have the resources to handle these reports.
This is extremely helpful for security researchers because it lets them know who (and how) to contact about a security issue. It also sets the expectation that the developer wants to hear about these reports, so they can take action to protect their end-users.
Without a vulnerability disclosure policy though, a lot could go wrong.
Researchers could just report the bug publicly, citing no public point of contact. If the researchers report the bug to the respective repository, the project could be removed until a patch is put in place. This harms both the websites that use the project and the project’s trustworthiness too.
Vulnerability news
Ninja Forms Unauthenticated Object Injection
This week, the Ninja Forms developers patched a critical security bug that could have led to attackers being able to run methods for any Class or Object within a website’s code base.
This is limited code execution, but still very dangerous.
The developers reached out to the WordPress.org plugins team volunteers and informed them of the high risk this security bug could pose. The volunteers are WordPress.org agreed the bug was high risk and warranted a forced update on all sites running insecure versions of Ninja Forms.
These forced updates are rare, but when a critical security bug that could execute code with a single unauthenticated request is found in a plugin on one of your websites, you’ll be happy the process exists.
Unpatched vulnerable plugins
Most security bugs in WordPress components receive patches, but not all. When a developer abandons a project, then nobody is around to provide security patches.
This is unfortunately may be the case this week for the following WordPress plugins, which were closed (temporarily) until their plugin authors are able to review their code and apply security patches.
If you are using any of the following plugins on your website, you may want to disable or remove them – until you have time to find an alternative plugin, or until the developers provide a functional security patch.
Mitsol Social Post Feed – Authenticated Stored Cross-Site Scripting (XSS)
Popup | Custom Popup Builder – Unauthenticated Denial of Service (DoS)
Team Manager – Multiple Authenticated Stored Cross-Site Scripting (XSS)
Sharebar – Arbitrary Settings Update to Stored XSS via CSRF
Pagebar – Arbitrary Settings Update via CSRF vulnerability to Stored XSS
Button Widget Smartsoft – Cross-Site Request Forgery (CSRF) vulnerability to Cross-Site Scripting (XSS)
Thanks and Appreciation
This week’s thanks goes out to the developers of the Ninja Forms plugin, thank you for pushing that security bug patch. And a special shout-out thank you to the WordPress.org volunteers, who reviewed and approved pushing the update for the over 1 million Ninja Forms plugin website owners out there. That certainly protected many websites from compromise this week.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!
