Add a "Report a vulnerability" button/link to plugin repo pages

[mrfoxtalbot]

Contributors who have been involved with the project long enough know that they should email plugins@… to report vulnerabilities. On the other hand, newer contributors are often not aware of this and will discuss or disclose vulnerabilities in the plugin's forum and in other places.

The plugins team has been discussing the idea of adding a visible "Report a vulnerability" button or link somewhere in the plugin page itself.

Clicking on this button could show a form that would be sent to the plugins team email. If we want to make it even simpler, the link would take the user to the ​relevant handbook page

The idea is to provide a very simple path for new users to report vulnerabilities in the correct way.

This ticket is a simplified version of the idea proposed in #6939

[mrfoxtalbot]

Mockup of a potential location for the "Report Security Issue" link/button

[TimothyBlynJacobs]

I think this needs to support a readme.txt field that can be a URL. Some plugins use HackerOne or Patchstacks' VDP program for managing vulnerabilities. Pointing security researchers to go to the .org team first would be misleading.

[oliversild]

I think the right approach to this issue was described in more detail here: https://meta.trac.wordpress.org/ticket/6939

"Contributors who have been involved with the project long enough know that they should email plugins@… to report vulnerabilities." - That is not entirely true. In fact, we've (Patchstack) been asked by Plugin Team to try not to send all vulnerabilities to the plugins team and instead report them to plugin developers directly.

Sending vulnerability reports to the plugins team should only be a fallback option. When submitting a plugin to the WP.org repo, plugin developer should have a requirement to add a link to their vulnerability disclosure policy or to security contact form.

[anonymized_20889438]

Replying to oliversild:

When submitting a plugin to the WP.org repo, plugin developer should have a requirement to add a link to their vulnerability disclosure policy or to security contact form.

Thus, we will face the situation that most developers aren't ready to talk about security, and this will only confuse/scare them. It may also turn out that the whole subject will become more complicated.

Why not add this link ("Report a security issue") as a first "trial" step, which would open a simple form, the data of which would be sent to two addresses - the WordPress Plugins team (just to keep an eye on the situation and have "evidences" that there was a contact attempt and so on) and to the developer?

[oliversild]

I think forcing plugin developers to set up security point of contact (which btw is already required by law in some EU countries) is a great and lowest effort way to get them think about security and take responsibility.

There should be a "Report a security issue" button, 100%, but it should be customisable link to their vulnerability disclosure policy, security.txt, bug bounty program, etc.

WordPress.org should not force researchers to report vulnerabilities to the Plugin Team, because it will clash with the plugins vulnerability disclosure policies and bug bounty programs. It's also a unwanted overhead for the WordPress volunteers and it's not reasonable for WordPress.org to cover vulnerability triage for 60K+ vendors.

[anonymized_20889438]

Replying to oliversild:

I think forcing plugin developers to set up security point of contact (which btw is already required by law in some EU countries) is a great and lowest effort way to get them think about security and take responsibility.

Someone has to enforce and track this requirement, otherwise it makes no sense. A similar example is maintaining a change log by developers. Everyone does what they want, and in the security field even this little thing creates different problems.

There should be a "Report a security issue" button, 100%, but it should be customisable link to their vulnerability disclosure policy, security.txt, bug bounty program, etc.

Yes, and we need some kind of backup option here in case the developers:

• indicate incorrect data;
• will lose their domain (quite common case);
• will not respond to incoming requests (x2 quite common case).

WordPress.org should not force researchers to report vulnerabilities to the Plugin Team, because it will clash with the plugins vulnerability disclosure policies and bug bounty programs.

I think exactly the same, but WordPress.org won't be able to force researchers to do something. Companies - maybe, but not researchers. On the part of researchers, participation in all these procedures is a gesture of goodwill, when everything could happen according to a different scenario (and we have a well-known examples how exactly this could be).

What if developers doesn't have their own VDPs and can only solve these security related issues through the WordPress Plugins team?

It's also a unwanted overhead for the WordPress volunteers and it's not reasonable for WordPress.org to cover vulnerability triage for 60K+ vendors.

One way or another, someone should control the process in case things aren't going smoothly and the problem needs to be solved.

[oliversild]

"Someone has to enforce and track this requirement, otherwise it makes no sense. A similar example is maintaining a change log by developers. Everyone does what they want, and in the security field even this little thing creates different problems."

