Welcome back to the Patchstack Weekly security update! This update is for week 51 of 2021.
See the 49th Patchstack Weekly and the 50th Patchstack Weekly here.
This week’s news may sound like deja-vu, as I will cover more of the same topics as I did last week. Log4j is still a leading security concern, and the project’s developers have released yet another security update, this time to address a Denial of Service concern.
I will also once again discuss WordPress plugins with options table update vulnerabilities reported in them … the difference this time is, there is no patch.
In this week’s knowledge share, I will compare the log4j project’s quick security response, to that “not to be named for your protection” WordPress plugin that has an options update insecurity that has not yet been properly patched.
This, lack of response, is an unfortunate reality security researchers sometimes face. I will share with you the inside knowledge on what happens when WordPress plugin or theme developers choose to ignore security reports.
Vulnerability news
In this week’s vulnerability news, there are no high-risk vulnerabilities to report in WordPress components. This may sound like a good thing at first, but I would like to let you in on a little insider knowledge which may sour that cheer.
The Patchstack Alliance has a vulnerability backlog, this backlog includes vulnerabilities that have not been patched due to non-responsiveness from the developers.
We notified these developers regarding vulnerabilities in their code, including one case of an options table update vulnerability, but they have not pushed a new release in the last month, and in some cases simply stopped responding. I will refrain from naming the plugins, themes, or developer’s names directly, but in one case we had to escalate the concern, and that resulted in the plugin being disabled on WordPress.org.
Temporarily disabled that is until the developer has pushed their security patches.
This leads me right into this week’s knowledge share: I will share details about how most open source projects handle security, and then explain what happens when a WordPress plugin or theme developer chooses to ignore security reports.
Weekly knowledge
Always be patching
I must start first by sharing the fact that most WordPress developers are quick to respond and patch when insecurities are reported in their project’s code. Occasionally though, security researchers reporting vulnerabilities get ghosted, ignored, or in rare cases blocked by the same people they are trying to help.
These developers have their reasons, and some of those reasons are valid, but they are forgetting they are the stewards of their codebase. Regardless of the reason, however valid, if no security patch is released they are leaving sites at risk for compromise.
To understand this better, let’s look at the log4j project’s security response, which I would consider an ideal response. After receiving the initial security report privately, a patch was ready, reviewed, and pushed within 1 or 2 weeks.
Then, new issues came up, and more patches came out even faster, within days. Version 2.17.0 was made available just this week. It addresses a denial of service issue, which could be argued is “low risk” but that does not mean “low priority”.
The log4j project’s developers still quickly released a patch to address the bug. This is a great example of code stewardship. The developers acknowledge the reports of security bugs in their project and were quick to release patches, and include clear communication in their changelogs, informing users that the version includes a security patch, encouraging users to update. The theme here being because they control the code, they are responsible to protect the users of the code.
Within the WordPress ecosystem, we tend to see respectful responses to security issues. Plugin developers most commonly are receptive when they receive security bug reports. They respond with appreciation and are quick to patch within a few days or weeks. In rare cases, developers have had new releases ready to address security bugs within a few hours of initial notification.
Now, patching within hours is the exception. We understand that security reports are emails that were not expected, and developers will not drop everything they’re doing to work on that one issue. But, in some cases … the developers try to simply ignore the reports. This begs the question:
What happens when security bugs are ignored?
A tactic some developers take is to simply ignore security reports. Remember, from the developer’s perspective the security report was not something they asked for, and they are already busy as it is. The reporting party is someone the developer has never met, and they have no authority to tell the developer how they should code! So, why should they take their time to listen to them?
When this happens, communication breaks down, no patch can be made available, and harm is caused. The victims here being harmed though, are the site owners who do not know they are running insecure code on their websites, and do not know they may be at risk of being hacked at any moment.
Who protects the site owners?
It turns out, the plugin developer is right, they don’t have to listen to the security researchers. But, there is someone who takes security seriously when it comes to WordPress components, and they have the power to act to protect website owners. I am talking about the volunteers who run the plugin and theme repositories.
When a developer ignores security reports, those reports get shared with the appropriate WordPress.org volunteer team and provide them with the details of the vulnerability. These volunteers, then take their own time to verify the report and reach out to the developer as well.
They are fairly effective at getting the issue addressed as well. If the developer ignores this team’s emails then the volunteers will remove the plugin or theme to protect site owners from installing insecure code. They are the ultimate line of defense, protecting site owners.
A dangerous situation emerges
It may sound good that the insecure plugin is pulled from the WordPress plugin repository, but I will have to sour your cheer again. Site owners will no longer be able to install the insecure plugin, yes. But, for site owners who already have the insecure component installed, nothing will look out of place.
They will continue to see the plugin as installed, and see that it has no updates available, leading them into a false sense of security because “no patches are needed”.
This is why it is important to check that your site’s plugins are being actively developed, and are still in good standing in their respective repository. If a plugin is disabled or has not received an update in years … then you may want to re-think its value vs. risk on your site(s).
Stay tuned for the backlog
As I mentioned earlier, Patchstack has a backlog of ignored security reports right now. Code that is running on 80,000+ websites could have been patched by now, but the developer is not replying to our emails.
We are about to notify the WordPress plugins team, and they may have to take action to protect more site owners from installing secure code. This may result in a number of themes or plugins getting disabled on their respective repository until security patches are made available.
You can expect updates regarding this situation over the next few weeks.
Thanks and appreciation
This week’s thanks go out to log4j’s development team, who are showing us how good stewards of code cases, and pushing security releases quickly. As well as a thank you to all of the other open-source developers who quickly patch security issues, your efforts are not missed.
Other thanks are needed for the WordPress security, plugins, and theme teams. Who, acts when needed to protect site owners, and put their foot down when developers do not address security issues.
I will be back next week with more security tips, tricks, and an update on those tens of thousands of insecure sites right here on the Patchstack Weekly security update!
