Pattern of Security Vulnerabilities in iThemes Security Plugin

This plugin has had a pattern of security vulnerabilities.

In 2016 alone, there were 4 serious security vulnerabilities published in the iThemes Security plugin:

• Potential Authenticated DOM Cross-Site Scripting (XSS)
• Insecure Backup/Logfile Generation
• Lack of Capability Check
• Unauthenticated Stored Cross-Site Scripting (XSS)

I would say that 3 vulnerabilities in a plugin of this type over a 2 year period would be too much, but 4 in 1 year is excessive. In all, your plugin has had 11 known vulnerabilities from August 1, 2014 to October 6, 2016 – just over 2 years. That is an extraordinarily high number for that short time period!

Even more alarming than the quantity of known exploits, is the fact that almost all of your plugin’s security vulnerabilities are easily predictable and therefore preventable if you have some basic security knowledge.

While your plugin may prevent certain specific security issues, by missing some basic security practices, you are opening up websites to other new vulnerabilities. This makes it seem that your development team doesn’t have a good grasp of security principles. And unfortunately, for a dev team that works on a security plugin, that doesn’t work.

One thing I will say in your defense – this is definitely a good trait – by all reports you have responded quickly to reported vulnerabilities, and issued fixes very quickly. So kudos on that…not everyone is so responsive.

Unfortunately however, with security it’s not enough to be responsive…it’s essential to predict and prevent threats.

Most end users will have no idea that your plugin is introducing new attack vectors into their site. They will think the plugin is working fine. (Until their site gets hacked.) And it may work quite well for the specific tasks you want it to accomplish. But the security issues negate the benefit, without users knowing any better.

From what we have read, you have had your own website hacked, and outsource your own website security to another company.

The question needs to be asked: If you don’t even manage your own security, should you really be developing a security plugin?

Here’s my point – please answer these questions:

• What are your plans to improve this plugin’s security and prevent new security vulnerabilities from emerging in the future?
• Are you going to hire any security experts to be part of the development team for this plugin, and improve its security moving forward?
• Do you have any plans to have security experts audit the plugin before each release?
• Is your development team going to receive advanced security training?

If your answer is to any of these questions is “No”, or you don’t have a clear answer, then the only ethical thing to do would be to retire the plugin altogether, or hand it off to a different development team that is competent in cybersecurity, and specifically WordPress security.

Looking forward to your response. Thank you for your time.