Skip to content
All systems operational Knowledge base Panel

Security · WordPress

WordPress 7.2: What’s Coming in the New WordPress Version and How to Get Your Site Ready

WordPress 7.2 lands in December with sudo mode, a Secrets API and stricter Application Passwords. See what changes and what to check before the beta.

Redação Amicatek8 min read

WordPress 7.2 is expected in the first half of December 2026 and, going by the roadmap the core team has published, it is shaping up to be one of the most security-focused releases in years. The highlights are re-authentication before sensitive operations, a native way to protect API keys, and stricter rules for Application Passwords. The first beta is due between October 20 and 22, which gives anyone responsible for a WordPress site roughly two weeks to review the changes before testing starts.

In this article we cover what is planned, what is not expected to ship, and the checks you can already run on your site. One caveat up front: a roadmap is not a guarantee. The official post says the listed features are still in development and may be pulled before the final release. The definitive list arrives with the Field Guide, close to the Release Candidate.

The WordPress 7.2 release schedule

Published on September 18 by Anne McCarthy, the official announcement only says the release will land in early December. The dates below come from outlets that follow the development cycle closely:

Phase Expected window
Beta 1 October 20–22, 2026
Release Candidate 1 November 17–19, 2026
Final release December 8–10, 2026

The new version will be presented in a livestream rather than at an in-person event.

Security features planned for WordPress 7.2

Three items on the roadmap directly affect access to the admin area and the connections your site keeps with other services.

Sudo mode: an extra confirmation for critical operations

The idea is to ask for identity confirmation again before allowing certain high-impact admin tasks, even when the user is already logged in. The concept mirrors how sudo works in a terminal and what GitHub does for important changes. Even if an attacker gets hold of a session cookie, they would not immediately be able to add administrators or install plugins.

The feature is still at an early stage. So far there is no published list of which actions will require re-authentication, or how long that confirmation will remain valid. For organizations, the main consequence is operational: for some tasks, the people who work in the dashboard will face one more step, and that is worth communicating in advance.

Secrets API: dedicated storage for credentials

Today, many plugins save OpenAI, Stripe and payment gateway keys directly, unencrypted, in the wp_options table. The Secrets API aims to offer protected storage built into WordPress core. The plan for 7.2 is to ship the API with WP-CLI support; management through the admin UI should come at a later stage.

There is an important limitation, though. Encryption helps protect credentials in database dumps and backups, but it does not stop malicious code running inside the installation itself from reading them. We explain this in more detail in our article on where to store WordPress API keys. Until the solution matures, the recommendation stays the same: keeping these values in wp-config.php is still the safest option.

Stricter rules for Application Passwords

Application Passwords are the standard mechanism for letting integrations reach the REST API. They are also one of the ways many AI agents connect to sites, as we covered in our piece on the WordPress MCP server. The roadmap includes:

  • an email notification whenever an Application Password is created;
  • better detection of local installs, separating development from the HTTPS requirement;
  • blocking unsafe values for the role assigned by default to new users (default_role);
  • support for cookies using the SameSite attribute.

Of these, the email notification is likely to matter most in day-to-day administration. Creating an Application Password without the account owner knowing is a common technique for keeping access after a breach. With WordPress 7.2, that kind of activity should no longer happen without any signal to the user.

Changes to the editor and design tools

Beyond security, the roadmap is a set of incremental refinements:

  • Notes with suggestion mode. Editor Notes should offer something close to tracked changes in a word processor. A collaborator proposes an edit for someone else to accept or reject. The update should also bring emoji reactions and a shortcut in the block toolbar.
  • Form controls in Global Styles. Buttons, text inputs, selects and labels can be styled from the admin, with no custom CSS.
  • Two new blocks. A Description List block, based on the semantic dl, dt and dd tags, and the Table of Contents block, in development since 2022.
  • SVG icons in the admin. The admin bar and admin menu should replace dashicons with SVG icons.
  • A change in how scripts and styles load. Concatenation of these files in the admin goes away, replaced by prefetching.

Ipsum becomes the new default theme

After 16 years of themes with names starting with “Twenty”, WordPress is set to adopt Ipsum as its default theme. The proposal is a deliberately minimal blog theme that works as a blank canvas, with style variations and WCAG AA–compliant contrast. A version for testing is already available on GitHub.

Sites running their own themes should see no practical change. Still, it is worth making sure Ipsum does not get activated by accident on a fresh install or in a staging environment.

What is not expected in this release

Two absences stand out in the current plan.

Real-time collaborative editing. It was intentionally left off the roadmap for the third cycle in a row. According to the team, the architectural decisions still need more time.

AI built into core. AI features remain in the official AI plugin, with no guarantee of being merged into core. Work in progress includes abilities that can perform write operations, updates to the MCP specification and distribution through the Plugin Directory, embeddings for semantic search, and streaming responses. The React 19 upgrade is also unlikely to be completed in WordPress 7.2.

That ordering seems coherent to us. AI agents interact with sites through credentials and permissions. Before expanding what agents can do, WordPress is strengthening exactly those two points: how secrets are protected, and what an already authenticated session can do without a fresh confirmation.

How to prepare before the first beta

There is no need to wait for the final release to start assessing your site. A few simple checks, run with WP-CLI and the terminal, help identify where 7.2 might affect you:

# 1. Default role and whether registration is open
wp option get default_role
wp option get users_can_register

# 2. Existing Application Passwords for a user
wp user application-password list admin

# 3. Hardcoded dashicons in themes and plugins
grep -rn "dashicons-" wp-content/themes wp-content/plugins

# 4. Concatenation setting in wp-config.php
grep -n "CONCATENATE_SCRIPTS" wp-config.php

Here is how to read the results:

  1. Default role. If public registration is enabled and the default role is anything other than “Subscriber”, fix it right away. That setting is already a security problem in current versions.
  2. Application Passwords. Revoke any credential whose purpose nobody knows. For the rest, note which systems depend on them, because those integrations are the ones to test during the beta.
  3. Dashicons. Custom themes and plugins that rely on the admin’s .dashicons- classes may show visual issues once the icons are replaced with SVG.
  4. Concatenation. If the constant is set, the admin’s loading behavior may change. Test it in a staging environment.

It is also worth listing every place where your site stores API keys. As the Secrets API gets adopted, plugins should start moving their credentials to the new system, and knowing how your install is organized today will make that migration easier.

When to update

From the first beta onward, experiments belong in staging, never in production. As for the final release, some agencies recommend waiting until late January, since a launch in the second week of December collides with holidays and reduced teams.

That caution is reasonable. For most businesses, the safest path is to validate the version in staging, wait for at least the first maintenance release, and only then install WordPress 7.2 in production. This does not apply to security fixes for the versions you run today, which should be installed as soon as they are available.

Final thoughts

WordPress 7.2 was not planned as a visually striking update. Its role is structural: better limits on what a session can do, stronger protection for credentials, and a notice to the account owner whenever a new form of access is created. For companies that already use AI agents, or plan to, that protective layer is essential before expanding what automation can do.

To see where your site stands before the beta arrives, Amicatek offers a WordPress assessment covering updates, credentials, integrations and performance. If you would rather hand off the testing and the upgrade itself, take a look at our WordPress maintenance service.

Sources