Still reeling from the REST API debacle, and with the Gutenberg Kerfuffle roiling as WP 5.0 approaches, the good people who develop WordPress – and I mean that sincerely, I believe them to be genuinely good people to whom I owe a great deal of gratitude – endured a terrible, horrible, no good, very bad day (*).
First, the Maintenance Release of WordPress 4.9.3 on February 5, 2018. WP 4.9.3 fixed 34 minor bugs, and introduced a great, big, major new one.
Bug icon by Dmitry Baranovskiy, from The Noun Project, CC BY 3.0
Somehow, the release was published with the critical auto-update functionality broken. A fix – WP 4.9.4 – was issued the very next day. But … since auto-update was broken, the fix can’t fix anything without manual action from an admin on each and every website. And who does that? Besides dedicated, responsible admins like you and me, I mean.
Surprisingly, my sites did auto-update to WP 4.9.4. I’m guessing because I explicitly enable auto-updates in my custom plugin. But an untold number – I’m guessing lots – of WP sites will stay stuck indefinitely on non-auto-updating 4.9.3, becoming increasingly outdated and vulnerable over time.
That would be a bad enough day for anyone, but on the same day as the release of WP 4.9.3, Israeli security researcher Barak Tawily announced his discovery of a serious vulnerability (CVE-2018-6389) in WP that could allow most WordPress websites to be taken offline by a relatively simple denial of service (DoS) attack. WordPress considered the vulnerability and decided to do … nothing (!), saying that DoS vulnerabilities “should really get mitigated at the server end or network level rather than the application level”. At the time of this post that remains WP’s position, even though Tawily has shown that the bug can be fixed in WordPress, and even wrote a patch to do just that. Not a good look for WP.
To be fair some security experts have noted that the reported vulnerability is not new – it has been around for years, just not reported. Some experts opine that the exploit is little different from any other DoS attack. That is not to say it is not serious, just that it should be handled – as WP contends – at the server or network level.
In the case of my websites, my CloudFlare page rules for login security should – I think – provide some protection against this particular exploit by setting an increased security level on the wp-admin folder, which this exploit targets.
(*) Credit to the excellent, renowned children’s book Alexander and the Terrible, Horrible, No Good, Very Bad Day, by Judith Viorst.
WPPOV supports freedom from Net Neutrality and the GDPR. The Internet of the people, by the people, for the people, shall not perish from the Earth.