Welcome to the Patchstack Weekly Security Update, Episode 58! This update is for week 6 of 2023. It is the start of February.
This week, I learned a fun fact about something security related Automattic is leading the way on. In this week’s knowledge share, I will explain a proposed security standard that Automattic has already implemented more than anyone else. I will leave it up to you if you want to add this proposed standard yourself and show you how easy it is to set up.
In this week’s vulnerability roundup I will cover one plugin with a high-risk security bug patched by its developer. As well as share details on some bugs in lesser-known possibly abandoned plugins which have left just a few sites at risk as these security bugs may go unpatched.
Weekly knowledge
I have been hanging out on mastodon recently and found it wonderfully nostalgic. There are a lot of people there sharing some really stellar posts, ideas, and blogs. It reminds me of the halcyon days of social media.
One of those blogs that I encountered was about a proposed security.txt standard. A security researcher out of Denmark wrote up a blog to encourage more websites to adopt the use of security.txt files.
Their post “A free way to improve your security.(txt)” shares some great insight from the security researcher’s point of view.
One neat thing they did was scan 10 million websites looking for a security.txt file. They found very few websites have a discoverable security.txt file, but this is expected as the proposal is not a standard yet, and it is relatively new.
But, some big names have security.txt files, including Google, Facebook, Github, Slack, and multiple government organizations. But a company we all know is leading the way, Automattic. Automattic is listed as the security point of contact for the majority of security.txt files this researcher found. It appears Automattic installed security.txt files on the biggest number of websites, which means they’re the organization with the largest adoption of the proposed standard.
That may or may not be reason enough to set up a security.txt file yourself, but let me show you how easy it is.
What is a security.txt file?
The primary purpose of a security.txt file is to identify a security-related point of contact for the website. You place this file in a well-known location, such as /security.txt or /.well-known/security.txt on your website so researchers who identify concerns on your website know who to contact.
This is a huge time saver for security researchers and bug bounty hunters. This is both a good and bad thing, but I will explain how to avoid the bad aspects in a second.
The contents of the security.txt file are simple. In a minimalist style, it can be just one field:
Contact: https://yourwebsite/vulnerability-disclosure-policyor
Contact: mailto:youremail@address.comThere are many more fields you can add to the security.txt file, as well as a handy securtity.txt generator tool all available for free on securitytxt.org. You should check it out if you want to set this up.
Security.txt files work really well in conjunction with a vulnerability disclosure policy (VDP). You can avoid some of the bad aspects of bug bounty begging by using a VDP. When you communicate to researchers and bug bounty hunters what they can expect for bounties (including making it clear if you offer no bounties) you can save everyone time. You can also clarify what sort of security reports you want to hear about (or which you do not). Don’t worry if you are offering no bounties either, you can still set up a VDP because some security researchers really do just want to help you out.
While the security.txt file is specific to vulnerabilities found on websites. If you are thinking something similar, something that helps communication between developers and researchers should exist for plugins and themes, well… you’re right, luckily there is something. Patchstack launched a service for just this reason, a way to help plugin developers to communicate with security researchers called Patchstack mVDP. You should look into it. Bonus, it is free for FOSS WordPress plugins and we will write the vulnerability disclosure policy for you.
Vulnerability roundup
js-support-ticket – Unauthenticated Arbitrary File Upload
Users of the JS Support Ticket plugin should update to the newest release as soon as possible. The developers have been hard at work addressing security bugs and improving the plugin.
Seeing developers providing security updates is a great sign of a thriving and healthy project like JS Support ticket. The same can not be said for the next two plugins:
marketing-performance – Cross Site Scripting (XSS)
The generically named plugin “marketing-performance” has only a few installations, and was last updated 4 years ago. This week, a cross site scripting vulnerability was publicly disclosed. If anyone out there has the “marketing performance” installed on their site, you likely want to look for an alternative that is actively developed.
1003-mortgage-application – Authenticated (subscriber+) Arbitrary File Download
The 1003 mortgage application plugin is vulnerable to a bug that could allow any logged in user (including subscribers) to download arbitrary files off the web server. The last release was just 2 months ago, so hopefully, the developers are still active and will provide a patch soon.
Thanks and appreciation
This week’s thanks goes out to the developers of js-support-ticket a.k.a.. JS Help Desk. Thank you for patching the security bugs and really improving your project’s code quality in the last few weeks.
Further thanks is extended to EdOverflow and Yakov Shafranovich the creators of the security.txt standard, and maintainers of securitytxt.org
I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!
