If you run WordPress, now is the time to check that your sites are up to date. On Wednesday, the developers released updates that fix several security flaws in the CMS. Shortly afterwards, the first attack attempts on one of them showed up, according to Wordfence, a security firm that specializes in WordPress.
The WordPress 7.1.4 release announcement lists nearly two dozen fixed vulnerabilities. The fixes have also been backported to older branches, namely versions 4.7.39, 4.8.34, 4.9.35, 5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24, 5.6.23, 5.7.21, 5.8.19, 5.9.20, 6.0.18, 6.1.16, 6.2.15, 6.3.14, 6.4.14, 6.5.14, 6.6.11, 6.7.11, 6.8.12, 6.9.11 and 7.0.8.
Malicious code during the update
The flaw that is already under attack has to do with the update process itself. When applying core updates, WordPress uses a predictable path that can be reached from the internet. Unauthenticated attackers can use it to inject and run malicious code while an upgrade is in progress (CVSS 8.1, rated high). At the time of the report, no CVE number had been assigned.
At first glance, this looks like an edge case. Attackers have to win a race against the installation and its cleanup routines, and in lab tests the staging directory was only reachable for a few seconds. Even so, Wordfence has already recorded active attempts. In the first 21 hours after rolling out a matching firewall rule, the company counted more than 18,500 requests probing for vulnerable setup-config.php installation paths. Two particularly busy sources kept polling small groups of WordPress sites for about 14.5 hours. Others varied the staging paths and version names they requested.
Why automatic updates play a role
Part of the reason these attempts have any chance at all is WordPress's automatic update mechanism. By default, WordPress checks for new versions on its own, downloads them and installs them. Only an upgrade using the full core package is vulnerable, though, because WordPress unpacks it into a predictable directory below wp-content/upgrade.
What you should do now
Check whether your sites have really installed the current version, and if not, update quickly. If the update was not yet in place, it is worth looking for signs of a break-in. Your log files may hold clues. Other red flags include:
- unexpected PHP files below wp-content/upgrade
- unknown admin accounts
- plugins you did not install
- PHP files nobody on your team put there
Back in late September, WordPress fixed another flaw that came under attack just hours after the patch. The pattern keeps repeating, and the window for patching stays small.