Reporting Security vulnerabilities in plugins

[dd32]

Currently there are two main ways to report security issues to plugin authors:

1. Scour the plugin page for a Security reporting link and failing that, look for a company/personal contact, reach out via their contact form or email address, convince them to resolve the issue.
2. Email the plugins team with a report, have them forward the report on to the author(s) of the plugin, and let the plugins team choose to withdraw the plugin from the repository or not (Note: Most plugins are withdrawn upon a security notice, as currently there isn't a better way to manage whether things get fixed or not).

Neither of these are ideal solutions, In the first, security reporters often find that their reports are missed, ignored, or simply not able to find a contact method for the author. That then causes them to use the second option.
In the second, it requires time from a human reviewer to review the security report, determine if it appears legitimate, determine the plugin it relates to, check to see if the plugin has released a newer version, copy-paste the report to the plugin author, manage the communication with the author + explain the issue, likely close the plugin to keep track of the security issue, etc.

Quite simply, neither is an optimal scenario, and with the number of plugins on the directory growing, and the number of security reporters who are invested in responsible disclosure growing, the human time required to manage this simply increases.

There are likely a few ways we can resolve this, but, after discussing this with a few community members, plugins reviewers, and a few select security researchers, I'd like to propose one solution.

The proposal

• Each plugin gets a Report Security Issue button, that links to..
• A form on WordPress.org, likely at a location such as /plugins/report-security-issue/?plugin=example-plugin-slug-here
• That form requests all the pertinent details, Plugin Version, Type of issue, Severity, Description, POC, Possible patch(es), Security reporter details.
• That form creates an 'security incident' CPT entry, The details are emailed to the plugin author for action.

From there, there are a few options, but I believe the above would suffice as an MVP, to streamline the process of getting security reports to the authors.
Ideally however, We'd then...

• A security incident is created, and accessible via a private URL to the plugin committers, security reporter/researcher, and plugins team, at a url such as /plugins/security-report/{UUID}/
• Communication between the Security reporter and Plugin Author can take place via comments on that page, instead of ad-hoc email. (Notifications of comments would still trigger an email)
• The Plugin authors details (email, etc) can remain private, likewise the security reporter could remain private. Perhaps it links with their 5ftf pledge and it's "This is a report from <username> of <CompanyName>" if part of a company, otherwise just "from <username>".
• Plugin Reviewers can see and comment if required.
• The incident can be marked as resolved in a given version (by any involved)

Of course, as noted above, there are some issues around how to ensure things get fixed appropriately, but also that false reports or by-design doesn't impact the plugin.

• If the plugin author doesn't ACK the issue, the plugin is closed within a certain timeframe, this encourages authors to resolve the issue.
• If the plugin author does resolve the issue within a time limit, and the security reporter is satisfied, the plugin is never closed. This benefits the Plugin author and end-users.
• If the plugin author believes the reported issue is not valid, or the Security reporter believes the author is not making a reasonable attempt at resolving the issue, it can be escalated to the plugins team to make a decision.

Potential Issues / Caveats

1. Not everyone understands what a Security vulnerability is.
   • Requesting specific fields may increase the barrier to reporting, making it less likely to be problematic.
   • Reports could still go via the plugins team for the initial report, only once a reviewer confirms it, would it (And future reports from the author?) then be forwarded on to the author. In other words; trusted reporters go straight through, not-yet-trusted gets moderated.
2. Security reporters have their own tools they may wish to use, asking them to use our system might be a challenge. Most should be at willing to use ours for submitting it though.
3. Plugin authors may already have a system in place, such as HackerOne or BugCrowd. Ideally we'd somehow integrate with those, but initially we could just disable ours if a security-reporting url is provided by the author.
4. Disclosure, Ideally issues would get disclosed at some point, for now this would be better left to the existing indexes of plugin vulnerabilities and we wouldn't be creating a disclosure index for now. At a later date it might be good to then use this data to say "Versions less than 1.2.3 are known insecure" and integrate that into core somehow.

Outcomes

• This would also provide the plugins team a greater view into the security issues affecting plugins, trends of what they need to keep an eye out on in plugin reviews, what needs better documentation, etc.
• Would also allow the plugins security team to be aware "sooner" of high-severity issues that may warrant a security auto-update, or to be escalated to the team when that's going to be needed.
• Plugin authors can be assured that they'll get notified about security issues, no longer have their plugin closed for re-review unless no effort is made
• Security reporters no longer need to hunt around for a contact email address or contact form, unsure if the issue will get to the correct person.
• Security reporters would be able to get a trackable event on their profile, "Reported a security issue on a plugin."
• Plugin reviewers would no longer need to manually process every security report email
• Plugin reviewers might be able to offload some of the re-review/verification of the security fix onto the security reporter, as currently it's 'easier' for the reviewers to review it than go back to the initial reporter to get it checked
• Plugin Security Team time could be more targeted to supporting and reviewing issues as needed, and working on supporting plugin authors and security items rather than emails.

[dd32]

Opinions of others are greatly appreciated. This is not something that's decided and set in stone.

[anonymized_20889438]

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 a 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.

[dd32]

Replying to fearzzzz:

• most likely, someone will try to abuse these forms and this isn't only spam [...] 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?

Yes, reporters would need to be registered.
I would like to think that a 'punishment' system shouldn't be required. If a reporter was to consistently make false reports then that would be within reason to have their account permanently banned or reporting permission limited.

• 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. [...] Such forms are mostly convenient for companies, but not for researchers.

Per-field or as the entire submission? Is there any "standardised" .txt/.md format that some use?

• 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.

This is unfortunately something that the plugin security team has to deal with often.
Quite often suggested fixes are ignored and insecure fixes are made, which requires further changes from the author.
Educating plugin authors can only be done through better documentation of the problem, and examples of how to resolve it.

In the case of WordPress.org plugins, if a author is not willing to fix something that the plugins team deems a security issue, then they can close the plugin. If the author wants their plugin, they need to work with everyone to ensure it's secure.
(It's not uncommon for some plugins that are intentionally "insecure" to get security reports either - for example, an admin console that lets any user execute PHP, or a plugin that allows users to access any file on the server filesystem, a report against one of those would not warrant the plugin being closed, unless it was something like an authentication bypass)

There's the scenario where the plugin security team can step in and fix the plugin too, although in that case, it would only be to make an update for end-users, the author would not retain access if they were not willing to support the plugin.

• does the term «security vendor» apply only to companies or to independent researchers as well?

Bad choice of words on my part. I meant in terms of researcher. This should be open to anyone, whether they're an employed security researcher, an individual researcher, or a vehicle mechanic who understand code.
I'm going to go edit the ticket to read security reporter to be more inclusive.

• 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?

I touched on this in the above answer, but this is a case where the security researcher would escalate it to the plugins team to intervene, and would result in the plugin being closed. That would ideally happen before the disclosure is made by a vulnerability aggregator.

Currently the plugins team take action in response to public disclosures mostly as the team was not made aware of the issue before hand (there are some deliberate 0day'ers) or due to being a volunteer team, did not get to the email in time (There have been cases where we're alerted a few days before the disclosure timeout happens, and some where the notification was misunderstood).

• additional question: what should motivate independent researchers to use this form?

That's something you can help greatly with! And why I'm open to discussion on this, rather than saying "This is what needs to be built and this is what everyone gets".

I suggested in the ticket a profile entry for reporting security issues, but I intentionally didn't suggest a threshold to get a badge of some form, or a count of submitted reports, to partially remove the desire to submit many reports for extreme-low-effort issues for an 'awesome badge'.

Perhaps down the line we'd be able to look at a Security Researcher badge for those who submit enough valid reports against WordPress Core / Plugins / Themes / etc, with a percentage-accepted criteria, to encourage reporters to only submit things that are actually valid and tested.
Other platforms have a Leader Board system, that works for them, but I don't think it'd work for us.
This is something that we'd probably only be able to identify the best solution for once we had enough reports / data collected.

• 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.

Interesting idea! This is probably not something we could do for the first iteration, again, due to lack of data points. But rewarding plugin authors who do things right is definitely worthwhile.

It would be great to somehow «force» plugin authors to write a 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.

I do agree, and in a way that is partly the reason for this ticket. The plugins team are often not aware of plugins that have significantly severe vulnerabilities until public disclosure and it being talked about widely, simply as they're never made aware of it.

Currently ​the only documentation we have on responding to a security report is not very direct on what they should do in this regard. Updating that page to strongly encourage changelog entries and crediting the reporter should be done. If you have any suggestions for wording changes to make to that page, come along to #pluginreview in Slack with them and we'll get it sorted.

Something that we could do here however, is forcibly prefix the Upgrade Notice for a security fix with information of that regard, or ensure the changelog mentions Security for such plugins.
This is one of those situations where we currently have limited ability to control the messaging from plugin authors, while we can encourage them to be transparent, we still have to rely upon them wanting to work with us.

I think this is something we'd have to look at as a follow up, once we see how plugin authors actually respond to it. With some well documented steps they should follow (perhaps a checklist) many are likely to be more willing to.

[yani.iliev]

Thank you for taking the time to write such a detailed ticket description.

As a plugin author, I just need a way to make the vulnerability reporting link easily accessible and visible to security reporters. As an MVP, I'd start with just a link but make it required. This is similar to how the "Support" link works for Commercial plugins.

The changelog request fails to consider that not everyone who reads the changelog is technical and understands the scope of the issue. The technical terms used to describe security issues can create FUD among non-technical users.
To address this, I propose that the changelog remains simple without creating unnecessary FUD, but includes links to the technical explanation of a security issue and how it was fixed. Plugin authors can be provided with a changelog template to use in their plugins.

Reporting a security vulnerability in a plugin can trigger an immediate disabling of the said plugin from the WordPress.org plugin repo. This rule has to change to give plugin authors time to address the issue before taking action.

[anonymized_20889438]

Replying to dd32:

I would like to think that a 'punishment' system shouldn't be required. If a reporter was to consistently make false reports then that would be within reason to have their account permanently banned or reporting permission limited.

I'm sure that this is a «must-have» option, even if it's not needed in the very near future. Sooner or later, but someone will try to use this reporting functionality for, let's say, personal purposes. At this point, limited reporting permissions sounds really good. Like, you know, «your account isn't banned and we're not telling you to get out, but you're doing something wrong».

Per-field or as the entire submission?

Good question. I think the proper title is a must over here, also it must be informative. I like how WPScan do it, i.e.: «WooCommerce Payments < 5.6.2 - Unauthenticated Privilege Escalation», «WZone - Lite <= 3.1 - CSRF» and so on. A well-written title will give us all the basic information we need: name of the vulnerable component, range of vulnerable versions, minimum required user role to exploit the vulnerability, and the type of discovered vulnerability. IMO, this should be the «gold standard».

Is there any "standardised" .txt/.md format that some use?

Many researchers are guided by the template that is required for Exploit-DB submits, but this only applies to the report header, and not everyone fills in the required fields with the correct data. So there is no single standard here. For example, I use my own template for reports.

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.

This is unfortunately something that the plugin security team has to deal with often.
Quite often suggested fixes are ignored and insecure fixes are made, which requires further changes from the author.
Educating plugin authors can only be done through better documentation of the problem, and examples of how to resolve it.

Yeah, I understand.

In the case of WordPress.org plugins, if a author is not willing to fix something that the plugins team deems a security issue, then they can close the plugin. If the author wants their plugin, they need to work with everyone to ensure it's secure.

Sounds legit.

Bad choice of words on my part. I meant in terms of researcher. This should be open to anyone, whether they're an employed security researcher, an individual researcher, or a vehicle mechanic who understand code.

Awesome, thanks for the clarification!

Currently the plugins team take action in response to public disclosures mostly as the team was not made aware of the issue before hand (there are some deliberate 0day'ers) or due to being a volunteer team, did not get to the email in time (There have been cases where we're alerted a few days before the disclosure timeout happens, and some where the notification was misunderstood).

Yeah, I know about this situation.

there are some deliberate 0day'ers

Honestly speaking, sometimes I do this because there are simply no other options left. It's a rare case now, but still.

That's something you can help greatly with! And why I'm open to discussion on this, rather than saying "This is what needs to be built and this is what everyone gets".

Sounds good! I need to think about it.

I suggested in the ticket a profile entry for reporting security issues, but I intentionally didn't suggest a threshold to get a badge of some form, or a count of submitted reports, to partially remove the desire to submit many reports for extreme-low-effort issues for an 'awesome badge'.
Perhaps down the line we'd be able to look at a Security Researcher badge for those who submit enough valid reports against WordPress Core / Plugins / Themes / etc, with a percentage-accepted criteria, to encourage reporters to only submit things that are actually valid and tested.

If it's a badge of distinction to be earned through honest and hard work, that would be great. I like it.

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.

Interesting idea! This is probably not something we could do for the first iteration, again, due to lack of data points. But rewarding plugin authors who do things right is definitely worthwhile.

Awesome!

It would be great to somehow «force» plugin authors to write a 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.

I do agree, and in a way that is partly the reason for this ticket. The plugins team are often not aware of plugins that have significantly severe vulnerabilities until public disclosure and it being talked about widely, simply as they're never made aware of it.

Currently ​the only documentation we have on responding to a security report is not very direct on what they should do in this regard. Updating that page to strongly encourage changelog entries and crediting the reporter should be done. If you have any suggestions for wording changes to make to that page, come along to #pluginreview in Slack with them and we'll get it sorted.

Count me in. I just need some time to think about this task.

Something that we could do here however, is forcibly prefix the Upgrade Notice for a security fix with information of that regard, or ensure the changelog mentions Security for such plugins.
This is one of those situations where we currently have limited ability to control the messaging from plugin authors, while we can encourage them to be transparent, we still have to rely upon them wanting to work with us.

I think this is something we'd have to look at as a follow up, once we see how plugin authors actually respond to it. With some well documented steps they should follow (perhaps a checklist) many are likely to be more willing to.

Yeah, I understand. From my personal experience, I would say that the first thing to do here is to «flip the script»:

Someone found a vulnerability in your plugin? Yes. But this doesn't mean that you write «bad code» or you are a «bad person». This is a great opportunity to make your product more secured, better and join the community united by a common idea.

Many developers seem ashamed of their lack of knowledge, of their mistakes, and this has its consequences on many internal processes. But silence or ignoring security issues only makes the situation worse.

[Otto42]

Replying to yani.iliev:

Reporting a security vulnerability in a plugin can trigger an immediate disabling of the said plugin from the WordPress.org plugin repo.

Definitely no. The whole point of having a security reporting system is that anybody can file a security report. Therefore, no report (from the general public) can be used to take automatic actions.

[dd32]

Replying to fearzzzz:

Many developers seem ashamed of their lack of knowledge, of their mistakes, and this has its consequences on many internal processes. But silence or ignoring security issues only makes the situation worse.

I think this is a key part of the issue, no developer writes 100% secure code all the time, but equally, no developer ever really wishes to admit that. Part of the problem is that while developers may understand this, users of plugins may not, and it's their opinion that matters for plugin authors.
But equally, there are often security fixes that are more of a 'hardening' change - something that is technically a vulnerability (perhaps often viewed by the author as nothing but a nitpick) but yet so extremely unlikely to actually ever be used to against a site, and that the fear of simply mentioning 'security' drives fear into authors.

[yani.iliev]

Replying to Otto42:

Replying to yani.iliev:

Reporting a security vulnerability in a plugin can trigger an immediate disabling of the said plugin from the WordPress.org plugin repo.

Definitely no. The whole point of having a security reporting system is that anybody can file a security report. Therefore, no report (from the general public) can be used to take automatic actions.

Exactly, yes.

[yani.iliev]

Replying to dd32:

Replying to fearzzzz:

Many developers seem ashamed of their lack of knowledge, of their mistakes, and this has its consequences on many internal processes. But silence or ignoring security issues only makes the situation worse.

I think this is a key part of the issue, no developer writes 100% secure code all the time, but equally, no developer ever really wishes to admit that. Part of the problem is that while developers may understand this, users of plugins may not, and it's their opinion that matters for plugin authors.
But equally, there are often security fixes that are more of a 'hardening' change - something that is technically a vulnerability (perhaps often viewed by the author as nothing but a nitpick) but yet so extremely unlikely to actually ever be used to against a site, and that the fear of simply mentioning 'security' drives fear into authors.

As a plugin developer, the reluctance to mention 'security' in a changelog is often driven by the fear, uncertainty, and doubt that it may instill in users, rather than an unwillingness to admit mistakes. To create a more welcoming atmosphere, penetration testers and security researchers should consider improving their public image. This could involve adopting more approachable profile images, usernames, and communication styles, which currently can appear intimidating or off-putting.

A more inclusive approach to addressing security issues could include labeling them simply as "Security" and providing detailed descriptions on a separate page for advanced users, interested in more information. This could encourage better adoption by users with varying levels of security knowledge by simplifying the information presented to them.

[anonymized_20889438]

Replying to dd32:

But equally, there are often security fixes that are more of a 'hardening' change - something that is technically a vulnerability (perhaps often viewed by the author as nothing but a nitpick) but yet so extremely unlikely to actually ever be used to against a site, and that the fear of simply mentioning 'security' drives fear into authors.

Yup, agree with you. Maybe this case can be solved by additional reference information with examples?

Replying to yani.iliev:

As a plugin developer, the reluctance to mention 'security' in a changelog is often driven by the fear, uncertainty, and doubt that it may instill in users, rather than an unwillingness to admit mistakes.

How can this scare users and customers if the vulnerability is fixed? That is, in fact, the plugin has become better and safer.
I assume that these are the consequences of silence on security issues. If so, then sooner or later it will still have to be done. Don't be afraid of any security issues, we need to talk about it.

To create a more welcoming atmosphere, penetration testers and security researchers should consider improving their public image. This could involve adopting more approachable profile images, usernames, and communication styles, which currently can appear intimidating or off-putting.

NGL, for the first time in my life I hear such an opinion. Is this your personal experience as a plugin developer?

[lanacodes]

I would definitely recommend that even in the first version there should be trusted reporters (who are security researchers at a company, or who already have several verified reports that they can confirm with CVE) and average reporters.

Reports from average reporters must be moderated and approved before those reports go to the developer.

I am sure that average users would fill out the form and submit the report due to a malfunction or bug in the plugin. This needs to be made difficult for them.

I think that security reporters should also be encouraged to first try to contact the developer, either by email or via the contact form on the developer's website. There may be strange cases when the plugin developer has a different email address than the one he uses at wp.org, and he does not receive the reports, while the developer can be reached at the email address indicated in the description or elsewhere.

[oliversild]

This button should just be for a hyperlink, I don't think WordPress should force reports to go through its own system. Many plugins use platforms such as Hackerone, BugCrowd, Patchstack mVDP, etc. where security vulnerabilities should be reported.

[JavierCasares]

I'll comment later about this idea, but also wanted to share this proposal I started after the WordCamp Europe.

​https://docs.google.com/document/d/1od6gM_cA27QQ1PDL-Orfq7KTCsfAWlZcSL2QBsPJ26k/

[Ipstenu]

This button should just be for a hyperlink, I don't think WordPress should force reports to go through its own system. Many plugins use platforms such as Hackerone, BugCrowd, Patchstack mVDP, etc. where security vulnerabilities should be reported.

The problem here is that those people are the minority (seriously, over 100k plugins, I promise you less than 5% use those tools, and those who do are the ones who aren't the problem ... most of the time ;) ). So we should default to our system unless there's an alternative provided by the developer.

But.

If we remove the option to report via WordPress.org, then what happens if the developer ignores the report via their designated system? Of what if they want a report to be on their website, and the site is down?

We should always have a 'fallback' of 'report to .org'

Maybe add in a checkbox for "Yes, I tried the other route." but we have to keep a way for .org to get notified. Maybe not default, but still.

[oliversild]

Replying to Ipstenu:

This button should just be for a hyperlink, I don't think WordPress should force reports to go through its own system. Many plugins use platforms such as Hackerone, BugCrowd, Patchstack mVDP, etc. where security vulnerabilities should be reported.

The problem here is that those people are the minority (seriously, over 100k plugins, I promise you less than 5% use those tools, and those who do are the ones who aren't the problem ... most of the time ;) ). So we should default to our system unless there's an alternative provided by the developer.

But.

If we remove the option to report via WordPress.org, then what happens if the developer ignores the report via their designated system? Of what if they want a report to be on their website, and the site is down?

We should always have a 'fallback' of 'report to .org'

Maybe add in a checkbox for "Yes, I tried the other route." but we have to keep a way for .org to get notified. Maybe not default, but still.

I agree. Default option can be a WordPress.org form. It should just not be the forced way as in some countries we even have regulations in place that companies need to have their own responsible disclosure program and in these cases many would want to point to a security.txt on their site or to a bug hunting platform. Additional thought is that some might not feel comfortable if the security reports are passed through any third-party, so they would wish to link to their own form for privacy reasons.

[JavierCasares]

For me, there are two parts to talking about plugin/theme security (this should apply to both). One is the disclosure of a vulnerability and the other is the use of that information.

What happens when a vulnerability is found?

There are many possibilities and branches when it comes to vulnerabilities. The simplest one is the vulnerability in the WordPress core, which is directly managed by the Community through the Core-Security team.

However, it's not as straightforward when it comes to plugins and themes, as the Community provides review and management tools, such as the ability to disable a plugin or theme from the directory, but it doesn't have the tools or resources for full management. It shouldn't be something that the Community should handle on its own, although it is partially responsible for it.

When a vulnerability appears in a plugin, the Community and Teams initiate a process to try to notify the developer for them to review and fix it, with or unsuccessfully, but the responsibility lies with the developer.

Another approach is through standard systems like the National Vulnerability Database (NVD), which provides commonly known identifiers known as CVEs.

In these cases, a series of organizations are responsible for providing information to this database and maintaining it.

In the case of WordPress, there are three well-known organizations (Jetpack Protect, Patchastack, and Wordfence) that have this capability, although they are not the only ones. When a notification reaches any of them, they may try to contact the developer directly or do it through the Community teams. If, after a certain period of time, the vulnerability is not fixed, or even if it is, the information is published publicly and made available to everyone, either in real-time or with a certain delay.

Shared responsibility

While it is true that the primary responsibility of the Community is to keep WordPress secure, it is also true that many elements at various levels (such as the use of PHP or performance analysis) are not solely focused on the WordPress core and default themes, but also consider the extensibility of the platform.

Often, when you hear “WordPress is not secure”, it is not referring specifically to WordPress itself but rather to its extensibility, meaning plugins and themes.

In the past, attempts have been made to create some kind of platform for the Community to take full responsibility, but it was not feasible because, until recently, there were no relatively stable systems or companies maintaining that information. Additionally, other databases attempt to aggregate that data to provide a minimal service to all WordPress users.

Security-Vulnerability Team

As part of the Hosting Team, I received some feedback and engage with Patchstack, plugins, and security companies (such as WPSec, WPGuardian, or Really Simple SSL at WordCamp Europe 2023). Considering the increasing amount of information related to plugins and themes, and within the Five for the Future project, an opportunity has arisen to open a debate and conversation so that the Community can have a minimum level of security information that can be maintained by multiple sources.

Based on this entire situation, the option arises for these companies to participate through the Five for the Future project by donating and maintaining certain public information that can be utilized internally by both the WordPress.org/Meta website and the WordPress Core. Additionally, basic security information would be made public.

Furthermore, this system would allow these companies to continue their business while improving the entire ecosystem, enhancing security not only for WordPress itself but also for plugin and theme updates.

The team would be composed of two groups. These groups can consist of different individuals from existing teams or form an entirely new team.

The differentiation between the two groups is temporary, with the disclosure of a vulnerability serving as a turning point.

Plugins Security Working Group

The security group is the preliminary stage before the disclosure of a vulnerability. Currently, there are already some issues with those who discover a potential vulnerability and need to communicate it to the developers.

Although it is possible to automate the process without revealing data from either party, it is a delicate matter that requires some minimal supervision, either directly from a group of knowledgeable individuals, potentially creating the Plugin Security Team and the Theme Security Team, or by utilizing the same resources as the existing Review Teams, relieving Meta from this responsibility that they currently handle.

Security has its own global cycles in the industry, so efforts should be made to understand and adapt to them, something that is currently not being done.

This would help enhance the perception of security, making WordPress a more secure tool overall.

Receiving the information with a form, may be a suitable option, but also some plugins have their own platform to receive that, so (as plugins have their Commercial / Community link) we should provide that as a first option, and then, if not, and by default, an internal form.

Plugin Vulnerability Working Group

This working group would be responsible for maintaining the vulnerability database. These vulnerabilities would exclusively include those that have been previously published in some way and are specific to themes and plugins.

This database would operate based on the combination of the following elements:

slug + operator + version + fix

An example could be:

plugin-name <= 1.0.0 nofix

In addition to this basic information, it is necessary to use and unify information from different sources, using unique identifiers and creating unique identifiers specific to the Community.

From a technical standpoint, this system could be a Custom Post Type with multiple Custom Fields, and it could also utilize users as sources of information, as well as the API system.

The maintenance of this database could be done through a closed REST API, accessible only to verified sources approved by the Vulnerability Group.

This way, providers like Jetpack Protect, Patchstack, Wordfence, or others could update the data for the vulnerabilities they are responsible for, with the plugin and theme teams serving as other sources. Additionally, other potential participants with the knowledge to contribute could also be involved.

Although this project can be carried out in various phases, it would initially allow the Community to have its database for the use of the Teams, then for Meta, followed by WordPress, and finally open it to the Community for public access (not necessarily in that order).

Internal use by the teams can serve to temporarily block a plugin or theme from the directory if a vulnerability is deemed serious, or simply as a precautionary measure.

The use by Meta could enable displaying historical information about a plugin or theme's vulnerabilities on its listing page, or indicate if there is an active vulnerability at the moment. Additionally, if a plugin or theme is closed for security reasons, direct links to the information sources explaining the details can be provided.

For WordPress itself, through the existing API, it would allow for expanding information on whether a plugin may have any active vulnerabilities directly from the Site Health or the listings of plugins and themes.

Opening the information to the Community would allow anyone to use the open data, enabling the creation of plugins or tools that leverage this information to enhance the security of installations.

Documentation

Furthermore, these groups could take charge of centralizing the security documentation that currently falls under the responsibility of the Hosting, Core, Plugins, and Themes teams, primarily, and is spread across almost all projects within the Community, as well as the documentation for end users.

This is partially a summary from ​Internal Proposal: Make Security / Vulnerability Team.

Props @crixu, @davidperez, @desrosj, @frantorres, @mrfoxtalbot, @oliversild, @pharar.

[mrfoxtalbot]

I have opened a related ticket (#7259) to explore a MUCH simpler approach.