DEV Community: Ansak Mahir

Elementor MCP: Connect Claude, Codex or Cursor, and Fix It When It Won't Work

Ansak Mahir — Tue, 03 Nov 2026 09:47:51 +0000

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

Elementor MCP is the MCP server built into the free Elementor plugin since version 4.3. You switch it on under Elementor > Elementor MCP, paste the prompt it generates into Claude Code, Claude Desktop, Codex or Cursor, and the AI can create pages, change them and publish them using Elementor's own widgets. Three things are easy to miss. It only edits pages built with Elementor's new Atomic (V4) elements. It needs WordPress 6.9 or newer, even though Elementor says 6.8. And a change it publishes to a page that's already live can stay invisible to visitors for up to a day, because of Elementor's element cache. Each of those has a fix below, and so does every connection error we ran into.

What you need first

Elementor 4.3.4 or newer. MCP arrived in 4.3.0. Version 4.3.4 fixed two MCP bugs: element settings could get lost when a page was updated through MCP, and the setup screen didn't warn you when Application Passwords were unavailable. 4.3.5 is the current release.
WordPress 6.9 or newer. Elementor's plugin listing says it needs 6.8, and the plugin does run there, but its MCP feature is built on the Abilities API, whose wp_register_ability() function arrived in WordPress 6.9. On a WordPress 6.8.3 site with Elementor 4.3.5 there was no Elementor MCP item in the menu at all, and opening wp-admin/admin.php?page=elementor-mcp directly gave "Sorry, you are not allowed to access this page." Update WordPress and the menu item appears.
Application Passwords that work. The AI client logs in with one. WordPress only offers them on sites served over HTTPS (or sites marked as local development sites), and some security plugins switch them off.
An administrator account to open the setup screen. Editors can use the connection, but they can't open that screen (which account to connect with).
The Atomic Editor switched on. It's on by default in Elementor 4.3.5, but if someone turned it off under Elementor > Settings > Atomic Editor, 12 of the 20 tools refuse to work, including every one that builds or edits (the error).
Pages built with Atomic elements, if you want the AI to edit them. It can read older pages but can't change them (more on that).
Node.js on your computer if you use Claude Desktop, because Elementor's Claude Desktop setup runs npx mcp-remote.

You don't need Elementor Pro. The free plugin gave our test site 20 tools. Pro adds headers, footers and other theme parts (below).

Turn it on and connect your AI client

In wp-admin, go to Elementor > Elementor MCP and click Enable MCP access.
Pick your client's tab: Claude Code, Claude Desktop, Codex, Cursor or Other.
Tick "I understand that clicking Generate Prompt will create an application password for this site", then click Generate Prompt.
Click Copy prompt and paste it into your AI client. The prompt asks the client to add the server to its own config file.
Restart the client, then check that the server shows as connected. In Claude Code, type /mcp.

The prompt contains a working application password for your admin account, in plain text. Treat it like your admin password: don't paste it into a shared chat, a support ticket or a screen recording.

Each click on Generate Prompt creates a new password with a name like "Elementor MCP - Claude Code (2026-10-18 12:42:34)". If you clicked it a few times while getting set up, delete the spares under Users > Profile > Application Passwords.

If you'd rather edit the config file yourself, click Prefer manual configuration? on the same screen. It generates the configuration block and tells you which file to paste it into.

Where each client's config goes

Client	Config file on macOS/Linux	Config file on Windows	How it connects
Claude Code	`~/.claude.json`	`%USERPROFILE%\.claude.json`	Straight to the site over HTTP, with an `Authorization` header
Claude Desktop	`~/Library/Application Support/Claude/claude_desktop_config.json`	`%APPDATA%\Claude\claude_desktop_config.json`	Runs `npx -y mcp-remote` with the same header (needs Node.js)
Codex	`~/.codex/config.toml`	`%USERPROFILE%\.codex\config.toml`	Straight to the site, TOML format (needs one fix)
Cursor	`~/.cursor/mcp.json`	`%USERPROFILE%\.cursor\mcp.json`	Straight to the site, with the header
Other	`~/mcp-config.json`	`%USERPROFILE%\mcp-config.json`	Same JSON as Claude Code

