WordPress 7.1.3: Every Change Explained, Tested, and What to Do After You Update

First published on LetsKnowTech, where I keep it up to date.

WordPress 7.1.3 came out on October 6, 2026. It's a security and maintenance release with seven security fixes and four bug fixes, and it's the version every WordPress site should be on right now. WordPress.org already marks 7.1.0, 7.1.1 and 7.1.2 as insecure.

It's a small, low-risk release, so update. Fifteen files change, the database doesn't, and a site on 7.1.2 downloads a 227 KB patch instead of the full 37 MB package. One change is visible to readers, though: Imgur embeds stop working, and old ones keep showing until you clear their cache.

Below, every change in 7.1.3 is explained twice: once in plain words, and once for developers, with the file and function that changed. Everything in the "what we saw" parts comes from updating a real test site from 7.1.2 to 7.1.3 and checking each change before and after.

WordPress 7.1.3 release details

The official announcement is on the WordPress.org news blog, and the full code diff is in the 7.1.2...7.1.3 comparison on GitHub.

One correction if you read the official version page: its "List of files revised" isn't quite right. It names two Customizer files (class-wp-customize-manager.php and class-wp-customize-setting.php) that are byte-for-byte identical in the 7.1.2 and 7.1.3 downloads, and it leaves out wp-admin/includes/image.php, the toolbar stylesheets, about.php and version.php, which did change. You can see this in the GitHub comparison above, which never touches the Customizer files, or by comparing the two zips from the release archive yourself. We did both. The full list of changed files is in the developer section.

Should you update? Is 7.1.3 stable?

Yes, update. Three reasons:

1. It's a security release. WordPress recommends updating immediately, and the version API now marks every earlier 7.1 release as insecure.
2. The risk of breaking something is low. No database change, no new requirements, no bundled package updates, and the code changes are small. Most of the security patches change a handful of lines each.
3. If you're on 7.1.0 or 7.1.1, you're missing much more than these seven fixes. WordPress 7.1.2 fixed a critical flaw that could lead to remote code execution under some server setups, and that flaw is now being exploited. More on that below.

None of the seven issues is a drop-everything emergency on its own. Two can be started by someone who isn't logged in, and both need something else to line up. The rest need a logged-in account or an unusual plugin setup. But the fixes are public, and the patch shows exactly where each weakness was, so the gap between "patched" and "someone tries it" gets shorter every day.

How much each fix matters depends on how your site is used:

Is 7.1.3 stable? As of October 12, 2026, there are no reports of 7.1.3 breaking sites, and there's no 7.1.4 announced. The only change that visibly alters content is the Imgur one. The known WordPress 7.1 problems so far, and where each stands:

• WP Rocket below 3.23.2.2 crashed sites on 7.1 with Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given in .../wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php:562. That's fixed in the plugin, not in WordPress: update WP Rocket to 3.23.2.2 or later (released August 20, 2026).
• The toolbar site icon showing huge on some themes: fixed in 7.1.3.
• Image uploads failing on hosts without PHP's DOM extension (a 7.0 bug): fixed in 7.1.3.

If you run a lot of sites, test on one first. A copy of your site on your computer works fine for that; our WordPress localhost guide covers every way to set one up.

The 7 security fixes, explained

Here's the full list, with what an attacker would need for each one. "Contributor+" means anyone with the Contributor role or higher.

The credits come from the release announcement: three of the seven reports came from Anthropic and one from Trail of Bits working with OpenAI. The 7.1.1 credits also name Anthropic (twice) and pwn.ai. Three security releases in 19 days is a fast pace for WordPress, and the security team is shipping fixes as reports arrive rather than holding them for one big release.

A quick glossary for the terms below:

• XSS (cross-site scripting): someone gets their own JavaScript to run in another person's browser on your site. If that person is an admin, the script can act as the admin. "Stored" means the script is saved in your database and waits there.
• SQL injection: text an attacker controls ends up inside a database query and changes what the query does. "Second-order" means the bad value is stored first, looks harmless, and only causes trouble when WordPress reuses it later.
• Denial of service (DoS): making the server spend its resources on something useless, so the site slows down or stops answering.

1. Stored XSS on the Comments screen (pending comments)

