In the last few weeks, a security researcher called Anthony Ferrera found a relatively serious security bug in WordPress. The bug essentially allows attacks via the WordPress database functions, which were not as secure as intended.
The security bug affects WordPress 4.8.2 and all previous releases, and is fixed in 4.8.3.
Core updates are applied automatically, so while it’s likely that your site has been automatically updated to 4.8.3 by WordPress, it’s definitely worth a quick check as if the fix failed to apply for whatever reason you can pretty much guarantee your site will be hacked in the next few weeks.
For all practical purposes, it is very likely your site has been fixed although it does make sense to just check you’ve made it to 4.8.3. If you are an average person, you can stop reading here once you’ve done that. Those of you who like technical details might like to read a little more below and check out the links for further information.
Technical details for the techie minded
The bug, in summary, allows some of the security built into WordPress to be worked around, specifically, the security of the WordPress wp-db.php or $wpdb->prepare() mechanism. Usually, sites would be attacked through plugins that were relying on the security of $wpdb->prepare() and not correctly filtering user input.
One interesting thing about the process here is that Ferrera initially disclosed the bug to WordPress. They did fix it, at least they put in what they thought was a fix. When Ferrera told them that their “fix” wasn’t complete he was initially ignored and had to campaign to get them to take him seriously. The final fix does cover the secondary issues he found.
If you are a developer and you do sanitize all user input before using it in queries, or you use PDO or mySQLi, you are safe from this issue. (You should, of course, if you are a developer, be sanitizing ALL input from the user side).
Something that isn’t made clear anywhere that I can see up to this point – for there to be an exploitable loophole with this, there needs to be BOTH a bug in a plugin AND they also need to use prepare() in a really foolish manner (“double prepare()”). In fact I don’t think it’s unreasonable to say that any plugin that does have a loophole as a result of this problem has been coded really badly. Plugins should be checking user input (ie to find and remove SQL injection attempts) AND they should also be using prepare() correctly, which would provide a second layer of protection. The problem comes only when they do both wrong.
The corollary of this is that that, to this point, there is no “generic” loophole – it’s likely any exploits here will be very specific to poorly coded plugins. The likelihood of this being relevant to any major plugins is also reduced as plugins with a larger audience tend to be better coded. Here’s crossing fingers that I’m correct!
To date, we haven’t seen mass reports of exploited sites, so it appears that like many of these, that this bug hasn’t actually resulted in huge numbers of hacked sites. Perhaps that’s because everyone acted promptly to get their sites updated, or perhaps it’s just because it’s harder to exploit than expected!
Here is the WordPress announcement:
This is the announcement from the security researcher (Ferrara) which go into more detail: