As of 2026-11-13 UTC. Primary source: WordPress Hosting Team, “Call to test: WordPress 7.2’s Secrets API, upgrades and /random/ on your hosting platform by November 17”, published 2026-11-12.
What is happening
WordPress 7.2 is due to ship on December 8, 2026. On November 12, 2026, the WordPress Hosting Team, the Make WordPress group that works between web hosts and WordPress core, published a call asking hosts to test three changes in the release on their own platforms, not just on a single test site, before Release Candidate 1 (RC1) lands on November 17. RC1 is the string freeze: after it, a change needs core committers to sign off.
The first of the three changes is the WordPress 7.2 Secrets API, a new way to store credentials such as API keys. The call reports that both sites upgraded on the one managed platform tested had no WP_SECRETS_KEY, which leaves the WordPress 7.2 Secrets API off. Separately, on the Core team’s dev note announcing the WordPress 7.2 Secrets API, Ryan McCue asked for it to be backed out of core for 7.2. Eric Mann, who wrote the note, replied “I don’t think that’s warranted.” Matt Mullenweg then commented: “I agree with @rmccue here.” That comment does not say which point he agrees with.
What the WordPress 7.2 Secrets API actually does
The dev note says the Secrets API stores credentials, such as API keys and OAuth client secrets, encrypted, with one previous version kept for rotation. Secrets are encrypted with libsodium (XChaCha20-Poly1305) and stored in the options tables. Their keys are derived from a random root key, which is stored encrypted with WP_SECRETS_KEY from wp-config.php.
Without a usable WP_SECRETS_KEY, the dev note states, “the API stores nothing, and every write, and every read of a stored secret, returns a secret_key_unavailable error.” The dev note says new installs get a key because “the installer fills it in along with the salts,” and that “Existing sites need one added.” The Hosting Team post says only the browser installer writes a key; sites whose wp-config.php is written by other tooling, such as wp config create, one-click installers or provisioning scripts, get none. The dev note adds that wp config create is being updated to add one.
The dev note names functions for plugin authors, including wp_set_secret() and wp_get_secret(). It tells plugins to check wp_is_secrets_api_available() before moving an existing credential into the new storage. Some hosts provide secrets through a read-only provider, where values are managed in the host’s dashboard or CLI. On those sites wp_secrets_provider_is_writable() returns false and wp_set_secret() returns an error object.
Why the WordPress 7.2 Secrets API matters for your site right now
Core does not call the API yet, so the Hosting Team expects breakage only once plugins move credentials into it. Its post puts it this way: “Core doesn’t call the API yet, so this breaks sites only once plugins move credentials into it.” The dev note’s own example code says that when the API is unavailable, a plugin should “Keep the existing storage.”
On the platform tested, the post reports, “Both sites upgraded on the managed platform had no key.” It describes its results as coming from testing 7.2-beta4 and beta5 “on one managed platform and local test fleets.” The post does not say how other platforms behave, and it asks hosts to run the tests on their own stacks.
Eric Mann, who published the dev note, argues the case for the default. The principle under discussion is that secrets should be “provided to the application, not managed by it.” Mann agrees with it “for platforms that have an out-of-band channel,” but “Most WordPress sites don’t. Their credentials arrive through a plugin settings screen and sit in wp_options in plaintext, where they show up in every dump, backup, staging clone, and export.”
McCue had written that “there’s no additional fundamental security offered by secrets compared to the database if your database is already encrypted at rest (which any provider offering a HSM-backed secrets API is likely already doing).” Mann replied that encryption at rest “protects against someone walking off with the disk” but “does nothing about SQL injection, a leaked mysqldump, a misconfigured backup bucket, or a staging copy handed to a contractor.” Mann argues the default closes those exposure paths.
The pushback: Ryan McCue’s objection and the replies
On the same dev note, at 3:33 pm on November 12, 2026 (time zone not stated on the page), Ryan McCue wrote: “I am a strong -1 on this feature, and I think this should be backed out of core for 7.2 until the above is resolved.” He summarizes the problem as the WordPress 7.2 Secrets API “mixing together two separate things in this dangerous way”: “secrets provided by the platform, which should be managed externally and provided to the application (not managed by it),” and “secret data within the application, including passwords, API keys, 2FA keys, etc.”
McCue proposed “breaking this into two separate APIs, such as a wp_get_secret() read-only API, and a wp_get_encrypted_value()/wp_set_encrypted_value() read-and-write API.” He wrote that “Industry-wide best practice is that wherever possible, secrets should be stored separately to the rest of your data, in a way that exposes them as read-only to the running application,” and that the API “is likely to ossify in a way that will mean secret providers must support writes to be ecosystem-compatible.” As an example he cited “the AI plugin’s secrets bridge does not check if the provider supports writes, assuming it does, and discarding any errors silently.”
Mann replied that “The provider layer was built for your setup,” addressed to McCue, and that a host can hand the entire API to an external secret manager. He wrote that the feature plugin “has shipped AWS Secrets Manager and HashiCorp Vault providers for months.” On the bridge, separately, he wrote “Fair catch” and “I’ll open a PR to fix that.”
On the call for a back-out, Mann replied: “I don’t think that’s warranted.” His reason: “The August concerns are the ones the provider rework addressed, and the remaining issue is a bug in one consumer that’s getting fixed.” He added: “What would help most is a provider built against the contract for Altis’s real setup before RC. If it hits a wall, we fix it before release, and I’m happy to pair on it.”
Matt Mullenweg then commented at 2:21 am on November 13, 2026 (time zone not stated on the page): “I agree with @rmccue here.” A second comment at 2:23 am reads: “It’s also not a great time to be making ourselves a target for very sensitive things like that. We already have a lot that we handle privately with wp_users, drafts, etc.”
The other change: files left behind after an upgrade
The Hosting Team’s post flags another change, a more mechanical one. Upgrading from 7.1.4 through the Dashboard or auto-update leaves 10 files under wp-includes/ that 7.2 does not ship, because $_old_files has not been updated for 7.2 yet (Trac #66456). The post says core adds removed files to $_old_files at RC1, so the leftovers are expected during the betas, and it advises repeating the comparison on RC1.
WP-CLI’s wp core update removes them, so, in the post’s words, “checksum-based integrity monitoring flags one path and not the other.” The post, whose results come from beta4 and beta5 testing on one managed platform and local test fleets, adds that WP-CLI removes the files only when it can reach api.wordpress.org. Otherwise it skips them with a warning and still reports success.
The other change: a /random/ route that returns a 404 after an upgrade until a flush
WordPress 7.2 also adds a /random/ route, tracked as Trac #64498, that redirects a visitor to a random published post. The Hosting Team’s post cites Trac #64498 comment 73 for the behavior after an upgrade: the route returns a 404 until rewrite rules are flushed, which core does on the first wp-admin request, per site on multisite.
The post recommends running wp rewrite flush on every site after each upgrade, then purging the page cache, in that order. It also lists early performance notes, from reading the Beta 5 source and not measured: every request runs ORDER BY RAND() LIMIT 0, 1 over the eligible published posts, so the cost grows with post count.
What to ask your host about the WordPress 7.2 Secrets API
The Hosting Team’s checklist is written for hosts, and it turns into questions a site owner can put to a host before December 8. Do new and upgraded sites get a WP_SECRETS_KEY? Have the one-click installers and provisioning scripts been updated to write one? The checklist tells hosts to update those tools “to write a WP_SECRETS_KEY for every new site,” and the dev note says hosts and tools that write wp-config.php should add the key when they add the salts. Is the upgrade process, Dashboard or WP-CLI, being tested against the leftover-files issue and the /random/ flush?
In Test 1, which counts sites without a key, the post lists two WP-CLI commands: wp config has WP_SECRETS_KEY and wp eval 'var_dump( wp_is_secrets_api_available() );'. They are examples from the Hosting Team post, and the post says to run tests on staging or test sites, never on production. For Test 2 it says to generate a key with openssl rand -base64 32, and to trim values from a file or store, because “a trailing newline makes a different key.” The dev note places the key line in wp-config.php below the salts.
The dev note warns that once secrets are stored, changing or removing the key makes all of them unreadable until the old value comes back. The Hosting Team post says a different key switches the WordPress 7.2 Secrets API off on a clone, so old secrets can’t be read and new ones can’t be saved, and that migrations, rebuilds and restores should never regenerate the key. To change a key later, follow the dev note’s replacement steps rather than generating a new one. General advice, not from the sources: back up wp-config.php before editing it, keep a secure copy of the key outside the site, and never commit it to version control or share it.
For the release line before this one, see our earlier guide to what changes for your server, not just your editor.
What is still unconfirmed
The captured copy of the dev-note thread (capture time not recorded) shows no decision on the WordPress 7.2 Secrets API’s status in 7.2. Its last comments are Mullenweg’s at 2:21 am and 2:23 am on November 13, 2026 (time zone not stated on the page). Whether the Secrets API stays in 7.2 as planned is therefore not settled by the sources reviewed. Site owners and hosts who want a final answer should read the dev note thread again before RC1 on November 17, rather than treat the discussion described here as settled either way.
Featured image: “Awaiting servers” by bugeaters, licensed CC BY 2.0, via www.flickr.com.