WordPress 7.1.3 Fixes 7 Flaws (XSS, SQLi, Data Leaks): Update Now

I saw the WordPress 7.1.3 announcement dated 6 Oct. 2026 on the project's news page, so I read through each fix before putting together this article for fellow WordPress maintainers. There is no single standout vulnerability this time, but a set of seven spread across several parts of core, from comment management to export and embed handling.

What changed in 7.1.3

The WordPress announcement calls this a Maintenance and Security Release, with 7 security vulnerabilities and 4 general bugs fixed. According to the Version 7.1.3 page, changed files range from wp-admin/js/common.js, wp-admin/includes/export.php, class-wp-http.php, class-wp-oembed.php, and class-wp-query.php to post.php and the REST posts controller. No external packages were changed.

I have summarized all seven in the table below, with reporter credits as listed in the announcement.

For item 3, second-order means that data is safely stored in the database first, then later used to construct an SQL statement elsewhere without being escaped again. In this case, that happens when exporting data to a WXR file. Item 5 means that members of the public who are not logged in can read comments on posts that should be private.

Severity

I checked the 7.1.3 announcement and the project's Version 7.1.3 page, and neither page lists CVE IDs or CVSS scores. The project only says that this is a security release and “recommends updating immediately.” I will not guess at scores, but the conditions stated in the issue descriptions show these differences:

• Item 5 requires no login at all, but the result is information disclosure, not a server takeover.
• Item 1 requires a comment containing a payload to sit in the moderation queue, followed by someone opening comment management as an admin. This is a form of XSS that can be used to hijack an admin session.
• Item 4 requires an existing Author account.
• The announcement does not report actual attacks involving any of these issues, and because it contains no CVE IDs, I cannot look them up individually in CISA KEV. With information current as of 5 Nov. 2026, I can only say that I did not find the word exploited in the sources I read.

Who is affected, and which versions are fixed?

The announcement says these fixes are also being backported to affected older branches “as a courtesy,” and stresses that only the latest release is actively maintained. This means older branches may or may not receive backports, and the announcement does not provide a table listing the fixed version for each branch. You need to check the version offered in Dashboard or the project's releases page. I have therefore left out a table of older branch versions that I cannot verify.

How to update

From Dashboard, go to Updates and click Update Now, or use wp-cli on a machine where you manage multiple sites. This is the sequence I recommend:

1. Back up first Both site files and the database, with at least one copy you can actually restore
2. Update core Through Dashboard or wp-cli using the commands below
3. Check the version and checksums Then open the site and wp-admin to confirm they work normally

# รุ่นปัจจุบันและสิ่งที่มีให้อัปเดต
wp core version
wp core check-update

# อัปเดตเฉพาะ minor/security ในสายเดิม
wp core update --minor

# ยืนยันว่ารุ่นเปลี่ยนแล้ว และไฟล์ core ตรงกับต้นฉบับ
wp core version
wp core verify-checksums

If you are running as root, run the command as the site's user, for example sudo -u webuser wp core update --minor --path=/var/www/example.com, to avoid changing file ownership. For multiple sites, work through a list of directories.

while read -r p; do
  printf '%s : ' "$p"
  sudo -u webuser wp --path="$p" core version
done < sites.txt

Check whether you have been affected

The announcement does not provide indicators of compromise for this set of vulnerabilities. I can only suggest general checks based on the nature of each issue.

• Items 1 and 6 (XSS): inspect pending comments for script tags or unusual attributes, and look for newly added admin accounts.
• Item 4: look for sticky posts that their authors did not intend to make sticky.
• Item 5: the site itself keeps no trace. If it has private posts whose comments should not be public, assume those comments could be read while the site remained unpatched.
• Item 3: check database logs, if enabled, for exports at unexpected times, and review who has permission to export.

# คอมเมนต์ที่ค้างรออนุมัติ ดูเนื้อหาด้วยตา
wp comment list --status=hold --fields=comment_ID,comment_author,comment_content

# แอดมินที่ไม่ได้สร้างเอง และโพสต์ sticky
wp user list --role=administrator --fields=ID,user_login,user_registered
wp option get sticky_posts --format=json

Personally, I would not wake someone up to patch this set in the middle of the night, because the announcement reports no actual attacks and several issues require Author privileges or an admin opening the comments page. But I would not leave it until next month's maintenance cycle either. If the site allows public comments or has multiple users, update within one to two business days, depending on staffing. And now that 7.1.4 is available, go straight to that release instead of stopping at 7.1.3.

P.S. The announcement says backports were still rolling out when it was posted. If you are on an older branch, do not conclude yet that “there is no release available”; check Dashboard again.

Sources: WordPress 7.1.3 Maintenance and Security Release (https://wordpress.org/news/2026/10/wordpress-7-1-3-maintenance-and-security-release/), Version 7.1.3 (https://wordpress.org/documentation/wordpress-version/version-7-1-3/), WordPress 7.1.1 (https://wordpress.org/news/2026/09/wordpress-7-1-1-maintenance-and-security-release/), WordPress 7.1.2 (https://wordpress.org/news/2026/09/wordpress-7-1-2-release/) Information current as of 5 Nov. 2026. If CVE IDs or scores are published later, I will come back and add them.