[wp-meta] [Making WordPress.org] #6939: Reporting Security vulnerabilities in plugins

[Making WordPress.org]

#6939: Reporting Security vulnerabilities in plugins
------------------------------+---------------------
 Reporter:  dd32              |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:  2nd-opinion       |
------------------------------+---------------------

Comment (by oliversild):

 Replying to [comment:22 dd32]:
 > Regardless; The plugins team should still use the same close-as-security
 workflows if the plugin author hasn't resolved a report within a
 reasonable timeframe. Simply handing off security reporting to a 3rd-party
 reduces the ability for WordPress.org to ensure that only secure plugins
 are distributed here.

 Making security reporting possible should be the responsibility of the
 software author, not .org. That's what has created this problem in the
 first place.

 > Then we have over a year to get to that point, where plugins can define
 their reporting method OR a further iteration of the MVP can provide them
 with a way to have it reported via W.org.

 It will take time to implement and will also take time for all plugin
 developers to adopt this. **We should not wait for the last minute.**

 > Agreed. But there is not a current location we can direct all plugins
 to, nor can we just have a form that emails the plugins team without some
 automation in place.

 The correct solution would be that the plugins team should not be bothered
 at all by this. In fact, this has been told to us in the past by the reps.
 of plugin review team that security reports should be sorted out between
 the reporter and the plugin author. Why create a workflow that gravitates
 the behaviour in the opposite direction?

 > It's not viable for a lot of plugin authors to setup those options, nor
 do we want to require them to use one of the very few commercial companies
 who are currently in this space.

 **This is the only viable way long-term.** Nobody needs to use any kind of
 commercial company for that. They will need to establish security point of
 contact and it's good enough if they add this information to their readme
 file, security.txt file or some dedicated page on their website.

 > This is overhead that we already have, due to Security Vendors emailing
 us vulnerabilities every day, often that are not user-affecting and where
 the plugin author would've been otherwise contactable.
 > ...this is about reducing the number of emails that the plugins security
 reps have to manually process and respond to every day.



 This overhead is directly caused by the fact that plugin developers have
 not been enforced to establish a clear security point of contact for the
 software they publish. I can say this because we're the largest
 vulnerability processor/reporter in the ecosystem and for many plugins
 (even the ones which are actively developed) it's often impossible to find
 any contact information or a clear way to report security issues - these
 are the cases when we fall back to sending the report to the plugin review
 team. 1) Plugin review team does not want to deal with this overhead. 2)
 Plugin authors don't want a these to be disclosed to third-party (plugin
 review team) before they fix the issue 3) We as a reporter should do
 everything in our power to keep this between the vulnerability reporter
 and plugin author until it gets patched.

 **I strongly advise against this MVP that creates a workflow that is a
 solution to a consequence and not to a root problem.** To raise the
 quality and security of the plugins in the ecosystem, we need the authors
 to take more responsibility.

 **I propose the following:**
 1) - I can draft a guideline for the Plugin Handbook for "Security
 Reporting" and how to set up security.txt file and how anyone can set up
 their own security reporting without using any third-party commercial
 solutions.
 2) - Button "Report a vulnerability" next to "Support" button on every
 plugin page (will be made visible when a hyperlink is connected to it).
 3) - All new plugins submissions need to have this hyperlink present.
 4) - Existing plugins should receive an email about this becoming
 mandatory starting from 1st of January 2026.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6939#comment:23>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org