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

Making WordPress.org noreply at wordpress.org
Thu Apr 20 06:30:18 UTC 2023


#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 fearzzzz):

 Heya,

 Right now the process of reporting new vulnerabilities is quite time
 consuming. NGL, I like this idea with the contact form and dedicated pages
 per reported vulnerability, because this way it will be possible to make
 communication between «Security researchers - WordPress Plugins team -
 Plugin authors» much easier and more transparent.

 **A few thoughts from my side:**
 - most likely, someone will try to abuse these forms and this isn't only
 spam, but also fake reports (very often on different vulnerability
 aggregators there are fake reports that are added for «self-promotion»
 purposes or for getting achievements/badges etc.). So basically the
 security researcher needs to be registered @ wordpress.org to access the
 form, right? Does it make sense to introduce a «punishment» system for
 obvious fake reports?
 - it would be nice not to make all the input fields of the form obligatory
 and give the ability to upload .txt or .md files. Security researchers
 often upload their reports to X different websites, and copying each item
 from the report many times ends up taking a very long time. Such forms are
 mostly convenient for companies, but not for researchers.
 - what to do with the situation when the vendor doesn't understand what
 security/vulnerability is and what is required of him, and is anything
 required at all? Quite a common case.
 - does the term «security vendor» apply only to companies or to
 independent researchers as well?
 - if the plugin author doesn't agree with the discovered vulnerability
 (which sometimes happens, and such a position is biased), then the
 researcher can simply «bypass» this communication routine by uploading a
 report to any vulnerability aggregator, which in the end will still force
 either the plugin author and/or the WordPress Plugins team to turn
 attention to this problem. At this point it makes sense to listen a little
 less to the opinion of the authors I believe. What do you think?
 - additional question: what should motivate independent researchers to use
 this form?
 - maybe it makes sense to implement some kind of rating that displays the
 average response time to an incident of the plugin author? It would be
 great to somehow reward the plugin author for a quick response to an
 incident with profile badge for example and highlight this information.

 **Additional request:**
 It would be great to somehow «force» plugin authors to write an honest
 changelog and **not ignore/silence** any discovered and confirmed security
 issues. Right now this isn't only disrespectful to security researchers
 and regular users/clients, but also creates confusion that could have been
 avoided.

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


More information about the wp-meta mailing list