The relationship between WordPress developers and security researchers has been strained for some time now. Recently it is so bad that vulnerability reporters are going rogue which is affecting site owners. In the past months we’ve seen multiple researchers drop 0-day information (vulnerability details with no current patch available) which has resulted in our security staff being in emergency mode to ensure plugins are getting updated quickly, before sites get hacked. In some rare occasions where sites get hacked before we can patch, we’re putting in even more time handling incident response and cleanup for every affected site.

This is not a healthy scenario for anyone involved. Developers are being rushed to produce patches, sites are getting hacked due to no fault of the site owners, security teams are putting in more time than normal towards remediation of hacks, and researchers are getting [bad] press over their actions.

Here are two articles from this week that in one shows a security researcher with great patience facing months of non-communication from the developers they reported a vulnerability to, and a second where it’s shown a different security researcher has stopped being nice and is now choosing to go full disclosure before attempting to contact plugin authors about vulnerabilities:

This scenario the WordPress and Security communities have got themselves in is a net loss for everyone involved (except the hackers), and it’s really quite saddening. Pagely’s Security Team has a strong background of doing the right thing in these cases, be it with reporting of vulnerabilities (including those in WordPress core and plugins) as well as received and triage vulnerability reports on behalf of others. We know that the process of reporting vulnerabilities can be a net-positive and does not have to go down the road that leads to sites being compromised.

Here we have four recommendations for Developers, plus an offer for Security Researchers and Developers alike.


These are our four recommendations:

1. Have a point of contact.

It would be surprising that one of the biggest hurdles for the security researchers may be simply finding out who to contact. The WP.org plugin repository understandably (for anti-spam and privacy reasons) does not include your email address or a contact form on plugin pages. Nor is it acceptable to publish details of a security finding in the plugin forums (this is the same as releasing the vulnerability since it’s a public discussion forum).

So take a minute to think. How do you want to receive security reports? Maybe include a security point of contact in the plugin’s readme/source files, or if you have a development website that you’re linking to from the plugin description page on WP.org, be sure to have either a generic contact form or specific page detailing instructions on how people can report security issues found in your code.

If you’re a development shop that has some funding, you also may wish to consider signing up for a bug bounty program like hackerone or bugcrowd, and use that as your point of contact.

What happens if a security researcher can’t find out how to contact a plugin author? Well, then they will reach out to the WP.org plugin team to act as liaisons to receive, triage, and report the issue to you, the developer.

Pro-tip: If the plugin team confirms a vulnerability, they will likely remove your plugin from the WP.org repo until you have a patch available.

2. Be appreciative.

Reading a report of a security flaw in your code base can bring up some negative emotions, especially if you’ve got your ego tied up in your code. Try to let any negative emotions slide away if they bubble up.

It helps to take a second before you start reading the report to imagine the reporting party as someone who already contributed multiple hours of their own time towards your project, free of charge. Treat them as you would someone who had a great idea or pull request that improved your code, not as a threat.

This is the step I see things break down the most. A developer gets, what they perceive as, a nasty email from a researcher. They take personal insult because they believe they’re being told their code is bad. Their reaction to this is to send an email maybe downplaying or demeaning the report which starts a negative downward spiral from where there is no positive outcome.

As a developer, imagine spending hours contributing to a project free of charge and when you unveil your improvements, the project lead acts dismissive or negatively towards your contribution. Would you feel comfortable contributing your time towards that project ever again? Probably not. Is it possible you may even have feelings of wanting to get even? Possibly.

Now imagine that contribution was a security finding? That security researcher has their means of getting even right there in the report they sent to the project in good faith. By making that same security report public, makes it an 0-day, sites get hacked, the project’s reputation is tarnished, and the developer still has to write and push a patch.

3. Communicate.

Don’t leave the reporter out of the loop while you work on a patch or review their report. Share your progress and timeline if you have one, even if it’s a long way off. Ask questions if you have any (some of these vulnerabilities are confusing the first time you read about them, it took me some time to really understand object injection and its risk).

If you inform the reporter you’re squeezed for time, or you’re having trouble understanding the issue, or maybe even just ask them their opinion of the proposed patch, sometimes they may offer to help.

Keep in mind the person reporting the vulnerability may have an internal timeline they assumed is sufficient (maybe 30, 90 or 180 days , but it’s always an arbitrary timeline until both parties communicate their expectations) and if the researcher doesn’t hear anything from the developer in that time frame, they may just report the vulnerability publicly so they can close the case and move on to finding more vulnerabilities. It doesn’t hurt to keep up communications, ask questions or share timelines and/or knowledge.

4. Transparency.

This last bit is for the users of your code. Be sure when you have a security release ready, you include a note in the changelog that the release contains a security related patch. Your users need to know that the version released addresses a security issue, so they know to update ASAP. Hiding or neglecting to include security notes from your code’s changelog, doesn’t mean the security issue never existed.

Neglecting to include a note that a version of the software includes a security patch is simply a disservice to a project’s users. If users don’t see there is a security patch in that release, then some will not bother to update their sites. Sites not getting security patches results in sites being compromised. The worst part is, during the incident response phase to clean up the mess the hack causes, it will be pointed out your plugin insecurity as the fault of the hack.

When Pagely customer’s experience a compromise we perform a detailed incident response which, is more than just a cleanup because, 99% of the time we will include details on what the initial attack vector was. It’s very common that if the cause of the hack was a plugin whose developer ignored or played down a security issue, the site owner chooses to remove the plugin from the site entirely. Understandably so, as the site owner feels betrayed and loses trust that the project’s developers will be honest with them about security concerns.


