Security
The third WordPress security release in a month fixes seven vulnerabilities, from stored XSS to SQL injection. Here is what each one means, and which sites should care most.
WordPress has released version 7.1.3, a security release fixing seven vulnerabilities and one bug rated critical. WordPress recommends updating immediately. Search Engine Journal has the original report.
It comes two weeks after 7.1.2, which fixed a flaw attackers started exploiting within hours of the patch. That context matters. Last time, the gap between "update available" and "attacks under way" was measured in hours, and there is no reason to assume this release will be treated differently.
The release notes list the issues by type only. Here is what each type of flaw means for a site owner.
1. Stored XSS. Cross-site scripting lets an attacker get their own JavaScript into a page. "Stored" means it is saved in the database and runs for everyone who views that page afterwards - including administrators. Script running in an administrator's browser can do anything the administrator can, which is why stored XSS is taken seriously even when it needs a login to plant.
2. Denial of service. A way to make the site slow or unavailable, usually by sending requests that are expensive for the server to handle. It does not leak data, but an outage on a lead-generating or ecommerce site has a direct cost.
3. Second-order SQL injection. SQL injection tricks the site into running attacker-written database commands. In the second-order variant, the malicious input is stored safely at first, then used unsafely later by a different part of the code. It is harder to spot in review, and a successful SQL injection can expose or change anything in the database.
4. Authors could make posts sticky. In WordPress, pinning a post to the top of the blog is normally reserved for Editors and Administrators. This weakness let users with the Author role do it too. Low impact on its own, but it is a permissions boundary that was not holding.
5. Unauthenticated disclosure of comments. Someone without an account could read comments they should not have access to. Depending on the site, that might include unapproved comments, which can contain names, email addresses or details people did not intend to publish.
6. XSS through Imgur embeds. WordPress turns pasted links from services like Imgur into embedded content. This flaw allowed that embed handling to be used for cross-site scripting.
7. Forgeable parameters leading to action name collision. WordPress uses named "actions" to decide which code runs for a request, and to check that a request is genuine. If the parameters behind those names can be forged, a request can be made to look like a different action than it really is - the kind of gap that can undermine those checks.
No single headline flaw. Unlike 7.1.2, this release has no one critical, unauthenticated exploit at its centre. It is a collection of mostly moderate issues. That is not a reason to wait: attackers compare patched and unpatched code, and a bundle of seven fixes gives them seven places to look.
Every site on an affected version should update. Some are more exposed than others:
The release also fixes a bug rated critical, and it is worth separating from the security fixes because it is a different kind of problem.
WordPress 7.0 introduced code that relies on PHP's DOM extension without first checking that the extension is installed. On hosts without it, image uploads could fail entirely with a fatal error. A core committer noted that the code had been live for 134 days before anyone reported it, which suggests almost every host already includes the extension.
If your uploads have been working, this did not affect you. If you have had unexplained image upload failures since moving to 7.0, this is very likely the cause, and 7.1.3 fixes it.
It is worth being clear about the limits of what is public:
Holding back detail until sites have had time to update is normal practice. It also means nobody outside the security team can tell you which of the seven is the most dangerous, so the sensible response is to treat the release as a whole as urgent.
1. Update to 7.1.3 and confirm the version in the dashboard afterwards. Do not assume an automatic update ran.
2. If you are on an older branch, check for its security release and apply it when it arrives. Better still, plan the move to the current branch - older branches still receive security fixes, but they can arrive later than the current release, as they have this time.
3. Review your user accounts. Remove anyone who no longer needs access, and check that each remaining account has the lowest role that lets them do their job. Several of these fixes matter only because someone had a login.
4. Review recent comments and posts for anything unexpected, particularly odd embeds or content you do not recognise from accounts that should not be publishing.
5. Check last week's work too. If 7.1.2 was never applied, 7.1.3 includes it - but the exposure window for that flaw has already passed. Our guide to the 7.1.2 exploitation covers what to look for in your logs and server files.
7.1.1 on 17 September, 7.1.2 on 22 September, now 7.1.3. Each one has been worth applying the day it shipped.
This is the pattern site owners have to plan for, not an unlucky month. A WordPress site needs someone who notices when a security release lands, applies it quickly, checks it actually went through, and has a tested backup ready in case it breaks something. Updating "when we get round to it" no longer works when attacks can start the same day.
That is what our website maintenance and support service does for the WordPress sites we look after. If you are not sure which version your site is on, or who is responsible for updating it, talk to us and we will check it with you.
Need a hand with this? Orange Orbits builds and markets websites for businesses across the United States. Book a free 45-minute scoping call and we will give you a straight answer about your specific situation.
Keep reading
An update stops new attacks. It does nothing about files an attacker already wrote to your server. If your site was patched late, here is how to find out whether someone got in first.
Read articleA critical flaw in the best-selling Avada theme lets an attacker take over a WordPress site with no login and no click. The fix has been out for weeks. Many sites still have not applied it.
Read articleExploitation attempts against a WordPress core flaw started within hours of the fix shipping. The patch window is now measured in hours, and that changes how sites should be maintained.
Read articleBook a 45-minute call. We will ask about your goals, your constraints and your timeline, then send a written recommendation with real numbers. If we are not the right fit, we will tell you who is.