For Claude Code the entry looks like this:

{
  "mcpServers": {
    "your-site-elementor": {
      "type": "http",
      "url": "https://example.com/wp-json/elementor/mcp/",
      "headers": {
        "Authorization": "Basic BASE64_STRING"
      }
    }
  }
}

BASE64_STRING is your username, a colon and the application password (admin:abcd efgh ijkl mnop qrst uvwx), Base64-encoded. Elementor's prompt fills it in for you. If you're making one by hand, the spaces in the password can stay, and your account's email address works in place of the username. To get the string:

# macOS / Linux
printf '%s' 'admin:abcd efgh ijkl mnop qrst uvwx' | base64

# Windows PowerShell
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('admin:abcd efgh ijkl mnop qrst uvwx'))

In Claude Code you can add the server from a terminal instead of editing the file. --scope user makes it available in every project:

claude mcp add --transport http --scope user your-site-elementor https://example.com/wp-json/elementor/mcp/ --header "Authorization: Basic BASE64_STRING"

Codex: rename `headers` to `http_headers`

The Codex config Elementor 4.3.5 generates puts the password header under a headers table:

[mcp_servers.your-site-elementor]
url = "https://example.com/wp-json/elementor/mcp/"

[mcp_servers.your-site-elementor.headers]
Authorization = "Basic BASE64_STRING"

Codex CLI (0.163) doesn't read that key. codex mcp get your-site-elementor shows http_headers: -, which means Codex calls your site without the password and gets a 401. Change .headers] to .http_headers]:

[mcp_servers.your-site-elementor.http_headers]
Authorization = "Basic BASE64_STRING"

Run codex mcp get your-site-elementor again. It should now show http_headers: Authorization=*****.

Claude Desktop config on Windows: `npx` not found

Elementor's Claude Desktop config starts the connection with "command": "npx". On our Windows machine, Claude Code launched with exactly that config showed the server as failed, while the same mcp-remote command run by hand from a terminal connected fine. Windows installs npx as npx.cmd, and a program that starts commands without a shell doesn't find it. Wrapping the command in cmd /c fixed it:

{
  "mcpServers": {
    "your-site-elementor": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "mcp-remote", "https://example.com/wp-json/elementor/mcp/", "--header", "Authorization: Basic BASE64_STRING"]
    }
  }
}

If your Windows client already connects with the plain npx version, leave it alone.

On Windows the Authorization: Basic ... argument can also get split at its space on the way to mcp-remote, which turns into a 401. The way around that is to pass the header value through an environment variable, with no space after the colon. This version connected on our Windows machine too:

{
  "mcpServers": {
    "your-site-elementor": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "mcp-remote", "https://example.com/wp-json/elementor/mcp/", "--header", "Authorization:${AUTH_HEADER}"],
      "env": {
        "AUTH_HEADER": "Basic BASE64_STRING"
      }
    }
  }
}

ChatGPT

ChatGPT isn't one of the tabs. ChatGPT's custom connectors sign in with OAuth (or with no authentication at all), while Elementor's server expects an application password in a header, so the two don't connect directly. Our guide to connecting WordPress to ChatGPT covers what ChatGPT does accept.

What the AI can do with it

The free plugin exposes 20 tools. You never call them yourself; the AI picks them based on what you ask. They fall into four groups:

Group	Tools	Who can use them
Read the site	`list-posts`, `get-page-structure`, `list-widget-schemas`, `get-widget-schema`, `list-assets` (Media Library images, SVGs, videos), `list-components`, `get-default-styles`, `list-resources`, `read-resource`	Anyone who can edit posts
Build and edit pages	`create-page` (always as a draft), `build-composition` (adds a whole section from a layout), `manage-elements` (up to 50 edits, moves, duplicates or deletes per call), `update-page-settings` (hide title, layout)	Anyone who can edit that page
Check and publish	`create-preview-link` (a signed, short-lived preview the AI uses to check its own work), `publish-document`	Anyone who can publish that page
Site-wide design	`manage-global-variable` (colours, fonts, sizes), `manage-classes`, `reorder-classes`, `manage-default-styles`, `manage-component`	Administrators only (by default)

