Akamai SIG’s Advanced Custom Fields (ACF) Attack Claim Confuses Script Kiddie With Attacker
In the past couple of days there have been scary sounding claims from journalists related to a recently fixed reflected cross-site scripting (XSS) vulnerability in the WordPress plugin Advanced Custom Fields (ACF), which we had detailed on May 4 after a machine learning (AI) based system we have flagged the fix being made. The journalists claimed that an attacker was trying to exploit this. With headline claims including, “Hackers target WordPress plugin flaw after PoC exploit released” from the Bleeping Computer, as well as “Hackers exploit WordPress vulnerability within hours of PoC exploit release” from CSO Online, and “ACF Plugin’s Reflected XSS Vulnerability Attracts Exploit Attempts Within 24 Hours of Public Announcement” from the WP Tavern.
Those stories are somewhat inaccurate, as they are citing another company’s disclosure a day after us as being when the vulnerability was disclosed. But the far larger issue is that it seemed highly unlikely that an attacker was really trying to exploit this. If this was true, it would be rather news worthy since we have seen no evidence of any wide scale exploitation of reflected XSS vulnerabilities in WordPress plugins. It turns out the source for those stories, Akamai Security Intelligence Group (SIG) confused a script kiddie with an attacker, leading to those misleading stories.
With the vulnerability, a WordPress user logged in with the Administrator role would need to access a URL specified by an attacker and JavaScript code included in the URL would then run for them. Akamai SIG was claiming that an attacker was making requests themselves. Unless they were logged in as an Administrator, that wouldn’t do anything (if they already had that level of access there would be no reason to try to exploit this). Yet, they were claiming the “attacker” was doing scanning:
Starting on May 6, less than 48 hours after the announcement, the SIG observed significant attack attempt activity, scanning for vulnerable sites using the sample code provided in the technical write-up.
That couldn’t work. The result they would get would be exactly the same if a vulnerable version of the plugin was being used, if a non-vulnerable version was being used, or even if the plugin wasn’t even installed on the website.
Even if an Administrator accessed the URL being requested by the “attacker”, say, because they saw it in a log, it wouldn’t do anything malicious, it would just show an alert box for them.
As we said earlier, it would be notable if an attacker was really trying to exploit a reflected cross-site scripting (XSS) vulnerability. But what looks to have happened here is that a script kiddie who doesn’t know what they are doing and didn’t do any testing first, tried to exploit this as if it was a different kind of vulnerability. That isn’t a new phenomenon or all that newsworthy, other than a reminder that you don’t have to worry about a lot of hacking attempts since they will fail on their own.
We tried to explain that to the author of Akamai SIG’s post, without getting anywhere, as it appears this person isn’t familiar with web security or understands that you can get news coverage while spreading FUD (fear, uncertainty, and doubt) related to the security of WordPress plugins.
Not the Only Issue
There are some other rather obvious issues with the claims made by Akamai SIG, which should have been red flags for any journalists considering covering this. For example, they claim that the developer of the plugin included a proof of concept when they announced the security fix:
On May 4, 2023, the WP Engine team announced the security fix in version 6.1.6, including sample exploit code as a proof of concept (PoC).
If you click on either link, you are not taken to an announcement, much less one with a proof of concept, which would be rather unusual to have been included. Here is the developer’s announcement blog post, which, unsurprisingly, doesn’t include a proof of concept.
Watch Out For Single Sourced Security Stories
All the stories we saw covering this relied on a single source for the claim, Akamai SIG. If the journalists had reached out to someone else, including us (we are available if any security journalist gets interested in running accurate stories about WordPress security), they could run more accurate stories or more likely not run a story, because there isn’t really a story here. Unfortunately, security journalists seem uninterested in getting their stories right, even with basic factual details, as we found recently. Despite that, we reached out to the journalists who wrote the stories mentioned earlier to let them know the stories are misleading, to put it mildly. We have yet to get any response to that.