Welcome back to the Patchstack Weekly security update! This update is for week 20 of 2022.
This week I will talk about the importance of communication and how to communicate security when it comes to security issues.
Starting from developers needing to communicate security bugs being patched and ending with how Patchstack partners are experiencing some great successes by integrating Patchstack’s WordPress vulnerability intelligence API into their products. I’ll tell you how and why later, in this week’s knowledge share.
But first, the week’s vulnerability news. Starting with announcing the winners of the Patchstack Alliance’s WordPress bug hunt contest, and a heads up about two unauthenticated SQL injection security bugs one patched, one not.
The Patchstack Alliance recently announced the winners of the WordPress bug hunt 2021. During this event, open-source security bug bounty hunters submitted over 1000 security bug reports and received over 17,000 USD in cash rewards.
In total, 11 security researchers won additional prizes. I wish everyone some happy hacking, or happy bug hunting, and look forward to a future contest with new prizes.
In other vulnerability news this week, the following two plugins have security bugs related to unauthenticated SQL injection attacks.
The first plugin luckily has a patch available. Users of the CP Image Store with the Slideshow plugin should upgrade ASAP.
It is unfortunate for me to share with you, that the WP Fundraising Donation and Crowdfunding platform plugin has not yet received a patch for an SQL Injection security bug at this time.
Sites running this plugin are vulnerable to attacks, and users may wish to disable the plugin until a patch is available, or ensure they have a WAF or vPatch layer to protect their sites from attacks.
How to communicate security?
This week, let’s talk about how to communicate security, and what kind of role it plays in the lifecycle of a security bug.
I will go over how developers can communicate security bugs to their users, and why that is so important.
Communication is critical
Developers for any project with customers must communicate. This is a requirement, and it starts with communicating what your project does. The project’s purpose, and functionality, are commonly shared using a README file.
Developers have used README files to communicate this information about projects since the mid-1970s! This is a long-standing tradition that helps users quickly learn important information like the purpose of the project, how to install the code, licensing information, troubleshooting, and more.
The WordPress.org plugin repository is no exception. They even have a guide on writing effective README files for plugin developers, with examples, a validation, and a web app . The web app will show you how your readme.txt file will look when parsed on the WordPress.org plugin repository.
README files are important for explaining the basics to users who are just learning about a project.
But what about people who are already using the project? How do you keep in communication with them? More specifically, how can you go about communicating the importance of each release, including security releases, of your project?
This is where a Changelog comes into play
Changelogs are a record of short details about each release of a project. This is where developers inform users “if you update to this version, this is what changes you can expect.”
Changelogs are an ideal place to communicate: new features, bug fixes, and more importantly security releases.
Why is it an ideal place? Especially true for WordPress, because users see a link to your plugin’s changelog when they see an update is available in the WordPress admin dashboard.
Users who see an update is available can make a single click to review all the changes you included in that release.
It is up to you to make sure your changelogs are clear and complete, so you communicate well. Keep a Changelog.org has some excellent pointers and tips for developers on what makes a good changelog. I won’t go into all of their tips, but I want to emphasize one point:
Be clear about security releases
Users need to know if a release includes a security patch. This will help encourage users to actually apply the patch for that version and avoids sites being compromised because the developer tried to hide a security issue by not communicating about it.
Does this happen? Yes. Some developers, mostly new developers, and junior developers try to hide security patches by not informing their users in changelogs, or by including a security patch along with many other changes and new features to the code base.
I’m speaking from experience. I have reviewed a lot of security bugs and more often than I would like to admit: the changelogs do not communicate security issues.
But, It gets worse, on some rare occasions, the vendors threaten public vulnerability databases, demanding the removal of the vulnerability details. Their goal is to censor or silence the fact their projects ever had a security bug.
This happened in the last week. A developer for an open-source project demanded we remove our entry for a security bug in their code.
The craziest part? It was a bug they patched already, they patched it two months ago. The sad part, their project’s changelogs are devoid of any mention of security issues, their users have no idea of the security implications if they do not update.
What is the result of not communicating security? Fewer users are updating to their newest, secure version of the plugin.
Here is the breakdown of their plugin’s active versions. It has been 2 months since they released the patch. Yet, a good portion of their users have not updated to the secure version:
Users are slow to accept these new updates because the vendor did not let them know of the existence of a security release in their changelogs.
This is not a good situation for their users to be in and could be improved easily. With a little humility, you let the users know about the issue.
Communicating security issues is not only important so people can update, but it is how you build trust with your users.
Using security communication goes beyond developers too! Patchstack works with organizations, helping them communicate security issues in open source components to their users, this greatly improves the trust-based relationship between the users and the vendors.
Global leaders like Plesk and cPanel integrating Patchstack’s intelligence into products and services like the WP Toolkit and even small local agencies like Toronto Canada’s Stunning Digital Marketing use Patchstack’s intelligence to help keep their customer websites up to date and free of insecure components.
Communicating security issues, so the responsible party can take action to patch, not only builds trust but prevents insecurity in a component from becoming a bigger problem, like a hacked website.
If reducing hacked websites, and increasing trust and communication with your customers is something your organization would like to look into doing, then please reach out.
Thanks and appreciation
This week’s thanks go out to the developers of the CP Image Store with Slideshow plugin. Thank you for supplying that patch, and let me extend that thank you to every developer who clearly communicates security bugs in your project’s changelogs.
Further thanks go out to all of the security researchers of the Patchstack Alliance, for reporting the hundreds, no, sorry over a thousand security issues to the Patchstack Alliance in the last year. Great job!
Finally, an extra thank you is extended to the Patchstack customers and partners, big and small, from cPanel and Plesk to Stunning Digital Marketing. Together, we are making the open-source web a more secure place.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update!