Welcome to the Patchstack Weekly Security Update, Episode 56! This update is for week 4 of 2023.
This week’s knowledge share is for developers and site owners alike. I will be discussing how open source projects (really any code project) can show, not just tell, their users that their project’s code is secure and safe to use.
In this week’s vulnerability roundup, I will share details about 3 high-risk security bugs in WordPress components of which 2 received patches and 1 went without.
How developers can prove their security
This week’s knowledge share continues the trend in the past few weeks’ new years security resolutions. This week’s resolution is how developers and project owners can prove their project is secure and safe to use.
If you’re not a developer, stick around. You may learn what to look for in a project that is serious about handling security and is willing to prove it.
As in previous new years resolutions I will share a few checklist items that open source projects can take to improve and show their security process to users. Or, as I prefer to say – to prove they have a mature security model.
Let’s get started.
Do they have a history of security releases?
This one may sound counterintuitive at first. You want to look for a lot of security releases. Because a project with a regular history of security fixes is proof of active security-related development and improvements. If a project has zero security-related patches, don’t think that means it’s security bug-free – it might just mean the opposite.
Where can you review or publish a project’s security releases? Changelogs.
Developers, you should always include details about releases in the changelogs. Site owners, you can also cross reference a third party like a public vulnerability database to confirm if there are really no security bugs known in the product, or if they omit security details from changelogs.
Another counter-intuitive idea is to look for releases with multiple security patches. Those may be another good sign, it may mean they paid a third party to perform a security audit and then made the fixes in a single security release to improve their code base.
If you spotted no security release details in the changelog, but there are publicly reported security bugs in the Patchstack Database? In this case, you may have a developer who is not communicating security issues very well with their users. This leads me to my next recommendation:
Do they communicate security issues?
Developers write the patches but a site is not secure until that patch is applied. This is why it is important for a developer to inform their users when a security patch is made available.
This communication can take place in a few places. Most commonly, the project’s changelog is the first place to look. This is how you can prioritize if that “update is available” needs to be performed next week (features) or immediately (security releases.)
In addition to changelogs, many open source projects have a dedicated “Security” section in their blog. If a project has a security feed I can subscribe to via RSS, then that’s the best. I will pipe that feed right into the company slack (or email list) and we never miss an important release.
Now, onto the final recommendation:
Do they have a vulnerability disclosure policy?
Vulnerability disclosure policies are formal documents describing how to report security issues to a project. I talked about what makes a good vulnerability disclosure policy last year on the Patchstack weekly(Week 5 – Open Source & Vulnerability Disclosure Policies). This year, Patchstack makes setting up a vulnerability disclosure policy a lot easier with the managed Vulnerability Disclosure Policy program.
If you’re a developer, I recommend you communicate how you would like security bugs reported to your project. If you lack this, you might get reports in unexpected places, like your public support forums.
Conclusions
These three points: A history of security releases, communication of security and a vulnerability disclosure policy are not just recommendations. They are how mature open-source projects approach security. You need not look far for an example, as WordPress itself has all three. WordPress security releases are clearly communicated with each release when security bugs are responsibly reported.
Vulnerability roundup
enable-media-replace – Author+ Arbitrary File Upload
The popular Enable Media Replace plugin, with over 600,000 installations addressed a security bug which could have allowed users with Author or higher roles the ability to upload arbitrary files. It is recommended to patch as soon as you can if you have many author accounts on your site.
mainwp-file-uploader-extension – Unauthenticated File Upload
The MainWP File Uploader extension released a patch which addresses an unauthenticated file upload security bug found by Patchstack’s very own Dave Jong. Users of the MainWP File Uploader extension are strongly encouraged to update as soon as possible.
mainwp-links-manager-extension – Unauthenticated Object Injection
In light of this object injection security bug being reported in it, MainWP has retired the MainWP Links Manager Extension. It is recommended site owners remove this plugin immediately and find an alternative solution.
This week included multiple vulnerabilities affecting various MainWP plugins. If your websites use MainWP, then it is highly recommended you check for updates or if the components you are using have been retired.
Thanks and appreciation
This week’s thanks goes out to the developers of Enable Media Replace, Short Pixel as well as the developers at MainWP for providing your security releases.
A special thank you goes out to all of the developers who don’t just say they take security seriously, but actually do. With clear communication about security releases, regular security updates and a vulnerability disclosure policy. That is how you prove you walk the walk not just talk the talk.
I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!
