It’s been a year since Wordfence launched it’s WordPress bug bounty program. For majority of that year I took a break from client work and I spent most of my time as a security researcher looking for security related bugs in WordPress plugins. I put in over a thousand hours doing security code review on over 1,500 plugins in the WordPress repository. I have submitted over 150 security related bugs. The bug types and severity are a mix of small impact to big impact. My goal was to maximize the payout on the lower end bugs while searching for the bigger related bugs.
This is what I learned!
WordPress Security
From a security stand point, I realized plugins are actually a pretty big area where successful attacks happen. Meaning, sites getting hacked or compromised via plugins. Up to this point I weighed plugins as maybe 25% of the problem with WordPress security. (most online places were saying 50% or more) The biggest impact being weak passwords or lack of basic server related protection (stopping the bots).
Luckily since Wordfence’s bug bounty program there has been a massive clean up happening and the threat of plugins is way less than it was. But after reviewing thousands of plugin’s code and overall getting a feel of how other people are writing WordPress code I have come to a point of not trusting plugins at all! Or should I say, I believe any plugin has some sort of security risk, mostly because the ecosystem is about profits and promoting paid versions of plugins. This approach means there is less focus on writing secure code and more focus on cranking out features or duplicating other people’s ideas to make a quick buck.
Copy Pasta
I was amazed at how many people were straight up copying other people’s code. It’s opensource so they have the right to use it for their own purposes but there was no hiding the fact that they literally copy and pasted another plugin’s code. Usually the same kind of plugin, making their own version to try an sell a pro version. From a bug bounty stand point this was great! Once I found one security issue I could search other plugins and most of the time 1 bug would turn into 3-5 bugs. Same functions, same code, duplicated across multiple plugins. From a security stand point, you shouldn’t copy and use code if you don’t understand what it is doing. Just because some big name or respected company wrote some code doesn’t mean it is written in secure manner, or even an efficient manner. This is an important thing to remember especially with AI and all the insecure code it ALWAYS outputs.
WordPress Learning
I learned a lot about WordPress this year. I consider myself very knowledgeable when it comes to WordPress as I have spent pretty much my whole WordPress career (10+ years) writing custom themes and plugins. My philosophy was and is, keep plugins to a minimum, and only use what is really needed like WooCommerce, Yoast and a security related plugin. Also I really don’t like wading through other people’s code when something breaks or I need to expand on something. It was always easier to just write custom code to fit my needs and integrate it into WordPress natively so I don’t have to deal with anything breaking in the future.
But auditing other people’s code I got to not only see how other people are writing code for WordPress but explore areas that I really never needed to dive into. API endpoints probably being the most beneficial. I never really needed a custom API endpoint in my projects but now I know how it works and how to use it if I ever need to.
Surprisingly auditing so many Elementor addon plugins I have come to appreciate Elementor as a page builder. In fact I might even be switching my workflow to integrate it as the main UI for clients to self manage their websites. It feels like this is what WordPress UI should of been and needs to be. Elementor code is actually well integrated into WordPress core and the flexibility of extending the code or creating your own widget makes if very appealing from a development stand point. And since Wordfence and all the other WordPress focused security companies have cleaned up most of the bigger security bugs it seems like a good option. But a note to the reader, DO NOT use any Elementor addon plugins. About 50% of my security bugs I reported were Elementor addons and after wading through so many of them it is clear the people putting these out have no idea what they are doing and no clue about writing secure code.
Wordfence Bug Bounty Program
This was really my first bug bounty experience. And I would say I was pretty much doing bug bounty full time this whole year. The first 3 months was very lucrative as Wordfence was paying 625x. I will say the 625x rate (or maybe half of that) is probably closer to what their base rate should be compared to other bug bounty programs. Once the “normal” rates started it became very clear that some bug types and the lower install count plugins weren’t a good option for time spent verses payouts.
The triage in the beginning was super fast. Reports were getting validated and rewards getting issued in just a few days, the longest wait would be 5 days. And the way they setup payouts, it’s all automated bimonthly, so that was very nice. Over time as more promotions came and maybe more people joined the program the times got longer. But still pretty fast, hopefully they will be able to scale their triage process as reports scale.
The WF team is very responsive to questions or comments about your report, their discord is also very active and a good place to hangout. So the response time and customer service, amazing!
Manage your expectations. It became clear that the promos of big payout on bigger bugs were just a dangling carrot. In the beginning the only pay scale mentioned was “up to”, eventually WordFence put an estimated payout section on their website but the gap from min payout to max payout is a very large span. When I did come across a bigger bug or type that I hadn’t submitted before I got super excited thinking max payout! Since I was getting pretty much max payout on most XSS reports, but in reality the bigger bugs and bigger pay tables never seem to reward the max. I realized I had to stop expecting max and just assume min payout on the higher paying bugs. There are blog posts being written with max payouts on bigger bugs from the WF program, so they are paying max just doesn’t seem to be consistent across the board, at least for me.
Overall, for the Wordfence program, smaller bugs seem to get a more balanced payout (or max payouts) than the bigger bugs. Which ultimately makes their program smaller bug encourage-able. The current method of payouts based on number of installed plugins seems to be somewhat flawed in my opinion. I am not sure what can be done different, but it just seems like the time and effort it takes to pop a bigger security bug isn’t any better than finding a handful of smaller bugs that ultimately can pay the same if found on larger install count plugins.
In the end 75%+ of the bugs getting reported fall into the category of Contributor+. In fact up until last year I was unfamiliar with any roles outside administrator and subscriber. It is my opinion you shouldn’t give website access or assign any role to a person that you can not trust. I always enforced strict limited users on my client sites and never used or needed roles like Contributor, or Editor. Since there is no way to measure how many WordPress websites actually use a Contributor+ role Wordfence treats these bugs as impactful. From a security stand point this is the right approach, and from a bug bounty reward standpoint, this is great for the financial incentive!
In reality though, maybe 0.5 percent of WordPress websites are using Contributor+ roles. This brings the impact way down and in most instances it’s zero impact for website owners. This creates a lot of noise that there are lots of security issues, but really it’s just noise. Since I am aware of this noise, in the end it might have the opposite affect of making me overlook a real threat versus a non threat.