Patchstack’s CEO Indirectly Admits Their Vulnerability Disclosure Program (VDP) Program is Unethical
Earlier this year when we were trying to figure how to contact the developer of Kadence Blocks plugin, which is a part of StellarWP, to alert them they had failed to fix a vulnerability in the plugin, we found their website had a page titled, “Responsible Security Disclosure Policy for KadenceWP.” That first paragraph of the page starts out by saying, “it is a standard practice in security research to responsibly and privately disclose discovered vulnerabilities to the software vendor prior to public release. This is even more critical when we work together to protect users in an open source space such as the WordPress community.” That sounds reasonable enough. (Responsible disclosure isn’t necessarily all that responsible, but that is an issue for another day.)
From there, they offer to help get the contact information for developers whose solutions extend theirs:
There are many third party developers that are building solutions on top of the Kadence Blocks plugin and the Kadence theme. If you believe you have found an issue with one of these third party offerings, we can likely assist in helping you find contact information for those developers if needed so that you can establish a secure communication channel for resolution.
That sounds good.
And then things take a turn, as the next section of the page starts this way:
Where do I report security issues?
The following products are handled through Patchstack’s managed Vulnerability Disclosure Program.
What? Why would they suggest reporting security issues to a third-party that is selling access to information about vulnerabilities? They don’t go on to provide an explanation for doing that.
The page then ends this way:
In all cases, you should not share the details with anyone else either privately or publicly until the vulnerability has been sufficiently patched. If you have a verified vulnerability, to ensure that the vulnerability is responsibly disclosed and can be tracked by the security community, we recommend requesting a CVE ID from an established CNA such as Patchstack and ensure that your CVE is scored by CVSS and entered into either the Patchstack or WPScan vulnerability database.
So you shouldn’t be sharing the information about the, even privately, with anyone else (including Patchstack, as they specifically cite), after they just told that is exactly what you should do.
The incoherence on display has a simple explanation, the page was edited last year to add in mention of contacting Patchstack (here is how it previously read). While ignoring that, it contradicts the rest of the page.
Patchstack’s CEO Admits This is Unethical
There are multiple reasons why directing reports of security issues away from developers to Patchstack, or any third-party like them, is a problem. There are additional issues specific to Patchstack. Either Patchstack isn’t aware of the general problems with that, which tells you they shouldn’t be handling vulnerability reports, or they are aware, and they don’t care, so they also shouldn’t be handling vulnerability reports.
One very big problem with this and similar programs is that they are focused on vulnerabilities, sometimes narrow bands of vulnerabilities. So you end up with nowhere to report lesser security issues. That is a problem we recently noted is the case WordPress and plugins coming directly from WordPress.
It was just in June that Patchstack’s CEO indirectly admitted what is going on here is unethical, as they wrote this on something called The Admin Bar (emphasis ours):
Sometimes developers and security researchers find bugs accidentally or when intentionally testing software security. If they are ethical, they would then report these security issues to the software vendor so they could fix this.
(Why that website ran something where the person writing it admitting they are unethical is its own issue.)
The problems specific to Patchstack include their continued failure to properly vet vulnerability claims and fixes, leading to situations where the WordPress community is unnecessarily scared about the security of a plugin and vulnerabilities haven’t been fixed. They then compound that by not providing a method vet their claims, as they don’t show what code was supposed to have been vulnerable, how it was supposed to have been fixed, or a proof of concept for the supposed vulnerability.
No Defense
We reached out to Kadence WP to point out the problems with what was there doing there and there really wasn’t a justification of the incoherence or directing vulnerability reports away from them. Instead, the response was basically we are going to continue to do this. That response is in line with them having failed to fix the vulnerability we set out to contact them about. They still haven’t fixed it months later.
They are not alone in that. We have now had interactions with two other developers about this. One of them, Elementor, we had the conversation both when they were direct reports to another vulnerability program that doesn’t involve a competitor of ours and then with Patchstack. In both cases, there wasn’t any defense of what is going on there.
Two of the three developers have long track records of handling security poorly. We are not familiar with the other, but based on some third-party information, it appears things are not much better.
Warning About This
The latest interaction about this with a plugin developer came not when we were trying to report an unaddressed security issue or vulnerability, but because our Plugin Security Scorecard had warned that their plugin was directing security reports to Patchstack (without naming Patchstack). So if you want to avoid plugins that are involved in Patchstack’s VDP, you can check if the tool is warning about that situation for a plugin.