The widgets it can place are Elementor's Atomic ones: heading, paragraph, image, SVG, button, divider, YouTube, self-hosted video, div block, flexbox, grid, tabs, accordion, background video, form and collection loop. Saved components can be placed too.

On our test site (WordPress 7.1.3, the Hello Elementor theme, no global styles set up), Claude Code built a landing page with a hero, three columns and an FAQ in about two minutes. It saved the page as a draft, avoided inventing prices or reviews, and listed the lines it had written that the owner should check, such as "most boiler services take about an hour". A follow-up asking for a new heading, a dark green button and a fourth column took about a minute and touched only those parts of the page. For more of what the wider WordPress MCP setup can do beyond Elementor, see everything the WordPress MCP Adapter can do.

The page opens in the Elementor editor like any other page, with the sections named the way the AI named them ("hero", "features", "faq"). You can carry on by hand from there.

Two things it didn't catch on its own, and that you can put straight into your first prompt:

Two H1 headings. The theme printed the page title ("Winter Boiler Service Offer") as an H1, and the hero heading was a second H1. Ask it to "hide the theme's page title on this page". It turns on Hide Title in the page settings.
Content running edge to edge on wide screens, because no container width was set. Ask for "a centred column no wider than 1140px, with side padding on mobile". It created a reusable class and attached it to each section.

Old pages: "Legacy V3 element cannot be modified through this MCP"

Pages built with Elementor's classic widgets (the Heading, Text Editor and Button widgets most existing sites use) can be read but not changed. When we asked Claude to change the heading and button text on a classic page, every edit came back with:

Legacy V3 element cannot be modified through this MCP. Edit V3 elements directly in the Elementor editor.

The AI can't even read those widgets' text or styles. It only sees that a "heading" or "button" is there. You have two ways forward:

Make the change in the Elementor editor yourself. For a text change, that's the quickest route and it keeps your styling.
Let the AI rebuild that section with Atomic elements, then delete the old one. The new section won't copy the old fonts, colours or spacing, so check it before publishing.

To find out which parts of a page it can edit before you ask for changes, ask: "Which elements on the About page are version 3 and which are version 4?" The page-structure tool tags every element with its version.

Headers, footers and other Pro parts

We asked for a site-wide header with a menu and a footer with a phone number. Claude didn't build anything. The free plugin has no tools for theme parts, and Claude said so, offering to put a header block inside individual pages instead, which it advised against. Elementor's own MCP screen says that with Pro, "your agent can build with Theme Builder, forms, popups, and more advanced Elementor capabilities". Its tool descriptions mention separate site-parts tools for headers, footers, 404 pages and archives that only appear with Pro.

Changes on a live page don't show up

This one will confuse you if you don't know about it.

Edits wait until they're published

When the AI changes a page that's already live, Elementor stores the change as an autosave. Visitors see the old version until the AI calls its publish tool. If the AI says "done" and the live page hasn't changed, ask it to publish the page.

Then the old version can stay up for a day

After a publish through MCP, the database had the new heading, but the live page kept showing the old one. That happened every time we repeated it. The cause is Elementor's Element Cache, which stores the rendered HTML of each page for 1 day by default. Saving in the Elementor editor clears it; publishing through MCP didn't. To fix it:

Right now: go to Elementor > Tools and click Clear Files & Data. On the command line, wp elementor flush-css does the same thing. The new version showed up straight away.
If you'll edit live pages through MCP often: set Element Cache to a shorter time, or to Disable, under Elementor's Settings > Performance. With it disabled, the published change showed up immediately.
Clear your page cache plugin and your CDN as well, as you would after any change. Then check the page in a private window, logged out.