That’s the basics. I hope developers reading this take to heart some of the considerations. I believe nothing recommended above would harm a project’s reputation and, in fact, I would argue they improve the project’s reputation as being ran by mature developers who have earned their user’s trust.

For the few security researchers who may be reading this, especially if you agree with the importance of the above four points, here is our offer:

I know some of you have faced some difficulties when reporting vulnerabilities to the WordPress development community in the past. We would like to offer an olive branch in the form of assistance.

If you have had a bad experience reporting vulnerabilities to the WordPress development community (core, themes, plugins, whatever), and would like us to help, please reach out (contact us via the Pagely support contact form, and someone will route notification to our security team).

We will be glad to help you find the point of contact for a plugin (we have connections in the community) and even act as mediators, reviewing/confirming your report and reaching out to the plugin author on your behalf!

This would be a win-win. You can spend more time finding vulnerabilities and less time writing emails, while we help the affected project be more secure.

This offer has already been put into play, we helped Slavco Mihajloski just last week with reporting a vulnerability he found in NextGen Gallery. We would look forward to helping anyone else (both developers and researchers alike) who want to work towards a solution where vulnerabilities are patched, credit is properly attributed, and sites don’t get hacked.

We hope that this dilemma can be addressed, hopefully our offer to help act as mediators will get both security researchers and WordPress developers away from the road that leads to 0-days being released and sites being hacked, and onto a road of collaboration and mutual understanding (and where hackers have to do their own damned work to find vulnerabilities in the WordPress ecosystem).

7 Comments

  1. Erik Geurts
    Erik Geurts

    Unfortunately, security reports I’ve received as part of my involvement with an open source project, more often than not are expressed in a very unpleasant if not plain hostile tone of voice. If it is the objective of a security researcher to get the immediate attention of the developers, it might help a lot to show a bit more emphaty. There is a human being at the receiving end of the report, after all.

    Reply

    1. Robert Rowley
      Robert Rowley

      You are correct Erik, researchers sending reports that come off as arrogant or egotistical happens. And when the two sides come to no agreement on how things should be handled respectfully, then things will turn hostile.
      That’s where point #2 (Be Appreciative) becomes critical. Everyone’s first reaction to what they perceive is a nasty email is to fight back, but, I promise, if you fight hostility or unpleasantness with kindness and appreciation, you will come out ahead… but if you respond with more hostility, that is what starts the downward spiral towards hostility.
      I know it’s a lot easier said than done to “just be nice to them.” That’s why we’re offering help to both sides (researchers and devs) so if you’d like to vent to someone over a hostile reporter, or have us help you by acting as moderators for hostile reports, please reach out.

  2. Erik Geurts
    Erik Geurts

    Robert, we have a set of fine tuned and non-aggressive firsr responses in our Hackerone program, so I hope that the way our team communicate with researchers is perceived as professional and non-hostile. What I referred to was the initial impression about the professionalism of researchers when we receive their report, if it is full of blame and shame, or threats to disclose if we don’t fix in a very short period of time, for example. Researchers often seem to be seeking respect or recognition, but fail to understand the recipient of their reports are fellow human beings also hoping to be treated with respect, not robots with malicious intentions.

    Reply

    1. Robert Rowley
      Robert Rowley

      If the people handling initial responses are sending well tuned, non-aggressive responses (even in the face of an ego driven security researcher) then you’re already doing things right. 🙂 If a researcher goes off the rails against a professional and non-aggressive response to their report, then the only person who looks bad is the researcher going off the rail.
      So, I thank you for you and your team’s positive professional attitude. I hope that others learn to do the same (including developers and researchers alike)

    2. Ed
      Ed

      The problem with disclosure is that the security researcher is really in a no-win situation. Every possible course of action has problems:

      1. If the security researcher describes their timeline for disclosure in the report, then they are accused of making “threats to disclose” toward the developer.

      2. If the security researcher doesn’t describe their timeline for disclosure but later discloses the vulnerability (before it is fixed), then they will be accused of blindsiding the developer and not practicing responsible disclosure.

      3. If the security researcher simply chooses not to disclose the vulnerability before it is fixed, then it’s possible that the vulnerability will go unfixed for months (or perhaps it will never be fixed).

  3. Julien
    Julien

    Could you help me connecting the dots? The vulnerability from the blog post about Sucuri has been fixed by the developers months before the disclosure and it’s also not even WordPress related?

    p.s.
    I’m the author of the bog post 😉

    Reply

    1. Robert Rowley
      Robert Rowley

      Hey Julien!

      Thank you for the blog post you wrote which included a detailed timeline of Sucuri’s response to your finding an RCE in their server side scanner.

      The dots connecting Sucuri to this post, can be a bit muddled. Sucuri is considered a large player in the web security field, and they have contributed a lot to the WordPress security field (via security plugins for WordPress, Finding/Reporting vulnerabilities in WordPress, and speaking at many WordCamps.) The connection is that many people in the WordPress community look up to Sucuri as leaders of security, and may emulate them based on seeing them as an authority.
      I had written this article a day before reading your blog post, and believed that some of the points you mentioned Sucuri did that made things difficult for you (non-communication, lack of time-lines, etc..) fit well with my points #2 and #3 (mostly #3). Which is why I added the reference (I apologize for any confusion I caused by bad wording in the draft that got out initially. The link to your article was somewhat a last minute add (right after I read your article) and I failed to clarify you were a researcher who was facing issues I hoped to address but doing so respectfully.)

      While I have you Julien, I want to applaud the stoic attitude you maintained during the timeline of that report. I would hope more researchers would emulate such behavior as your own and not be so rash to rush to dropping 0-days to get their way (the other reference point in the opening of the article above.)