In plain words: a comment waiting in your moderation queue could carry a booby-trapped link. If a moderator interacted with it on the Comments screen, script could run in the moderator's browser, with the moderator's permissions. Comments wait in that queue for exactly the people who can approve them, so the target is always a trusted user.

Who was exposed: sites running 7.1.0 to 7.1.2 with comments on. Before 7.1, a visitor's comment couldn't carry the markup this needed. WordPress 7.1 started letting comments keep a class attribute on span tags, so @mentions in Notes (the comments you leave on blocks in the editor) display properly; that's _wp_kses_allow_note_mention_span() in kses.php. Older branches got the same hardening anyway.

What changed in the code: the click handler for the contextual Help tabs in wp-admin/js/common.js passed a link's href straight to jQuery's $(). jQuery treats any string that looks like HTML as HTML to build, not as a selector to look up. 7.1.3 changes one line to $( document ).find( link.attr('href') ), and .find() only accepts selectors.

What to do: update. If you have a big pending queue from before the update, it's fine to moderate it after updating; the patched handler no longer builds HTML from those links.

2. Denial of service in WP_Http::make_absolute_url()

In plain words: WordPress has a helper that turns relative links (like ../image.png) into full addresses. Certain malformed paths sent it into a loop that never ended, tying up a server process. A logged-in writer could reach it through the editor's link previews, which fetch the page you're linking to.

Who was exposed: sites with Contributor or higher accounts held by people you don't fully trust, such as open registration with writer roles or guest-post programs.

What changed in the code: in wp-includes/class-wp-http.php, the loop that strips folder/../ pairs now counts how many replacements each pass made, and stops when a pass changes nothing. On older branches (before 5.9) the same class lives in class-http.php and got the same fix. We ran six ordinary relative URLs through the function on 7.1.2 and 7.1.3, and the results were identical, so normal link handling is unchanged.

What to do: update. Review who has writer accounts while you're at it (see the checklist).

3. Second-order SQL injection in the WXR export

In plain words: WordPress's export tool (Tools > Export) builds a list of featured-image IDs from each post's settings and drops them into a database query. It trusted that those IDs were numbers. If a non-number had already been stored there, through a buggy plugin or another weakness, the export could run an altered query when an administrator exported content.

Who was exposed: two things had to line up: a bad _thumbnail_id value already sitting in your database, and an administrator exporting a single content type. The default "All content" export doesn't reach this code. The code itself dates from WordPress 6.5.

What changed in the code: wp-admin/includes/export.php now runs absint() (force to a whole number of zero or more) on the thumbnail IDs, on the merged list of post IDs, and again right before each batch of 20 IDs goes into the WHERE ID IN (...) query. That's three layers for one bug, which is the security team being deliberately cautious.

What to do: update. Exports keep working; a single-type export on our 7.1.3 test site completed normally. If you move content between sites often, our guide on exporting posts with their media and featured images still applies unchanged.

4. Authors could make posts sticky

In plain words: a sticky post is pinned to the top of your blog's front page, and on default WordPress roles that's an Editor's decision. Through the REST API, an Author could pin their own posts anyway.

Who was exposed: sites with Author accounts. The impact is mostly editorial: someone can push their post to the top of your home page.

What changed in the code: in class-wp-rest-posts-controller.php, the sticky check refused a request only when the user lacked both edit_others_posts and publish_posts. Authors have publish_posts, so they passed. The fix changes "and" to "or": now a user missing either capability is refused. On updates, the check only runs when the request actually changes the sticky value.

What we saw: Authors' editing screen doesn't change at all. The block editor never showed them the "Stick to the top of the blog" toggle, because the REST API's action-sticky link already required both capabilities, even in 7.1.2. On 7.1.3:

• An Author setting sticky on their own post gets 403 rest_cannot_assign_sticky: Sorry, you are not allowed to make posts sticky.
• An Editor can still make any post sticky.
• An Author can still edit a post that an Editor made sticky (the save goes through and the post stays sticky).
• An Author can't unstick it.

What to do: nothing, unless you have a custom app or script that lets Authors pin posts. That will now fail with the error above. Have an Editor pin posts, rather than giving Authors edit_others_posts, which would let them edit everyone's posts.

5. Comments on private and unpublished posts readable without logging in (CVE-2026-66666)