One order to avoid

On a live page, an element edit, then a page-settings change (such as hiding the title), then a publish lost the element edit. The page-settings save replaced the staged autosave. Claude ran into this by itself while fixing our page, noticed, and redid the edits. You can avoid it by asking for page-settings changes first, or by publishing the element edits before you change page settings. Either way, look at the live page afterwards.

Which account to connect with

The AI can do whatever the WordPress account behind the application password can do. Here's what three roles got on our test site:

Account	Create pages	Edit and publish any page	Site-wide colours, fonts, classes, components
Administrator	Yes	Yes	Yes
Editor	Yes	Yes	No ("Permission denied")
Author	No ("Sorry, you are not allowed to create posts of this type.")	No ("Sorry, you are not allowed to access this document.")	No

For everyday page work, an Editor account is enough, and it can't touch your site-wide design. The catch is that the Elementor MCP screen needs an administrator. To connect an editor:

Log in as the editor, go to Users > Profile > Application Passwords, and create a password.
Put that username and password into the config from the table above, with the server URL https://yoursite.com/wp-json/elementor/mcp/.

Two more things worth knowing before you connect an agent to a live client site:

"Turn off MCP access" doesn't revoke the password. It closes the MCP endpoint, but the application password still logs in to the rest of the WordPress REST API. With MCP turned off, the same password still changed a page through /wp-json/wp/v2/pages. To cut an agent off completely, revoke its password under Users > Profile > Application Passwords.
Try it on a copy first. A staging site or a local copy of WordPress lets you see how the AI handles your theme and your pages before it publishes anything real. On a local site, application passwords work without HTTPS as long as WP_ENVIRONMENT_TYPE is set to local in wp-config.php.

When it won't connect

First, find out what the endpoint itself says. Paste your username and application password into one of these and run it:

# macOS / Linux (or curl.exe on Windows)
curl -i -u "admin:abcd efgh ijkl mnop qrst uvwx" \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}' \
  https://example.com/wp-json/elementor/mcp/

# Windows PowerShell
$auth = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('admin:abcd efgh ijkl mnop qrst uvwx'))
$body = '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}'
try { $r = Invoke-WebRequest -UseBasicParsing -Method Post -Uri 'https://example.com/wp-json/elementor/mcp/' -Headers @{Authorization = "Basic $auth"; Accept = 'application/json, text/event-stream'} -ContentType 'application/json' -Body $body; "$($r.StatusCode) $($r.Content)" } catch { "$($_.Exception.Response.StatusCode.value__) $($_.ErrorDetails.Message)" }

Then match what came back:

You get	It means	Fix
`200` and JSON with `"serverInfo":{"name":"Elementor MCP"`	The site side works	The problem is in the client: check the config file, the Codex header, npx on Windows, then restart the client
`401` and `rest_forbidden`, "Sorry, you are not allowed to do that."	The password didn't log anyone in	Wrong password, or the header is being stripped
`404` and `rest_no_route`	No MCP route on this site	MCP access is turned off, or Elementor or WordPress is too old (no menu item)
`200` with a web page (HTML) instead of JSON	`/wp-json/` isn't reaching WordPress's REST API	Plain permalinks

When the client can't connect, Claude Code just lists the server as failed under /mcp and the AI says it has no Elementor tools, whatever the cause. The test above tells you which cause it is.

401 "Sorry, you are not allowed to do that."

All of these produced the same 401 on our test site:

a mistyped or revoked application password
your normal login password instead of an application password (it has to be an application password)
a correct application password that never reached WordPress

The last one fools people, because the password is right. Some servers, Apache with PHP running as FastCGI being the usual one on shared hosting, drop the Authorization header before PHP sees it. WordPress's standard .htaccess has a line that passes it through, but a hand-edited or older .htaccess may not. On our FastCGI test server, removing that one line turned a working connection into a 401. The PHP error log said:

Permission denied for MCP API access. User ID 0 does not have capability "read" | Context: ["HttpTransport::check_permission"] | User ID: 0

