WordPress Plugin Developers Can Use security.txt Files to Aid in Getting Security Issues Reported to Them
In May, we found that numerous security providers had failed to catch that a vulnerability in the 100,000+ install WordPress plugin Genesis Block hadn’t been fully fixed. It was a good reminder of the importance of relying on vulnerability data that is actually vetted, which isn’t true for most sources. At the time, we had tried to contact the developer to let them know about the failure to fully fix this, but they didn’t provide a contact method to do that. We did find that the parent company of the developer, WP Engine, has a security page, but that doesn’t provide a contact method for non-customers to contact them. It directs customers to contact them through a general contact form. Both of those things are odd. It also mentioned a third-party vulnerability bug bounty program, which wouldn’t be relevant to address the issue we were trying to reach them about (and wouldn’t get us in touch with them).
The vulnerability has remained in the plugin since then. The plugin had remained in the WordPress Plugin Directory despite the plugin being publicly known to be vulnerable. That is, until two days ago, when it was closed on there:
That isn’t a great response time by the WordPress Plugin Review Team running it.
Since then, the developer acknowledged the plugin was closed due to the vulnerability and has released a fix. Though without being transparent about the fix in the changelog, as the changelog says, “Fixed: Security improvement for the sharing block.” There is a lack of acknowledgement there that there was a vulnerability. (They are not the only ones failing to be transparent, as Wordfence has not credited us with discovering that the vulnerability hadn’t been fully fixed, as they had previously claimed twice.)
WordPress Still Isn’t Addressing This
It has long been brought up by us and others that there isn’t a mechanism through the WordPress Plugin Directory to report vulnerabilities to plugin developers. Last year, two undisclosed members of the WordPress Plugin Review Team (who both work for Automattic, alongside yet another undisclosed team member) put forward separate suggestions for addressing the lack of a reporting mechanism. Neither of them have gone anywhere, with the last response on either being in October. There is a solution that developers can implement right now to make it easy to find contact information for notifying developers of security issues.
security.txt
Getting in touch with the right people to report security issues isn’t just a problem with WordPress plugins. Here is the US government’s Cybersecurity and Infrastructure Security Agency (CISA) noting they had trouble trying to warn organizations that they are susceptible to ransomware:
Earlier this year, CISA launched the Ransomware Vulnerability Warning Pilot (RVWP) program, which proactively discovers and notifies organizations of their exposure to internet-accessible vulnerabilities used in ransomware attacks. This is a proactive program used to enable organizations to take early mitigation measures before an incident occurs. Our current notification process can be hampered by the inability to find appropriate point of contact information for organizations.
They wrote that while explaining why security.txt files are so important.
A security.txt file is a simple file that provides information on reporting vulnerabilities and can include additional security related information. The concept was introduced in 2017 and became a RFC with the Internet Engineering Task Force (IETF) in 2022. While this is promoted as being placed on websites, it can easily be placed in to plugins. Similarly to how some plugins have SECURITY.md files used by Github. The RFC explicitly states it could be used for products as well, ‘A “security.txt” file MAY also apply to products and services provided by the organization publishing the file.”
The file only has two required elements as part of the standard, contact information (either a URL or email address) and an expiration time for the file. There are more optional elements. A file can easily be generated at securitytxt.org.
With our own plugins, the file we are adding to them looks like this for the two required elements:
Contact: https://www.pluginvulnerabilities.com/contact/ Expires: 2025-06-30T06:00:00.000Z
We also include an optional element with our encryption key.
Pushing This Forward
Inspired by the OpenSSF Scorecard project to better assess open source software security risk, we recently introduced our own Plugin Security Scorecard. That grades plugins based on their handling of security. One of the things we are checking for is inclusion of a security.txt file (or SECURITY.md file) in the root directory of the plugin. As the situation with Genesis Blocks shows, there is often a need to be able to get in touch with plugin developers to address security issues, but so often there isn’t any information available on how to do that. Providing that also can help developers to avoid situation like this, where a plugin is closed because a vulnerability hasn’t been addressed.