Automattic’s WPScan Doesn’t Appear to Have Learned From Claiming Exploited Vulnerability Had Already Been Fixed
Automattic’s WPScan WordPress security service makes a lot of impressive sounding claims on their homepage, including being “Enterprise-strength” protection:
Enterprise-strength WordPress protection for everyone
Claiming you will be the first to know about vulnerabilities:
Be the first to know about vulnerabilities affecting your WordPress installation, plugins, and themes.
Claiming to have a team of security experts:
Dedicated team of WordPress security experts
Claiming to continuously monitor for new vulnerabilities:
Continually monitoring the web for new vulnerabilities
The real world results show that they are not just failing to deliver those results, but failing to even learn from their mistakes.
At the beginning of November, they claimed to have verified that a vulnerability had been fixed in a plugin named Beautiful Cookie Consent Banner, which they described this way:
The plugin does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).
There are multiple significant inaccuracies in that. Some of that is highlighted in a claim they made on Sunday, about what they said was a different vulnerability, though really is the same vulnerability:
The plugin does not have authorisation and CSRF check when updating its settings, and does not escape some of them when outputting them, which could allow unauthenticated attackers to perform Stored Cross-Site Scripting attacks. An initial fix was released in version 2.10.1, and completed in 2.10.2.
Note: The issue is being actively exploited
What that means is that they got what level of access was needed to exploit the original vulnerability wrong, missed that it could be exploited another way, and that even as inaccurately described the first time, the vulnerability hadn’t been fixed. So did they make sure to do the verification work this time, to avoid further problems? No. They still managed to miss another issue present as of 2.10.2, as the changing of settings was still not properly restricted.
With the latter entry, they claimed the vulnerability as being publicly disclosed on February 13, so somehow in the future:
In reality, we publicly warned on January 31 that the vulnerability had likely already been exploited. So WPScan failed on their being first to know claim and the continuous monitoring claim, as the monitoring we did of publicly available information, alerted us to this the day before that. Their late awareness isn’t a new issue, it has been going on for many years, so they don’t seem to care, which might be explained by the ability for WordPress security providers (and security providers in general) to get away with highly exaggerated claims about what they deliver to their customers.