Welcome back to the Patchstack Weekly security update! It is the beginning of February and this update is for the fifth week of 2022.
This week I will share some of the core principles of open-source software development and how security researchers participate in them, as well explaining why open source projects should always have a vulnerability disclosure policy and what makes a good vulnerability disclosure policy.
This week in WordPress component patches news, there are three critical vulnerabilities I will highlight in three plugins: So let's get into it.
While there are some specific conditions needing to be present to perform the attack, it may be possible that this attack requires no authentication if they are met. So, It is recommended site owners update to the most recent release as soon as possible.
Patchstack's CTO Dave Jong wrote an excellent write-up about the Essential Addons for Elementor LFI vulnerability on the Patchstack blog.
The developer added a step to sanitize all user-controlled values before they're added to an SQL query. Users should update this plugin if they have it installed as soon as possible.
This is a severe risk and site administrators running Masterstudy LMS should patch ASAP and check their WordPress admin dashboard's user page for any unknown admin users which may have been added.
Open source has revolutionized the online world, but open source is not just free software it is an ideology that software should be open, affordable, transparent, and perpetual.
These are a few of the individual core tenants all open source projects should follow, because together they create an emergent property that open source software is projects of collaboration, worked on by anyone willing to put in their time, and improved upon in the process.
Open source means so much more than just free., and is not meant to be kept hidden away from others in a tower of ivory.
In last week's Patchstack Weekly Update, I commented on the many people who play a role in open source security. This week, I will dive a little more into the relationship between two of those roles: the open-source security researcher and the open-source developer.
The developers who embrace open source get a great benefit from the researchers who also embrace open source, as the projects get their most critical bugs (security bugs) reported and addressed freely.
Open source projects can benefit greatly when they make sure they have a formal guideline for reporting vulnerabilities. Which, most large projects have. These are called "Vulnerability Disclosure Policies", and take no more effort than writing them out. Then keep them up to date, either published on the project's website or including them in a file distributed with the source code.
Vulnerability disclosure policies have gained a lot of popularity recently, thanks to bug bounty programs. But, not all vulnerability disclosure policies have to be related to bug bounty programs, and you do not need to pay for bugs to have a policy!
The policy would be exactly where you would clarify this because they are for setting expectations and providing guidance to people reporting security bugs.
Communicating expectations and boundaries are important in life, work, and most interpersonal relationships. The above rules will help you get started with communicating to security researchers how they can best contribute to your open source project with reports.
This week's thanks go out to everyone who contributes to open source projects. This includes foremost the developers who contribute code to open source projects, but also the many people who play a supportive role like: documentation, project leadership, community builders, and of course security researchers who practice responsible disclosure.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update!