WordPress 7.1.2 Security Release: What It Means for Your WooCommerce Store

WordPress 7.1.2 came out on 22 September as a security release. It fixes one vulnerability, rated critical: 9.2 out of 10. On some sites it lets an attacker who isn’t logged in run their own code on the server, and WordPress recommends updating immediately.

For a store, “their own code on your server” means customer data, orders and the checkout page itself, nine weeks before the busiest weekend of the year. Here is how to tell whether your store is exposed, and what to do today.

The attack needs three doors open at once: an old WordPress, a particular theme and a particular server. Answer three questions about your store and watch how far an attacker would get.

1. Your theme. The active theme, or its parent theme, has a top-level folder whose name starts with page- — for example page-templates. The advisory names Twenty Twelve and Twenty Fourteen and the popular Neve, Hestia and Sydney. Keeping page templates in a page-templates folder is a common habit, so a theme that isn’t on the list can still qualify.

2. Your server. The attacker needs a suitable PHP file that the server can read. The known route uses PEAR’s pearcmd.php when a PHP setting called register_argc_argv is on. The advisory says the official PHP Docker image and the default cPanel setup with PHP older than 8.5 are affected.

In plain wordsAn old WordPress alone isn’t enough: the theme lock and the server lock have to be open too. You can check the theme yourself in a minute. The server is a question for your host or developer — which is why updating is quicker than finding out.

WordPress installs security releases by itself if automatic background updates are on. On many stores they are off on purpose: the site is deployed from Git, an agency applies updates in batches, or the host manages WordPress. Then 7.1.2 waits until somebody installs it.

Our own site is set up that way, so this week the update goes out through our normal release, not by itself. Open Dashboard → Updates on your store and check what it says.

This is the one kind of change that goes in even during a code freeze: a security fix, tested on staging, then released.

It is also why we update stores in October. WordPress backported this fix to old versions as a courtesy, but only the latest version is actively supported. A store that stays current takes a fix like this in an hour. A store that has skipped a year of updates usually needs a round of plugin and theme updates first — the kind of work you want to do in October, not in the week before the peak.

• Patched versions: 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9 and so on back to 4.7.37 — the full list is in the advisory.
• Theme: ls -d wp-content/themes/<theme>/page-*/ for the active theme and its parent.
• Server: check register_argc_argv for the PHP that serves the site — a phpinfo page, not the command line, where it is usually on anyway — and whether pearcmd.php is on PHP’s include path.
• Git deploys: with AUTOMATIC_UPDATER_DISABLED or DISALLOW_FILE_MODS in wp-config.php, core is updated in the repository and deployed like any other release.
• If the store met both conditions before the update: look for new administrator accounts, PHP files in wp-content/uploads and recently changed theme files.

Keeping WordPress, WooCommerce and plugins current, security releases included, is part of our WooCommerce support. If you want to know where else your store is exposed, that is our WordPress security audit.