WP Engine’s Poor Security Partially Explained by CTO Who Lacks Basic Security Knowledge
In WP Engine’s lawsuit against Automattic and Matt Mullenweg, examples of WP Engine using the WordPress trademark over the years also show that they have also made a big emphasis on handling security well. It hasn’t matched the actual results. In late 2015, they suffered a breach that required the “passwords for the WP Engine user portal, SFTP, the original WP-Admin account, password-protected installs and transferable installs, and the WordPress database” to have to be reset. Their explanation for the breach was that it came through the provider they outsourced the hosting of websites to. It was the same provider that had led to a more limited breach two years before. Either they could safely rely on outsourced infrastructure, but failed to properly vet it, or they couldn’t rely on that. Either way, they were promising security they were not delivering.
Their poor handling of security has continued in various ways in to the present time. It was just in May we found that they had failed to actually fix a vulnerability in one of their plugins. Compounding that problem, they were providing their customers warnings about vulnerabilities in WordPress plugins known to not be reliable information. Last year, their source had promoted WP Engine’s use of the source with a quote from WP Engine’s VP of Security admitting he hadn’t done basic due diligence. If he had done basic due diligence, he would have known the data provider isn’t reliable. Amazingly, that person is still employed despite publicly admitting to not acting professionally in a way that has put WP Engine’s customers at unnecessary risk.
How that person remains employed might be explained by the stunning lack of security knowledge of WP Engine’s Senior Vice President and Chief Technology Officer. In a recent legal filing, he made this claim:
I have been in the software industry for decades, and I have never heard of a situation where a company or developer publicly disclosed such a security vulnerability before allowing the developer of the plugin at least 30 days – if not 60 or even 90 days – to apply a security patch. In my experience, a notice period of at least 30 days, and often 60 or even 90 days, is the generally accepted industry standard
It is such a strange claim to make sense there has long been tension between security researchers and companies that are poor handling security. Here is an example of someone disclosing an unfixed issue in iOS after Apple wasn’t properly handling previous issues.
He also made another admission that isn’t great for WP Engine. There CTO has only been professionally working with for less than five years:
I have been working with WordPress in a professional capacity for more than four years.