"User ID 0" means nobody was logged in: the password never arrived. Any one of these, near the top of .htaccess, brought the connection back:

# WordPress's own line, inside the "BEGIN WordPress" block, after RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# Apache 2.4.13 and newer
CGIPassAuth On

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

If none of them changes anything, your host may be stripping the header further up. Send them the error log line above.

"Application passwords are not available on this site"

Elementor shows this, and greys out Generate Prompt, when WordPress won't issue application passwords. On our test site it appeared as soon as the site was set as a production site still served over plain HTTP. Passwords created earlier stopped working too: they returned the same 401 as a wrong password.

Serve the site over HTTPS. WordPress decides this from the request it receives. If your site sits behind a proxy or CDN that talks to your server over plain HTTP (Cloudflare's Flexible SSL mode does this), WordPress sees HTTP and keeps application passwords off. Use an SSL mode that encrypts the whole way to your server, such as Cloudflare's Full (strict), or ask your host to pass the HTTPS flag through.
Check your security plugin. Several have a setting that disables application passwords. Turn that off, or allow them for the account you're connecting.
For a local test site, set define( 'WP_ENVIRONMENT_TYPE', 'local' ); in wp-config.php.

On Elementor 4.3.0 to 4.3.3, the screen didn't show this warning at all, so update to 4.3.4 or newer if the setup seems to do nothing.

A similar message, "Application passwords are turned off for your user account", means it's switched off for your account only. Enable it on your profile page, as the message says.

No Elementor MCP menu item

WordPress 6.8 or older: the menu item only appears on 6.9 and newer. On 6.8, the page URL gives "Sorry, you are not allowed to access this page." That message has other causes too, but here it just means the page doesn't exist yet.
Elementor older than 4.3.0: update it under Plugins.
You're not an administrator: only accounts that can manage options see the screen.

"This site needs the Atomic Editor turned on"

If the connection works but the AI comes back with:

This site needs the Atomic Editor turned on before this can be built. Turn it on in WP Admin → Elementor → Settings → Atomic Editor, then try again.

then the Atomic Editor is switched off on your site. With it off, all 20 tools still show up in the client, so the connection looks fine. But building, editing, reading widget lists and changing site-wide styles all return that message. Only a few things still work, such as listing posts, reading a page's structure, creating a blank draft and publishing. Turn it back on where the message says, and ask again.

`/wp-json/` returns your home page

With Settings > Permalinks set to Plain, a request to /wp-json/elementor/mcp/ returned our home page's HTML with a 200 status. The client can't make sense of that, so it shows as failed. On the same site, https://example.com/?rest_route=/elementor/mcp/ worked.

Elementor builds the server URL when you generate the prompt, so it matches the permalink setting at that moment. The problem appears when you switch to Plain afterwards, or type the /wp-json/ URL in by hand. Pick any setting other than Plain, or use the ?rest_route= form of the URL.

Turned off by mistake

If someone clicked Turn off on the Elementor MCP screen, the endpoint returns 404 rest_no_route and every client shows the server as failed. Click Enable MCP access again. The existing application passwords still work, so the clients reconnect after a restart without a new prompt.

That's all.

Written with AI assistance from my own test notes; the fixes were run on real WordPress installs before publishing.

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

Ansak Mahir — Tue, 03 Nov 2026 09:47:48 +0000

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


Released	October 6, 2026
Type	Security and maintenance release (a "minor" release)
Fixes	7 security fixes, 4 bug fixes
CVE IDs	One so far: CVE-2026-66666 (comments on private posts, CVSS 4.0 score 6.9, Medium)
Known attacks	None reported for any of the seven (but the critical fix in 7.1.2, which 7.1.3 includes, is under active attack)
Database change	None (database version stays 61833, so there's no "Update database" screen)
Requirements	Unchanged: PHP 7.4 or newer, MySQL 5.5.5 or newer (7.1 compatibility; the same minimums are in `version.php` of both releases)
Files changed	15 in the release package, none added or removed
Download size from 7.1.2	227 KB partial update instead of the 37.2 MB full package (the 15 changed files plus the updater and readme that every update package carries; measured October 12, 2026)
Older versions	Security backports for every branch from 4.7 to 7.0, released the same day
Next release	WordPress 7.2, scheduled for December 8, 2026

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:

It's a security release. WordPress recommends updating immediately, and the version API now marks every earlier 7.1 release as insecure.
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.
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:

Your site	The fixes that matter most to you
A blog with open comments	The pending-comment fix on the Comments screen, and the private-post comment leak
A site with writers (Contributors or Authors)	The Imgur embed fix, the link-preview slowdown fix, the sticky-post fix
A site with private or draft posts that get comments	The private-post comment leak (CVE-2026-66666)
A site where admins export content (Tools > Export)	The export fix
A site with custom plugins that use custom post statuses	The status-hook change (read the developer notes)
A simple brochure site with comments off and one admin	Little direct exposure, but update anyway: it's free and takes seconds

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 fix	What an attacker needed	Reported by
1	Stored XSS on the Comments screen, through pending comments	A comment waiting for approval, and a moderator (Editor or Administrator) interacting with it	Trail of Bits, with OpenAI
2	Denial of service in `WP_Http::make_absolute_url()`	A Contributor+ account	Anthropic
3	Second-order SQL injection in the WXR export	A bad value already stored in the database, and an administrator running a specific export	Anthropic
4	Authors could make posts sticky	An Author account	Anthropic
5	Comments on private and unpublished posts readable without logging in (CVE-2026-66666)	Nothing: no account needed	Ananda Dhakal (Patchstack)
6	XSS through Imgur embeds	A Contributor+ account, and someone viewing the post	Zhengyu Liu, Jingcheng Yang, Gavin Zhong
7	Forgeable `{status}_{type}` hook names	A plugin that saves unchecked post statuses or post types	Alex Concha (WordPress security team)

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.

What we checked	7.1.2	7.1.3
The update itself	—	Downloaded the 227 KB partial package; no database update needed; core checksums verified
Imgur album in an Embed block	Full Imgur card, script from Imgur	Cached card keeps showing until the embed cache is cleared, then plain text
Toolbar site icon under a "natural size" theme rule	150 × 150 px	20 × 20 px (28 × 28 px on phones)
Author pins own post via the REST API	—	Refused (403)
Author edits a post an Editor pinned	—	Works, stays pinned
Post moved to a status nobody registered	Both dynamic status hooks fire	Neither fires; `transition_post_status` still does
Publishing a post whose type isn't registered	`new_to_publish` and `publish_book` fire	Only `new_to_publish` fires
ReverbNation `www` artist link	No embed	Embeds
Relative-URL resolution (6 normal cases)	—	Identical to 7.1.2
Public post comment feed	—	Works
Single-type export	—	Works

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.

File	What changed
`wp-admin/js/common.js` and `common.min.js`	Help-tab click handler uses `$( document ).find()` (fix 1)
`wp-includes/class-wp-http.php`	`make_absolute_url()` loop exits when nothing is replaced (fix 2)
`wp-admin/includes/export.php`	`absint()` on thumbnail IDs, merged IDs and each query batch (fix 3)
`wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php`	Sticky check needs both capabilities; on update, only when the value changes (fix 4)
`wp-includes/class-wp-query.php`	Comment-feed query moved after the post-status check (fix 5)
`wp-includes/class-wp-oembed.php`	Imgur and Someecards removed, ReverbNation endpoint moved to `legacy.reverbnation.com` (fix 6 and two bug fixes)
`wp-includes/post.php`	Dynamic status hooks fire only for registered statuses and post types (fix 7)
`wp-admin/includes/image.php`	`wp_get_image_alttext()` returns early without `DOMDocument` (bug fix)
`wp-includes/css/admin-bar.css`, `admin-bar.min.css`, `admin-bar-rtl.css`, `admin-bar-rtl.min.css`	Toolbar site icon gets min/max sizes and an `img.site-icon` selector (bug fix)
`wp-admin/about.php`	"Maintenance and Security Releases" note for 7.1.3
`wp-includes/version.php`	`$wp_version = '7.1.3'`

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.

Release	Date	What it fixed
7.1.1	Sep 17, 2026	11 security fixes, 17 core bug fixes and 19 block editor bug fixes
7.1.2	Sep 22, 2026	1 critical security fix (CVE-2026-87902)
7.1.3	Oct 6, 2026	7 security fixes, 4 bug fixes

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:

If you're on…	Update to…	Security fixes included
7.0.x	7.0.7	All 7 (but none of the 4 bug fixes)
6.9.x	6.9.10	All 7
6.8.x	6.8.11	All 7
6.7.x	6.7.10	All 7
6.6.x	6.6.10	All 7
6.5.x	6.5.13	All 7
6.4.x down to 4.7.x	6.4.13, 6.3.13, 6.2.14, 6.1.15, 6.0.17, 5.9.19, 5.8.18, 5.7.20, 5.6.22, 5.5.23, 5.4.24, 5.3.26, 5.2.29, 5.1.27, 5.0.30, 4.9.34, 4.8.33, 4.7.38	6 of 7: the export fix isn't needed, because that code arrived in 6.5

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

Confirm the version. Dashboard > Updates should say 7.1.3 (or wp core version).
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.
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

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.

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.
Purge your page cache and CDN. Caching plugins and CDNs can keep serving the old Imgur card even after WordPress has dropped it.
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.

Check Site Health. Tools > Site Health will flag a missing DOM extension and other problems worth fixing.
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).
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 no new requirements. The only visible change in our test was that Imgur embeds stop working.

Is WordPress 7.1 stable?
7.1 itself has had three security releases and plenty of bug fixes since August. On 7.1.3, there are no known regressions as of October 12, 2026. If you held back from 7.1 because of early issues like the oversized toolbar icon or the upload error on hosts without the DOM extension, both are fixed in 7.1.3. If you use WP Rocket, make sure it's on 3.23.2.2 or later before moving to 7.1.

Will 7.1.3 break my plugins or theme?
Very unlikely. The changes that could affect code are narrow: plugins that use unregistered custom post statuses, apps that let Authors set sticky posts through the REST API, and anything that depends on Imgur embeds. See the developer notes.

Why did my Imgur embeds stop working?
WordPress 7.1.3 removed Imgur from its trusted embed providers to close an XSS hole. Old embeds keep showing until their cache is cleared, then they show as plain text. Replace them with uploaded images or links (steps).

Is anyone exploiting these vulnerabilities?
No exploitation has been reported for any of the seven, and the one with a CVE (CVE-2026-66666) isn't on CISA's Known Exploited Vulnerabilities list. The critical flaw fixed two weeks earlier in 7.1.2 (CVE-2026-87902) is on that list, though, so sites still on 7.1.0 or 7.1.1 are the ones at real risk.

What are the CVE numbers for WordPress 7.1.3?
So far only CVE-2026-66666, for the comments on private posts. The other six don't have CVE IDs or GitHub security advisories yet. Advisories for 7.1.1 appeared the day after that release, so these may follow.

Do I need to update if I'm on WordPress 7.0?
You should at least be on 7.0.7, which has all seven security fixes. But 7.0.7 doesn't have the bug fixes, and 7.0 only gets security fixes now, so moving to 7.1.3 is the better choice.

Does 7.1.3 change the database?
No. The database version stays 61833, so you won't see an "Update database" screen.

How big is the 7.1.3 update?
From 7.1.2 it's a 227 KB partial update: the 15 changed files, plus the updater and readme that every update package carries. From 7.1.1 it's 236 KB. From 7.1.0 it's about 9 MB. A fresh download is 37.2 MB.

When is WordPress 7.2 coming out?
It's scheduled for December 8, 2026.