Sudo Mode and a Secrets API Are Coming in 7.2

A WordPress administrator session has worked the same way for years. You log in once, and everything after that — adding a user, installing a plugin, writing a file — runs under the same cookie until it expires. The roadmap to WordPress 7.2, published on 18 September 2026, proposes to break that pattern for a narrow set of actions, and it targets early December 2026 for the release.

What sudo mode changes about the admin

The roadmap describes sudo mode in one line: it “gates sensitive actions behind re-authentication”. The model will be familiar from the command line. You stay logged in, but a small class of actions asks you to prove it is still you before they run.

The roadmap does not publish a final list of gated actions, and guessing one would be a mistake. The shape of the problem is clear enough without it. A stolen session cookie, an unattended laptop, or a cross-site scripting payload executing in an administrator’s browser all inherit full administrative authority the moment they land. Re-authentication stops none of those from happening. It puts a second obstacle between them and the actions that turn a nuisance into a compromise: user creation, capability changes, plugin and theme installation, and anything that writes a file to disk.

Agencies should plan for the support consequence before the technical one. A client who has never been asked for a password after logging in will read an unexpected prompt as a broken site.

Why a Secrets API is overdue

The second named feature is a Secrets API, which the roadmap says “offers a first-class way to store credentials safely”. Core has never had one. A plugin that needs an API key today puts it in the options table, in plain text, because that is the only mechanism core offers it.

Three consequences follow. A database dump taken for a routine migration carries every key in it. Anything with database read access — including a vulnerable plugin on the same install — can read them. And there is no inventory, so nobody can answer the question “which third-party credentials does this site hold” without reading the options table by hand.

A core API does not force plugin authors to adopt it. What it does is give reviewers something concrete to check for.

Application Passwords, hardened

The roadmap also lists “security hardening and UX refinements for Application Passwords”. These have been in core since 5.6 and are the documented way to authenticate against the REST API without a session cookie. Read that phrasing carefully: the REST API authentication documentation treats them as machine credentials, not as a login mechanism, which is the distinction behind passwordless login and two-factor setup on a WordPress site.

The risk profile is what motivates the work. An application password is a long-lived bearer credential. It ignores whatever two-factor prompt sits on the login form, does not expire on its own, and is revocable only if somebody remembers it exists. Sites that have moved to what passkeys support is actually available for human logins frequently still have forgotten application passwords sitting behind them, which puts the weakest credential on the account outside the strongest control on it.

HTML processing is a security workstream, not a polish item

“Work continues to harden how WordPress parses and processes HTML” reads like maintenance. It is not. WordPress 7.1.1, released 17 September 2026, shipped 11 security fixes alongside 17 core bug fixes and 19 for the block editor. One of them was a stored cross-site scripting issue in wpautop() that let an unauthenticated visitor inject script through a comment, subject to comment approval. Every function in core that rewrites author-supplied HTML with regular expressions is a candidate for the same bug class, and the HTML API work is the long route to closing them rather than patching them one at a time.

What to prepare before December

None of this requires waiting for a beta to act on.

• Inventory the Application Passwords on every site you manage and revoke any nobody can account for. Each is an active credential however long it has sat unused.
• Find where third-party credentials currently live — options rows, constants in wp-config.php, hard-coded strings in a theme — so that migrating them to a Secrets API later is a known job rather than a discovery exercise.
• Check whether any administrator account is shared between people. A re-authentication prompt is unworkable on a shared login, and shared logins are why this feature is needed.
• Review what REST API security looks like on your install now, since sudo mode gates the admin interface and not the API surface behind it.
• Book staging time for the 7.2 beta cycle. A re-authentication flow interacts with single sign-on, custom login pages and two-factor plugins, and those interactions are best found in November.

The roadmap is a statement of intent rather than a changelog, and features named in September have been deferred before. Treat the December date as the point at which you want to have already tested, not the point at which you start.