Recently, a fairly serious vulnerability was fixed in the WordPress plugin 10Web Booster, which WPScan is claiming was discovered by Krzysztof Zając. That vulnerability allowed anyone to delete arbitrary WordPress options (settings). The vulnerability could have been most easily used to disable the website. That the vulnerability existed in the plugin isn’t surprising considering the developer has a long track record of poor handling of security. That includes another serious vulnerability found in this plugin earlier this year. After that earlier vulnerability was fixed, the developer ran the plugin through the PHP_CodeSniffer (PHPCS) software or some variant of it. The results of that are out of line with claims made about that software and the related WordPressCS.

Here was the vulnerable function that led to the option deletion vulnerability:

292
293
294
295
296

function two_activate_score_check() {
    if (isset($_POST['nonce'])) { // phpcs:ignore
        $p_nonce = sanitize_text_field($_POST['nonce']); // phpcs:ignore
        $nonce = get_option($p_nonce);
        delete_option($p_nonce);

You can tell the code was run through PHPCS or a variant based on the comments that read “phpcs:ignore”.

That code passes the value of the POST input “nonce” to the WordPress function delete_option(), which is used unsurprisingly to delete WordPress options. The only restriction on that is the value is passed through a sanitization function, sanitize_text_field() to strip malicious code from the value. That sanitization function serves no real purpose there.

While two lines contain “phpcs:ignore” to have PHPCS ignore them, the line that passes arbitrary values to the function WordPress options doesn’t, despite the security risk of it.

The fix changed the code, so a fixed value is deleted instead:

296

delete_option('two_activate_score_check_nonce_data');

While PHPCS didn’t flag that line, code like that is flagged by tools focused on security. At least that is the case with our own security tools for checking the security of WordPress plugins. It also is something we specifically check on with security reviews we do of WordPress plugins.

Is PHPCS a Security Solution?

The description provided by the developer of PHPCS doesn’t mention security:

PHP_CodeSniffer is a set of two PHP scripts; the main phpcs script that tokenizes PHP, JavaScript and CSS files to detect violations of a defined coding standard, and a second phpcbf script to automatically correct coding standard violations. PHP_CodeSniffer is an essential development tool that ensures your code remains clean and consistent.

Elsewhere, the story is different.

In a release announcement for the latest version of the related WordPressCS, usage for security checking was mentioned:

A large part of the WordPress community, including WordPress Core, relies heavily on the WordPress Coding Standards for code quality and security checks and while the community has been pretty vocal with copious complaints about the delayed release, barely anyone has stepped up and actually contributed.

A WP Tavern post about the release mentioned security checking as well:

The situation is alarming as WPCS is a foundational tool that flags not only code style issues but also critical security issues, making WordPress a more secure CMS.

Joost de Valk writing at Post Status recently stated:

Without these tools, our code would have more security issues, stability issues, bugs, etc. I can’t stress enough how important these tools are.

In the comments on the WP Tavern post, we mentioned the significant limitations when it comes to being used to identify security issues and one of the contributors of WordPressCS was dismissive of being more careful about how that was marketed.

It isn’t as if the vulnerability in 10Web Booster is the first time we have run across this software showing significant limitations. Over two years ago, we noted usage of WordPressCS had flagged code as insecure in a way it wasn’t, while the code was still very insecure after addressing the issue.

Why It Matters

Improving the security of WordPress plugins is clearly needed, but solutions that make plugin developers think they have secured their code when they haven’t are a hindrance to that.