WordPress Plugins Security Vulnerability Disclosures

There have been a lot of discussions about how plugin developers should communicate security fixes to the users. In the past, it has been their decision to choose wether they want to mention security fixes in the change-logs or not.

While the best developers have always opted for transparency and clear communication, there are also those who feel embarrassed or want to make security fixes go unnoticed. This, however, is not an option anymore.

In the last issue, I talked about the upcoming Cyber Resilience Act, which is expected to be passed as a law in the EU, which affects all developers who publish software that have end users in Europe.

With more and more vulnerabilities being discovered and fixed in the WordPress ecosystem, I see an increasing amount of discussions around how these issues should be addressed. Today, let’s cover that. Hopefully it’s useful to both plugin developers, and to users who choose their vendors.

Importance of WordPress vulnerability disclosure

By default, every vulnerability in open source software is a public information – regardless if it’s fixed, not fixed or even not yet known to anyone. The latter, however, is impossible to validate, and therefore every vulnerability in open source software should be processed as a publicly known issue.

We often see plugin developers and sometimes also their users criticize the vulnerability disclosure process. The arguments are often around the fact that users did not have enough time to update and that the disclosure is helping hackers to launch attacks faster.

In some cases, plugin developers have even tried to convince us to remove the vulnerability information from our database completely and have tried to fix vulnerabilities silently to “protect their users”.

However, the reality is that the hackers always have the upper hand. Here’s why:

1. They are often the only one who intentionally search for the vulnerabilities in the plugin. Most developers don’t do regular security audits to their plugins. Most vulnerabilities stay undetected in the codebase for a long time, so when receiving a vulnerability report by a ethical hacker, it’s unreasonable to expect that this vulnerability has not been found by someone else before.
2. Hiding the fact that security vulnerability has been patched and/or not communicating this clearly to the users only benefits the hackers. First of all, it’s impossible to prove that nobody else knew about this vulnerability before. Hackers could have known about it, but could have kept the zero-day in reserve for future attacks. Once the vulnerability gets patched, new version code diff can alert the hackers about changes made to the vulnerable function.
3. If the users are not immediately notified about a security fix, then the number of users who rush to update is lower. Hackers take advantage of that to try exploit as many websites as possible before they’ve had time to update. Few weeks ago, we saw a popular page builder to become exploited in a matter of 5 hours after vulnerability was disclosed. The exceptional communication by the developer saved a lot of site owners from the worst.

The benefits of transparent vulnerability disclosure

The plugin/theme (or any open source software) developers should see transparent vulnerability disclosure process as an opportunity instead. Security & trust have become more important than ever and web developers who choose new plugins into their stack want to know if the vendors are trustworthy.

If the plugin developer has set up a vulnerability disclosure program (btw every WordPress plugin developer can set this up for free here) and they are transparent about their security processes and communication, then it gives assurance to web developers that they can rely on the vendor and that important information is communicated to them without delay.

Transparency and clear communication can be turned into a significant competitive advantage. Just take the example of a recent incident where a critical severity vulnerability was fixed in Bricks builder. We consulted the developer to stay transparent and focus on clear communication, which regardless of the severity of the vulnerability made the Bricks users trust the developer even more than they did before.

I must mention Cyber Resilience Act once again. This will become a law, and as long as your plugin has users inside the European Union, you need to comply. Setting up vulnerability disclosure program today can give you head start before anyone else and make sure your software is compliant early on.

Conclusion

Actions of plugin developers have a significant role and responsibility of how vulnerabilities in their software affect the end users websites that have trusted them (and their code). Everything in the world boils down to people and relationships, and this is true here also.

Open source is all about transparency, integrity and open communication. As web developer, make sure the plugins you use follow these principles and as a plugin developer, be smart and turn these to your competitive advantage. If you want to stand out even more, consider rewarding security researchers for their contribution and open up a bug bounty program.

Resources:

• Vulnerability disclosure program for WordPress plugins
• Sign up to Patchstack weekly security newsletter