Dear WordPress Community,

It hasn’t been a full month since we discussed the MailPoet security breach, and another disaster struck just a few days ago.

It Slider Revolution that , the popular slider plugin used by over 1,000 themes has a serious security issue allowing hackers to gain control of the affected site.

The Problem

The major problem is the global WordPress community’s current mindset and approach to security. After the Slider Revolution incident, its developers released a statement that, among other things, said:

The problem was fixed 29 updates back in 4.2 in February. We were told not to make the exploit public by several security companies so that the instructions of how to hack the slider will not appear on the web.

Saying “we were told to keep our mouths shut” makes me want to scream. It also seems to be on the border of being legally pursuable. Cases like this—with a major one occurring almost every month—have really hit a point of no return, at least for me.

Frankly, I am getting sick of this. I am getting sick of people calling WordPress an unauthenticated remote shell that, as a useful side feature, also contains a blog. This negative sentiment about WordPress is creating millions of dollars’ worth of damages for the thousands of businesses that rely on WordPress.

The problem affects millions of users, bloggers, and families whose sites are being hacked. It also slows down the worldwide adoption of the WordPress platform due to negative press in the media.

But things could be different. Things are different.

Thanks to the incredible effort of the community of contributors, I would say that today, the WordPress core is as safe as any CMS can be. The rough journey it faced over the past 11 years is also one of the key strengths of WordPress today. An incredible number of issues have been ironed out, and the project bearers have gained a vast amount of knowledge about web application security.

It is clear that the biggest threat to the project today lies in third-party plugins and, to a lesser extent, themes (which is ironically its biggest strength). I had the opportunity to witness this myself recently when I had to repair a bunch of hacked sites.

While MailPoet and Slider Revolution are examples of vulnerable plugins that were actively maintained, most of the danger lies in the thousands of plugins that are left alone and not updated anymore or in developers’ poor coding practices and lack of web application security knowledge, which causes them to write vulnerable code.

The WordPress repository currently includes 33,000+ plugins, with approximately 3,000 others in Envato. My rough estimate is that 2% of these have potential security concerns, ranging from the simplest forms of XSS/CSRF vulnerabilities to more dangerous broken authentication and session management issues. In other words, around 800 plugins at this moment could present a future danger to the WordPress community and the reputation of the WordPress platform.

What’s Being Done

There are security plugins such as iThemes Security and services such as Sucuri that help identify and fight hacks. I have also made it a personal quest to include a full suite of security tools in ManageWP by 2015. But we need to extinguish the fire at its source.

I cannot speak for Envato, but the WordPress plugin repository has undergone a number of improvements in recent years that help with this issue.

The Version Compatibility and Last Updated features tell the user if the plugin is actively being maintained. The longer a plugin goes without an update, the more likely it is to be a ticking bomb.

An effort to perform code reviews was introduced in the form of automated reviews (as far as I know) when new versions of plugins are submitted to the repository.

As a plugin developer, I was pleasantly surprised by a recent email when WordPress 4.0 came out notifying me that I need to check and update compatibility for my submitted plugins; the email provided a list of my plugins and their current compatibility.

However, people often don’t check to see when a plugin was last updated. Vulnerabilities, such as those described earlier, are difficult to find with automated code scans. I have 30+ plugins in the repository; how I can find time to update all of them to 4.0 compatibility let alone carefully check them against all the changes is beyond me at this point.

What Can Be Done

I think the community needs a scalable solution that will help create/enhance the perception of WordPress as a secure platform. This would involve a large-scale effort—no doubt about it. But the sooner we start, the better.

I propose a three-step process. The first step involves weeding out plugins with potential security issues. Given the sheer number of plugins to check, the wisest thing to do would be to call on the power of the masses and launch a crowd-sourced, white-hat security effort. This has been done before with success, and all the major web companies, including Facebook, are doing it. We had a lot of experience and success running our own white-hat security reward program, so I can tell you that this works. Over the years, it helped us find potential issues with the software, and we learned a great deal about this area. As a result, in the four years that ManageWP has existed and with over 200,000 managed websites, we have not suffered a single security incident.

This is exactly what WordPress needs, only on a larger scale. Luckily, it has a large community that can help achieve this. I do not want to go into detail about how to organize a white-hat program, but in my experience, the system needs to have strict set of rules and an automated process to avoid being overwhelmed with low-quality submissions.

If such a call for help was issued, I am sure that many would jump in, even without any promise of compensation or other incentives. A simple Hall of Fame (like this) in a prominent place on WordPress.org could do wonders. Simply by being on this list, those individuals will establish their reputation in the community, and they could get numerous job/consulting offers in the future.

To further improve the chances that the effort will succeed, the second step in the process involves a monetary reward for finding vulnerabilities. For example, $50–100 could be offered for finding XSS/CSRF issues, and $500 could be offered for finding a major vulnerability that exposes the entire website to hackers. Earlier, I estimated that 800 plugins are potential risks; assuming that the majority of the rewards would be for low-risk security issues, I estimate that around $150,000 would be needed to cover the rewards.

Once a vulnerable plugin is found, it would be quarantined. The plugin would immediately be suspended from the repository, a note would be sent to its developer, and the plugin would be placed on a public list with an explanation of the vulnerability and its effects. Developers (or the community, in another opportunity for a Hall of Fame) would be given a few weeks to fix the plugin; if it is not fixed, it would be removed permanently.

This also opens door for the WordPress Foundation to recruit people who perform well on this part of the challenge.

At the same time, an effort should be made to enhance the WordPress repository plugin verification process so all new plugins/commits are scanned. A good example of this is the way in which the theme review process advanced through the years. The last time I tried to submit a theme, which was two years ago, I was met with very strict requirements; eventually, I gave up (it required too much effort, and I wasn’t that keen on the theme). That really is a huge, fantastic thing. If you really want your theme in the repository where it will be exposed to millions of WordPress users, you should be required to put forth a lot of effort.

Plugins should absolutely get the same treatment. A great example is the tool from Symfony (which is a great PHP framework) that allows you to check your project for security vulnerabilities.

The third step involves making a conscious effort to educate the WordPress developer community beyond what is currently being done. The Foundation can do two things. First, it can create a vast knowledgebase on security (best coding practices, tools, tutorials) located on WordPress.org. Second, it can call 2015 “The Year of WordPress Security,” making this the main theme of all the WordCamps worldwide.

I estimate that the total cost of the project, including reviewers, process automation, software, and rewards, would probably be around $500,000. Given how much is at stake here, I think that amount is completely reasonable. Even if I am off by a lot and the cost is ten times more, it would still be reasonable to start this action today because of the huge effect it would have on the WordPress project and economy.

While most would expect Automattic to fund this, I think that does not necessarily need to be the case. This problem affects many WordPress-based businesses (plugin and theme shops, hosting, web design and development, etc.) as well as businesses that simply run their sites on WordPress. Why wouldn’t we all join the effort to make “our” platform better so our businesses can thrive in the future? As a start, I am ready to pledge $10,000 in the name of ManageWP to help fund this effort.

To recap:

The perception that WordPress is insecure is the greatest threat to the WordPress project today.

This is a large-scale problem that requires a crowd-based solution.

A combination of a white-hat security program, stricter code review, and investments in educating WordPress developers is the solution to this problem.

The cost may range from $500K to $5M, but the funds could be acquired from interested WordPress businesses.

You do not have to pledge funds to this effort; simply offering your time, experience, or opinion would be a great help. Please do not wait for your site/business to be compromised before you decide that this is something our community must do.

Sincerely yours,

Vladimir Prelovac