The Dark side of WordPress Security

May 15, 2023 code, wordpress

In 2015 I wrote a simple WordPress plugin that allows you to show your email address on the front end of your website but hide it from the source code aka obfuscate it, so it wouldn’t get picked up by spam bots. I called it Cloak Front End Email. The very original version only had one option, the admin email you had set in WordPress settings.

Later I expanded on the plugin to include options for other email addresses. This allowed parameters to be added to the shortcode. The goal of the plugin was mostly targeted towards admins who wanted this feature. My focus was on single user websites. Over 10 years developing WordPress websites I have never used or came across a website that utilized any of the additional roles. Subscriber, Editor, Author, or Contributor. (outside of WooCommerce’s customer role) I understand that WordPress has evolved into membership sites and guest blogging platforms, so these other roles do exist on WordPress sites in the wild.

In January of 2023 I received an email from WordPress stating my plugin had been deactivated and pending review for security reasons. There was a link to referencing the security issue. WPScan is now an Automattic Inc. endevor (same company that owns WordPress). Clicking on the link I see that wpscan and the person that reported it had already published a proof of concept on how to exploit the shortcode for XXS (Cross Side Scripting) as a contributor or above user role. No one had even reached out to me, and now the plugin was deactivated, not allowing anyone to download or even update any patch I submit. Within 30 minutes of receiving the email, I fired up my code editor and fixed the issue. Pushing the patch to WordPress. But this new patch wasn’t available, it was still frozen and unable to update. This is when I realized in the WordPress security community, there is no responsible disclosure mentality. All these WordPress specific security companies, plugins, or scanners, they are all about pushing out as many vulnerabilities as possible to get sales and sell their product. It is not about security it is about profits! Welcome to the dark side of WordPress security.

WPscan states on their website their responsible disclosure policy.

Initial Contact

WPScan will alert the appropriate Vendor of a security flaw in their affected item(s) in a responsible and timely manner. The initial contact effort will be made using any suitable contacts or formal channels stated on the vendor’s website, or by sending an email to security@, support@, info@, and [email protected] with the relevant details regarding the reported issue.If a Vendor does not respond to WPScan’s initial communication within three business days, WPScan may make a second official contact using a different method than the one used earlier, if publicly available.


Vendors are given 30 (thirty) days to resolve the vulnerability with a security patch or other appropriate remedial measure, this is extendable in cases of high complexity, limited to 120 (one hundred and twenty) days after first contact.

Yet non of this actually happened. WPScan did not attempt to reach out to me via email, or even my website that has a email form on it. The author URL is clearly stated in the plugin header and very easy to access. So I reached out to WPScan to ask about why they didn’t contact me. This was their response.

We first tried to find your email address to contact you, but since we didn’t find any email address, we escalated this issue to Plugin Review Team on 2023 Jan 10.

On the next day, the Plugin Review Team made the plugin unavailable, and as per our disclosure policy, we had to make it public: | It is mentioned there:

WPScan may issue a public alert stating its findings as soon as the Marketplace decides to remove the plugin, or make it unavailable for download on their website.

Having an easily findable email address for reporting security issues makes it less likely that issues like these will happen. So maybe next time, you can provide some way on the plugin so that we or any other similar platform can reach you directly before escalating it to the marketplace.

Straight from their team, no attempt to even contact me, even those random emails they say they send to, those don’t get sent. No 30 days to fix this, not even 24 hours went by before they submitted the freezing of the plugin and mark it as no patch known, and released a simple proof of concept on how to exploit the shortcode for any bad actors that might have a low privilege user trying to get admin access. (which by the way, the use case for this is actually being exploited was very small and based on 500 or less plugins installed, more than likely this wasn’t affecting many, if any websites)

Luke, I am your Father

Here is where the real dark side comes into play. If you look over these “leader boards” on a few different WordPress specific security sites you can see that there are tons and tons of disclosures happening daily. Based on the experience above Im sure there are plenty of plugin developers that are not being contacted and getting their plugins closed, or pending review.


Lana Codes the same person that submitted the report on Cloak Front End Email, was top researcher in January when my plugin was deactivated.


Again, Lana Codes at the top of the list (screen shot taken at time of this blog post). So why didn’t this person reach out to me? Again my website has a contact form, even phone number. Responsible disclosure should be happening on multiple fronts.

WordPress security companies that are paying “researchers” out of their own pocket without responsible disclosure seems like a conflict of interest. Going around and disclosing vulnerabilities without giving the developers a chance to patch it, is in fact fueling more security issues. Giving the away the keys to the kingdom so to speak. This is actually the opposite of security, the focus is on profits not security.

Bug Bounty Done Right

Ive been part of Hackerone for a few years. WordPress is actually part of their bug bounty program. I understand that small WordPress plugins can’t fit this model of signing up for a Hackerone account. And honestly most do not have enough code base to even bother. But these WordPress security companies and WordPress Plugin bounty programs need to take an approach like Hackerone on their overall process of disclosure. Just responding with we couldn’t find any contact information (even when it’s very clear on the developer’s website), so we disclosed anyways is unacceptable behavior, and completely irresponsible. Not to mention not even following their own policies and guidelines.


The lesson I have learned here is that everyone is human and we all make mistakes, despite how much of a perfectionist I am. This plugin was written almost 10 years ago. And despite all the time I spent actually testing the security from the outside in, I didn’t factor in a malicious internal user. Personally I am of the opinion that you shouldn’t give anyone any kind of access to your website unless you trust them. Obviously my coding and security skills are way better than from 10 years ago, so moving forward this will stick in my mind forever. And I will always ask myself when developing a third party plugin for WordPress, can a malicious internal user do anything they shouldn’t with a low level privileged user role?

I have mixed thoughts and emotions on this whole experience. One side, I am glad I got to experience this whole vulnerability process, it gives me a better understanding of what the other side feels like when they have a vulnerability disclosed in their code base. On the other side. I am not happy that this vulnerability status is forever, a permanent mark on the internet that is going to be associated with my brand. And quite possibly influence potential customers.