In plain words: every post has a comment feed (an RSS feed of its comments). For private or unpublished posts, WordPress loaded the comments before checking whether the visitor was allowed to see the post. It then hid the post, but the comments were already loaded, and the feed printed them for anyone who asked.

Who was exposed: any site where private, draft or scheduled posts have comments. That's more common than it sounds: internal notes left as comments, client feedback on a draft, or comments left before a post was made private. It's tracked as CVE-2026-66666, rated 6.9 (Medium) on CVSS 4.0. The CVE record lists 6.6 through 7.1.2 as the affected versions. WordPress still shipped the same code change to every older branch down to 4.7, so a site on, say, 6.2 gets it as well, whether or not that branch could actually be attacked this way. It isn't in CISA's list of exploited vulnerabilities.

What changed in the code: in wp-includes/class-wp-query.php, the 37-line block that queries a single post's comment feed moved below the post-status check in get_posts(). Nothing in it changed; it just runs after WordPress decides whether you can see the post.

What we saw: on 7.1.3, a public post's comment feed still lists its comments, and a private post's feed returns no comments to a logged-out visitor.

What to do: update. If private posts on your site hold sensitive comments, assume anything public-facing before the update could have been read, and judge whether that matters for you.

6. XSS through Imgur embeds

In plain words: when you paste a link from YouTube, Spotify or another supported site, WordPress asks that site for the embed code. For a short list of trusted providers, WordPress inserts that code as it arrives. Everyone else's code is cut down to a sandboxed frame first. Imgur was on the trusted list, and its embed code includes text from the person who uploaded the image, so whatever that person wrote could end up on your page unfiltered.

Who was exposed: sites where Contributors or higher can publish embeds, and the readers of those posts.

What changed in the code: wp-includes/class-wp-oembed.php removes Imgur from the provider list. The file's own table of retired providers now lists Imgur as removed in 7.1.3, alongside Someecards (see the bug fixes). WordPress.org's Embeds help page still lists Imgur as supported; it hasn't caught up with the code yet.

What we saw: this is the one change your readers will notice, so we tested it closely.

• On 7.1.2, an imgur.com/a/... album link in an Embed block showed Imgur's full card, with its script loaded from Imgur.
• After updating, the old card kept showing. WordPress stores embed code in the post's metadata, and the update doesn't touch it. It survived re-saving the post, and it survived even when we backdated the cache by ten days and re-saved.
• After clearing the post's embed cache, the post showed the bare Imgur address as plain text: not an embed, and not even a clickable link. A plain Imgur URL on its own line in a classic-editor post did the same.
• In the block editor, the Embed block now says "Sorry, this content could not be embedded." and offers Convert to link.
• Links in the imgur.com/gallery/... form, which is what Imgur's address bar shows, already failed to embed on 7.1.2, because Imgur's own embed service no longer answers for them.

An Imgur Embed block after the update. Convert to link turns it into a normal link readers can click.

Imgur also cut off visitors from the UK in September 2025, so UK readers had already been seeing blank Imgur embeds.

What to do: update, then clear the embed cache for posts that use Imgur and replace those embeds. The checklist has the exact steps.

7. Forgeable {status}_{type} hook names

In plain words: when a post changes status (say, from draft to published), WordPress announces it to plugins with named "hooks" built from the status and post type, such as publish_post or draft_to_publish. Some unrelated core hooks follow the same naming pattern. If a plugin saved a post with a status nobody had registered, the generated name could match one of those unrelated hooks and set off code meant for something else entirely.

Who was exposed: only sites with a plugin that passes unchecked statuses or post types into wp_insert_post(). Default WordPress doesn't.

What changed in the code: wp_transition_post_status() in wp-includes/post.php now fires {$old_status}_to_{$new_status} only when the new status is registered and the old one is registered (or is new), and fires {$new_status}_{$post_type} only when the new status and the post type are both registered. The general transition_post_status hook still fires every time.

What to do: site owners: just update. Developers: read the developer notes. This one can change how your plugin behaves.

The 4 bug fixes

Two of these fix problems people hit after updating to 7.0 or 7.1. The other two update WordPress's list of embed providers.

Image uploads could fail with a fatal error (missing PHP DOM extension)