You can quite easily enforce it by asking plugin developers to give a link or email of their "security point of contact". You should not be able to submit a new plugin without doing this. You could also enforce it on existing plugins in a way that they can't release a new update without having the security point of contact added. Older plugins that have not yet added their own link or email for security point of contact should have the button fall-back to WP.org plugin team.

"Yes, and we need some kind of backup option here in case the developers:
indicate incorrect data;
will lose their domain (quite common case);
will not respond to incoming requests (x2 quite common case)."

This I think is out of scope. All WP.org can do is add a disclaimer that the security point of contact link/email needs to be accessible and it should be possible to reach out to the plugin dev. regarding security issues at all times. If for some reason this is not the case (email bouncing back, URL broken, etc.), then the plugin is failing with the requirements and should get closed (if it's not getting fixed).

"I think exactly the same, but WordPress.org won't be able to force researchers to do something. Companies - maybe, but not researchers. On the part of researchers, participation in all these procedures is a gesture of goodwill, when everything could happen according to a different scenario (and we have a well-known examples how exactly this could be)."

Yes, you can't force security researchers to do anything. All you can do is make reporting vulnerabilities as easy and straightforward as possible, so they don't disclose the vulnerabilities elsewhere (which is bad for the plugin developer and for the entire WordPress ecosystem).

"What if developers doesn't have their own VDPs and can only solve these security related issues through the WordPress Plugins team?"
They should have. If they don't have a VDP, then at least they they should have a separate security point of contact form or an email. This needs to become a standard in the WordPress ecosystem as it is elsewhere in the wider open-source space.

[Otto42]

Replying to oliversild:

This needs to become a standard in the WordPress ecosystem as it is elsewhere in the wider open-source space.

Please, point us to where this is actually a standard. Any URL, documentation, or anything you want that shows that this is a standard in the "open source space".

[swb1192]

Worthwhile to review how NPM does this with a “Report Malware” button on the package listing:

​https://www.npmjs.com/package/react-dropzone

[oliversild]

Replying to Otto42:

Replying to oliversild:

This needs to become a standard in the WordPress ecosystem as it is elsewhere in the wider open-source space.

Please, point us to where this is actually a standard. Any URL, documentation, or anything you want that shows that this is a standard in the "open source space".

Happy to do that. I think when we look at open-source content management systems (most similar to WordPress), then a great example is Drupal. In the Drupal modules library, each module page has a dedicated link to report security vulnerabilities, like that: ​https://www.drupal.org/project/webform

Another open-source content management system similar to WordPress is Joomla. They also have standard way for reporting security vulnerabilities for Joomla extensions (This example is not the best way to do it actually (at least for WordPress). They have single security point of contact for all extensions, which can work for them, but not in the scale that WordPress has): ​https://extensions.joomla.org/vulnerable-extensions/submit-a-report/

When we look beyond content management systems, but stay in the open-source PHP ecosystem, then another example is Packagist. They all have a separate section for "Security Vulnerabilities" where the developers can set their own security point of contact (I think that's the way WordPress should do it as well). Example: ​https://packagist.org/packages/laravel/laravel

I hope that helps.

[oliversild]

Replying to swb1192:

Worthwhile to review how NPM does this with a “Report Malware” button on the package listing:

​https://www.npmjs.com/package/react-dropzone

Yes, indeed, NPM does this as well (and many others, such as Go), but I left them out atm as Drupal, Joomla, Packagist are "closer to home" and they provide a more relatable example. :)

Since I now mentioned Go, I'll just share their example too: ​https://pkg.go.dev/net/http

[oliversild]

I think GitHub is a great (wider open-source ecosystem) example as well.
Example: ​https://github.com/laravel/framework

[zodiac1978]

There was a great post from Joost de Valk about this:
​https://joost.blog/plugin-security-issues/

Talking about how to report issues, these are not very standardized. Some places which are mentioned ...

On the plugin’s webpage / website.
On the plugin’s GitHub page (preferably through a security policy Security.md file).
In the plugin’s readme.txt and thus on the WordPress.org plugin page.

But the plugin creator can also use some vulnerability disclosure program are have a security.txt on their website with this information.

Customizing the link for reporting in the readme.txt could be one way to solve this, maybe with a fallback for the form (which is send to the author and/or to plugins@) if it is not set.

[oliversild]

Replying to zodiac1978:

Customizing the link for reporting in the readme.txt could be one way to solve this, maybe with a fallback for the form (which is send to the author and/or to plugins@) if it is not set.

This!☝🏼