The marketing strategy of a new WordPress security provider, Snicco, is largely built around pretending to not understand how security actually works. It is a strategy that works pretty well, since people who are interested in security, but not yet very knowledgeable, often won’t understand that they are being misled.

In the latest incident, Snicco is pretending to not understand why information, including API keys, has to be available in plaintext. They claim to have a new feature of their Fortress plugin, which solves that.

To promote this new feature, they mentioned a situation that it could prevent, except they admitted they didn’t even actually know what had happened in that situation:

While the specifics of how the hacker got their hands on the API keys remain speculative, the incident undeniably underscored the gravity of storing sensitive data in plaintext in the WordPress database.

Despite that, they claim to have a solution for the issue. That doesn’t make sense, but it gets worse.

They went on to make this claim about their solution:

This guarantees that there is no way to recover the plaintext data short of the entire web server being compromised.

It isn’t uncommon for WordPress websites to be hacked, but compromising the entire web server is much less common, so that claimed level of protection would be significant.

It would be significant, but it isn’t true. The author of their post making that guarantee admitted in the comments that isn’t actually true less than a day later, as they admitted their solution doesn’t limit PHP code from accessing the plaintext data:

Correct, PHP always has to have access; otherwise, all features will stop working (as long as they are implemented in PHP).

(Despite admitting that, they didn’t correct the post. Surely because they already knew that.)

You can run PHP code on a website without having control of the server. Shared hosting wouldn’t work if that wasn’t true. It isn’t uncommon for there to be vulnerabilities that allow hackers to run PHP code on a website. On Monday, we disclosed one such instance involving a 300,000+ install plugin, where the code allowing that has been in the plugin for 5 months.