WordPress 7.0 added a feature that reads alt text embedded in an image's metadata when you upload it. That code used PHP's DOM extension without checking it was installed. On hosts without it, uploading an image stopped with:

PHP Fatal error: Uncaught Error: Class "DOMDocument" not found in .../wp-admin/includes/image.php 

WordPress lists the DOM extension as recommended, not required, and nearly every host has it, so this was rare. The code shipped in 7.0 and went 134 days before the first report (Trac #66221). For the sites it hit, though, it stopped all image uploads. In 7.1.3, wp_get_image_alttext() returns empty alt text when DOM isn't available, and the upload continues.

To check whether your host has the extension, go to Tools > Site Health. If it's missing, Site Health shows "One or more recommended modules are missing". Ask your host to enable dom; other features use it too.

Note that 7.0.7 doesn't include this fix. The 7.0 backport carries only the security fixes, so sites without the DOM extension need 7.1.3.

The toolbar site icon could show up huge

WordPress 7.1 added your site icon to the admin toolbar, sized with just a width and a height. Many themes and plugins have rules like img { width: auto !important; height: auto !important; }, which override those, so the icon rendered at the size of the image file and covered part of the page. People reported it on Divi and other themes (Trac #65912).

7.1.3 adds matching minimum and maximum sizes and a more specific selector (img.site-icon) in admin-bar.css. In our test with that exact theme rule, the icon measured 150 × 150 px on 7.1.2 and 20 × 20 px on 7.1.3 (28 × 28 px on a 390 px-wide phone screen). If you added custom CSS to work around this after 7.1, you can remove it now.

ReverbNation embeds work again

ReverbNation moved its site and embed service to legacy.reverbnation.com, and the old address returns "404 Not Found", so embeds of artist and song pages had stopped working (Trac #66079). On 7.1.2, a www.reverbnation.com/artist link didn't embed at all in our test. On 7.1.3 it embeds the player again. Links that already used legacy.reverbnation.com worked before through WordPress's generic embed support, and still do.

Someecards embeds removed

Someecards' embed service returns a 404, and its pages no longer advertise one, so 7.1.3 removes someecards.com and some.ly from the provider list (Trac #66078). Those links were already failing, so nothing that worked before breaks.

The 7.1.3 tag also includes some changes that never reach your site: trimmed automated-test runs for the 7.1 branch, a database health check for WordPress's Docker development setup, a test fix, and new unit tests for the alt-text function.

What we saw when we updated a test site

To see what 7.1.3 changes in practice, we installed WordPress 7.1.2 from the official download on a fresh test site, recorded how it behaved, updated it to 7.1.3 with WP-CLI, and ran the same checks again. The test site used PHP 8.2 and MariaDB 10.4 with the default theme, plus one extra rule that forces every image to its natural size, as some themes do.

The same post before and after the update, with the embed cache cleared: the toolbar icon is back to 20 px, and the Imgur album is now plain text.

Nothing else on the test site changed. The one change you'll see on a real site is the Imgur one, and only once the cache is cleared.

For developers: what could affect your code

Most of 7.1.3 is invisible to plugin and theme code. Five changes are worth checking.

1. Dynamic status hooks need registered statuses and post types. If your plugin stores posts with a custom status like in_review but never calls register_post_status(), hooks like draft_to_in_review and in_review_post no longer fire. The same goes for {status}_{type} when your post type isn't registered at the moment the status changes, for example while your plugin is inactive or if it registers the type late. In our test, the same transition fired both hooks again as soon as the status was registered. The fix:

add_action( 'init', function () { register_post_status( 'in_review', array( 'label' => _x( 'In review', 'post status', 'my-plugin' ), 'public' => false, 'internal' => false, 'show_in_admin_status_list' => true, 'label_count' => _n_noop( 'In review <span class="count">(%s)</span>', 'In review <span class="count">(%s)</span>', 'my-plugin' ), ) ); } ); 

If you can't register the status, listen on transition_post_status instead. It still fires for every change and passes the new status, the old status and the post:

add_action( 'transition_post_status', function ( $new_status, $old_status, $post ) { if ( 'in_review' === $new_status && 'in_review' !== $old_status ) { // Same job your draft_to_in_review callback used to do. } }, 10, 3 ); 

2. The REST sticky check is stricter. Changing sticky now needs both edit_others_posts and publish_posts. If your app sends the whole post object back on save, it's fine: on updates, a sticky value that matches the post's current state isn't checked. If it sends sticky: true on create for Author-level users, expect rest_cannot_assign_sticky.

3. Imgur is no longer a built-in oEmbed provider. wp_oembed_get() returns false for Imgur URLs, and the editor's /oembed/1.0/proxy endpoint returns 404 oembed_invalid_url. Don't re-add Imgur with wp_oembed_add_provider() as a trusted provider; that's the exact hole that was closed. Cached results stay in _oembed_* post meta and oembed_cache posts until cleared. On the front end, WordPress serves post-meta embed caches without checking their age, so they never refresh on their own.

4. Help-tab links are treated as selectors. The handler in common.js now uses $( document ).find( href ). If your plugin adds contextual Help tabs with WP_Screen::add_help_tab(), nothing changes; the generated #tab-panel-… links are plain ID selectors.

5. Comment-feed queries run later in WP_Query::get_posts(). The comment_feed_join, comment_feed_where, comment_feed_groupby, comment_feed_orderby and comment_feed_limits filters now run after the single-post status check instead of before it, with the same arguments. For a post the visitor isn't allowed to see, they no longer run at all. If you use those filters to log or count comment-feed requests, expect fewer calls.

Also changed but behavior-neutral for valid input: WP_Http::make_absolute_url() stops its cleanup loop when a pass changes nothing, and export_wp() casts every post ID with absint().

Every file 7.1.3 changes

These are all 15 files that differ between the 7.1.2 and 7.1.3 downloads. Nothing was added or removed.

Still on 7.1.0, 7.1.1 or 7.1.2? What you're missing

7.1.3 is the third security release since WordPress 7.1 "Mary Lou" came out on August 19, 2026. Updates are cumulative, so updating to 7.1.3 gets you everything below.

That's 19 security fixes in three releases.

If you're on 7.1.2, you need only the seven fixes on this page. Your update is a 227 KB download.

If you're on 7.1.1, you're also missing the 7.1.2 fix, and that's the serious one. CVE-2026-87902 let a visitor who isn't logged in make WordPress load a PHP file from outside the theme folder when it picks a page template. With the right server and theme conditions, that becomes remote code execution: an attacker running their own code on your server. WordPress rated it critical (9.2 on CVSS 4.0). And it's being used: the US Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog (search for CVE-2026-87902) on September 25, 2026, three days after the fix, which means there's evidence of real attacks. Your update is 236 KB.

If a site of yours sat on 7.1.0 or 7.1.1 after late September, don't stop at updating. Check it for signs of a break-in: admin accounts you don't recognize, PHP files in wp-content/uploads, and core files that fail wp core verify-checksums. Our security checklist has the full clean-up order if you find something.

If you're still on 7.1.0, you're missing all 19, including a stored XSS that a visitor could plant through a comment (fixed in 7.1.1). Your partial update is about 9 MB, because it also carries 7.1.1's bug fixes.

If a site has been stuck on an old 7.1 release, check why. Usually it's automatic updates being off, a host that holds updates back, or wp-config.php settings such as AUTOMATIC_UPDATER_DISABLED or DISALLOW_FILE_MODS. Our WordPress security checklist covers how to set automatic updates so security releases arrive on their own.

Older WordPress versions and backports

Only the newest WordPress version is actively supported. As a courtesy, the security team backports security fixes to older branches, currently all the way back to 4.7. The 7.1.3 backports all shipped on October 6, 2026, the same day as 7.1.3. The announcement said they were "in progress" when it went out, but every branch has its release now.

We checked each branch's code changes to see which fixes it actually received:

The full list of downloads is in the WordPress release archive.

A backport keeps an old branch from being trivially attackable, but that's all it does. Old branches don't get bug fixes, many plugins stop testing against them, and the older the branch, the older the PHP it was built for. If you're on 6.x or older, plan the move to 7.1 instead of relying on courtesy patches.

Moving from 7.0 (or older) to 7.1? That's a feature update, not just a patch, so test it on a copy first. According to the WordPress 7.1 Field Guide, the changes most likely to affect existing sites are these:

• The post editor now always runs in an iframe, even when plugins add old-style meta boxes. Check plugins that add boxes, styles or scripts to the editor.
• jQuery UI is updated to 1.14.2. Check plugins that use jQuery UI widgets such as date pickers, sliders and dialogs.
• The toolbar now stays available on editor screens. Check plugins that add toolbar items.
• Some image processing can now happen in the browser before upload. Check image-optimization and upload plugins.

How to update to 7.1.3

Take a backup first, or confirm your host's backup from today exists. Then pick whichever fits.

Automatically. Minor and security releases like this one install by themselves unless something turned that off. Go to Dashboard > Updates. If it says you have the latest version, you're done. The footer of any admin page and Tools > Site Health > Info > WordPress also show the version.

From the dashboard. Dashboard > Updates > Update to version 7.1.3. It takes a few seconds. There's no database update step this time.

With WP-CLI. Over SSH:

wp core version # what you're on now wp core update # updates to 7.1.3 wp core verify-checksums # confirms every core file matches WordPress.org's copy 

On our test site, wp core update fetched wordpress-7.1.3-partial-2.zip (the 227 KB patch for 7.1.2), and wp core update-db confirmed the database was already current.

Many sites at once. If you manage dozens of sites, use your management dashboard's bulk update, or loop WP-CLI over your sites with wp core update and wp core verify-checksums, then spot-check a few home pages. With three releases in 19 days, this is the month to set that up if you haven't.

Manually. Download WordPress 7.1.3, replace the wp-admin and wp-includes folders and the root PHP files, and leave wp-content and wp-config.php alone. You won't need this unless automatic updates fail on your host.

Rolling back. If something breaks, go back to 7.1.2 only for as long as it takes to fix the cause. You'd be reopening all seven holes.

After you update: a 10-minute checklist

1. Confirm the version. Dashboard > Updates should say 7.1.3 (or wp core version).
2. Verify core files. wp core verify-checksums should report success. A failure means a core file differs from WordPress.org's copy; find out why before moving on.
3. Find posts that use Imgur. In Posts > All Posts, search for imgur.com (do the same under Pages). With WP-CLI:

 wp post list --s=imgur.com --post_type=any --fields=ID,post_title 

1. Clear their embed cache. Re-saving the post doesn't do it; we tested that. Use WP-CLI:

 for id in $(wp post list --s=imgur.com --post_type=any --format=ids); do wp embed cache clear $id; done 

No WP-CLI? Open the post and replace the Imgur Embed block (next step). Once the Imgur address is no longer in the post, the cached code is never used again.

1. Replace the Imgur embeds. If the image is yours or you have permission, upload it to your Media Library and use an Image block. Otherwise, use Convert to link on the Embed block, so readers get a working link instead of a bare address.
2. Purge your page cache and CDN. Caching plugins and CDNs can keep serving the old Imgur card even after WordPress has dropped it.
3. Review writer accounts. Three of the fixes involve Contributors and Authors. List them under Users (filter by role), or with:

 wp user list --role__in=author,contributor --fields=user_login,user_email,roles 

Remove accounts nobody uses, and keep open registration on the Subscriber role.

1. Check Site Health. Tools > Site Health will flag a missing DOM extension and other problems worth fixing.
2. If you build plugins, search your code for register_post_status and for hooks shaped like *_to_* or {status}_{post_type}, and run your tests against 7.1.3 (see developer notes).
3. Delete custom CSS that shrank the toolbar icon after 7.1, if you added any. It's not needed now.

What comes next

WordPress 7.2 is scheduled for December 8, 2026, according to the release party schedule on the core team's blog. No 7.1.4 had been announced as of October 12.

Given the pace of September and October, more 7.1.x security releases before 7.2 wouldn't be surprising. The practical defense is the same as always: leave automatic minor updates on, keep a recent backup, and follow the WordPress releases feed so you hear about the next one on the day it ships.

FAQ

What is the latest version of WordPress?
WordPress 7.1.3, released October 6, 2026. WordPress.org's version check marks it as the latest and every earlier 7.1 release as insecure.

Is WordPress 7.1.3 safe to install?
Yes. It's a small security release with no database changes and...