Welcome back to the Patchstack Weekly security update! This update is for week 4 of 2022.
In this week’s session, I will share a few high-risk WordPress vulnerabilities that were patched this week and provide an update on details about the un-patched WordPress theme vulnerabilities that Patchstack continues to deal with.
During this week’s knowledge share I will identify the many players in open source security. These are the people in many different roles, that play a part in open source security beyond the developers and the end-users of their open-source projects.
Patchstack engages with people of varying roles, who have different responsibilities and risks when it comes to protecting open source projects.
The WordPress plugin Adsanity developers patched a critical vulnerability this week.
The patch addresses multiple security issues, the most severe of which prevents a low-privilege user from uploading arbitrary files to the website.
Users are recommended to update to the most recent release of Adsantiy as soon as possible.
Numerous WordPress themes are affected by a lack of CSRF protection, which could lead to the activation or deactivation of plugins installed on the website.
The themes affected by this lack of CSRF protection are the same themes with unpatched vulnerabilities we had to release earlier this month as well.
Patchstack encountered the same issue of non-responsiveness from the developer since reaching out to them in early December 2021.
Ignoring our security reports is what led us to have to release details of the unpatched vulnerabilities publicly, we do this so site owners using these components can take action to address this security issue themselves.
The reports of WordPress vulnerabilities are complex, with many different responsible parties involved. In an ideal world, where everyone knows their role and responsibilities, then vulnerability reports go smoothly (as most of Patchstack’s reports do).
Knowing everyone’s role and responsibilities is the topic I will go into during this week’s knowledge share.
Security is everyone’s responsibility. In this week’s knowledge share I will be introducing the many players involved with every security report Patchstack handles, and what their roles, risks, and responsibilities are.
Risks: Reduced or Improved trust in their products. This really matters, if a developer ignores security bugs, their users will not trust that product, but if they are patching, even patching critical vulnerabilities (like the Adsanity plugin developers did this week) shows the users they can trust this developer to protect their users.
Responsibilities: The only one who can push the patch.
Risks: Wasting their time, imagine putting in hours of effort into identifying a high severity issue and having to wait a long time for a fix, or never seeing a fix get implemented.
Responsibility: Respectful disclosure process. Including sufficient information that the developer understands and can use to take action to patch their code, and a report free of blame or negativity.
Risks: Reputation hits from both customers and block-lists if their hosted sites are regularly compromised.
Responsibilities: Secure infrastructure, and assist customers who get compromised.
Risks: Reputation hits if a site is hacked. No one wants to visit sites full of SEO spammers, phishing scammers, or credit card skimmers.
A lot of hard work and effort can be ruined by one unlucky, unpatched vulnerability.
Responsibilities: Security “hygiene”, such as keeping website components up to date, using unique and secure passwords or 2FA for logins, etc.
Well, we are building the bridges of trust that will help improve security for everyone involved, what we like to call the Patchstack Alliance.
You likely already know Patchstack works with the security researchers, offering them a bug bounty and notoriety for reporting WordPress vulnerabilities in open source components through the Patchstack Red Team.
Patchstack then takes the vulnerability reports the red team provides, manually verify them, and only forwards the reports which are within the developer’s control to patch.
We include sufficient details needed for the developer to know how to verify the problem themselves, and can help point out what part of the code likely may need the patch.
Patchstack continues to help everyone else responsible for security as well, we have services that help the website owners and hosting providers as well.
With the information gathered from the Red Team, we provide web application firewall rules to protect websites that rely on open source code either at the site level (with the Patchstack App) or at the hosting level (with our hosting partnerships.)
This is the Patchstack Alliance, the bringing together of security researchers, developers, hosting providers, and site owners to help improve the security of open-source code.
If you are interested in joining this alliance, we would love to have you.
This week’s thanks go out to the supporters of Patchstack’s work. Hosting providers partners who pay for access to our vulnerability intelligence feed like (Gridpane, Pagely, or Plesk), developers who have paid for security audits or a featured listing on the Red Team bug bounty program, Patchstack Red Team members who support us with their time finding and reporting WordPress vulnerabilities, as well as the ever-growing number of individual website owners and agencies who are paying for the Patchstack App.
These are all the people who are not only getting protection from attacks but are supporting an alliance that has already and continues to improve the security of many open source projects.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update!
Thank you.
