Two WordPress security releases in two weeks. What they tell you
8 min readSecurity
WordPress 7.1.2 on 22 September fixed a critical unauthenticated path traversal rated 9.2, which attackers began probing on release day. WordPress 7.1.3 on 6 October fixed seven further issues, none confirmed as exploited. If you are running anything between 7.1.0 and 7.1.2, update now.
What was wrong in 7.1.2?
An unauthenticated path traversal in the function WordPress uses to pick a page template. It let an attacker, with no account and no login, make the site load a PHP file of their choosing from outside the active theme.
That is a local file inclusion leading to remote code execution on some servers — the worst class of web vulnerability, because it ends with someone else running code on your machine. WordPress rated it 9.2 out of 10.
The detail worth absorbing: Patchstack recorded probing attempts on the day the patch was published. That is the normal pattern now. A security release is a public description of how to attack every site that has not applied it yet.
The gap between a patch shipping and attackers using it is measured in hours. Any update policy built around monthly maintenance windows is a policy that accepts being exploitable for most of the month.
What did 7.1.3 fix?
Seven security issues and four bugs, two weeks later. None confirmed as exploited in the wild, and Patchstack characterised the release as important rather than an emergency.
Worth knowing what they were, because several depend on who has an account on your site:
Stored XSS on the Comments screen
Delivered through pending comments, firing when a moderator clicks. Reported by Thomas Chauchefoin of Trail of Bits.
Private post comments leaking
Comments on private and unpublished posts were reachable by logged-out visitors through comment feeds.
SQL injection in the export tool
Second-order injection in the WXR exporter, requiring an administrator to run a single-content-type export.
Author role privilege issue
Users with the Author role could make posts sticky, which is not theirs to decide.
XSS through Imgur embeds
Requires a Contributor account or higher, plus somebody viewing the post.
Why do user roles keep appearing in this?
Because several of these need an account to exploit, and most WordPress sites have accounts nobody has audited in years.
The freelancer who wrote three posts in 2023. The agency that built the site before you. The Contributor account created for a campaign and never removed. Each one is a Contributor-or-higher account, which is exactly what half of the 7.1.3 issues require.
Reviewing who holds an account is free, takes ten minutes, and closes more of this release than the update itself does for most sites.
What should you actually do?
Four things, in order:
Update to 7.1.3 now
Dashboard, then Updates. Sites on 7.1.0 through 7.1.2 are the exposed ones.
Clear your caches afterwards
Easy to miss and genuinely important: a cached page containing a malicious embed keeps serving it after the patch is applied.
Audit your users
Remove every Contributor-or-higher account that no longer needs to exist. Most sites find at least one.
Turn on automatic minor updates
WordPress applies security releases automatically unless someone has disabled it. On most sites that is the right setting, and on many it has been switched off by a plugin nobody remembers configuring.
Is WordPress unusually insecure?
No, and the volume of security releases is easy to misread. WordPress runs a large share of the web, which makes it worth attacking, and it has a well-funded security team that publishes fixes openly. Both of those produce headlines.
The sites that get compromised are almost never running current core. They are running a version from eighteen months ago, with eleven plugins, three of which are abandoned. The platform is not the variable — maintenance is.
Which is the honest argument for a care plan, and also the honest argument against needing one: if you reliably apply updates within a day or two yourself, you do not need to pay anyone. Most people do not.
Common questions
- Has my site been hacked?
- Most likely not, but check rather than assume. Look for admin users you do not recognise, PHP files with recent modification dates in wp-content, and unexpected scheduled tasks. A free scan through Google Safe Browsing tells you whether you have been blacklisted.
- Does WordPress update security releases automatically?
- Yes, minor and security releases apply automatically by default. The catch is that hosts and plugins sometimes disable it, and many site owners do not know it has been turned off until they check.
- I am on an older major version. Am I affected?
- The fixes were backported to older branches, though sources disagree on exactly how far back. Check the official release notes for your branch rather than relying on a blog post, including this one.
- Do I need a security plugin?
- Less than most people assume. Current core, current plugins, strong passwords and a short user list prevent more than a security plugin does, and a security plugin is itself more code that can have vulnerabilities.