Is WordPress 7.2 Finally Ending Plain-Text API Keys in Plugins?

WordPress 7.2 Beta 1 adds a core Secrets API that encrypts plugin API keys at rest with libsodium. Here's how it works, what it won't stop, and what to change.

TheTechLane cover asking "Is WordPress 7.2 Ending Plain-Text API Keys?" beside artwork of an api_key row being locked inside a layered key vault

For years, almost every WordPress plugin that talks to Stripe, an email service or an AI provider has saved its API key as plain text in the database. WordPress 7.2 Beta 1, released on October 20, adds a core Secrets API that encrypts those credentials at rest, and plugin developers can start testing it now.

Here's what you need to know:

  • WordPress 7.2 ships a new Secrets API: wp_set_secret() stores a credential encrypted, and wp_get_secret() reads it back.

  • Encryption is always on, using libsodium's XChaCha20-Poly1305, with a layered key chain whose first key lives in wp-config.php, not the database.

  • It protects against stolen database dumps, backups and SQL injection reads, but not against malicious code already running on your site.

  • Hosts can swap in their own vault or key service through a wp-content/secrets.php drop-in.

  • WordPress 7.2 is scheduled for December 8, 2026, so this is still beta code.

UML sequence diagram of how wp_set_secret and wp_get_secret encrypt and decrypt a WordPress secret

How a secret is stored and read back in WordPress 7.2.

What Happened

The WordPress 7.2 Beta 1 announcement lists a new Secrets API that gives developers "a standardized, secure way to store sensitive credentials such as API keys and authentication tokens," with encryption at rest, credential rotation and customizable storage providers.

It started as a proposal by core contributor Eric Mann in August. His diagnosis was blunt: every plugin that needs an API key "writes it to the options table in plaintext," so credentials end up "in every database dump, every backup, every staging clone." He added that AI integrations raised the stakes, since "a leaked model-provider key is a metered spend liability."

The code landed in trunk on October 13, according to a hands-on test by W4dev. Here's the core of it:

wp_set_secret( 'my-plugin/api-key', $key );

$secret = wp_get_secret( 'my-plugin/api-key' );
$key    = $secret->reveal();

Under the hood, each secret gets its own random data key. That key is wrapped by a master key, which comes from a root key, which is itself wrapped by a site key taken from a WP_SECRETS_KEY constant, or derived from LOGGED_IN_KEY and LOGGED_IN_SALT if you haven't set one. W4dev's test shows the stored row holds only ciphertext and isn't autoloaded.

Atto WP's read of the Beta 1 source found more: a WP_Secret object that prints as a placeholder in logs and var_dump(), current and previous version slots for rotation, a wp_secret_changed audit hook that never passes values, and three Site Health checks.

Why It Matters

WordPress powers a huge slice of the web, and its plugins hold keys for payments, email, CRMs and now AI models. Today, a leaked backup or a SQL injection bug can expose all of them at once. With the Secrets API, a stolen database gives an attacker ciphertext unless they also get wp-config.php.

It also ends a lot of home-made crypto. Mann's proposal notes that Site Kit, WooCommerce gateways and SMTP plugins each invented their own scheme, "each one a separate audit surface." One reviewed implementation in core is easier to trust and easier to audit.

But it's not a vault. The proposal is clear that code execution inside WordPress is out of scope: any plugin can call wp_get_secret() with another plugin's name, and namespacing gives "no claim of per-plugin isolation." Hosts like Pantheon and Altis pushed back in the comments, raising concerns about how WordPress should work with their own external secret stores. The shipped design lets hosts plug those stores in through the drop-in.

What It Means for Developers

If your plugin stores any credential, start planning now:

  • Feature-detect. Wrap new code in function_exists( 'wp_set_secret' ) and keep your old storage path for sites on WordPress 7.1 and earlier.

  • Handle three results. wp_get_secret() returns a WP_Secret, null when nothing is stored, or a WP_Error when a secret exists but can't be decrypted. Don't treat an error as "not configured."

  • Add your own checks. The functions run no capability check, so your settings screen still needs current_user_can() and a nonce.

  • Migrate, then rotate. wp_import_option_as_secret() copies an old option into a secret and flags it for rotation, because the old plain-text copy is already sitting in past backups.

  • Set a dedicated key early. Add WP_SECRETS_KEY (32 random bytes, base64) to wp-config.php before any secrets are stored. Adding it later means existing secrets won't unwrap without the previous-key constant.

  • Reveal late. Call ->reveal() right before you use the key, and never log the result.

UML class diagram of the WordPress Secrets API: WP_Secret, Provider, Keyring, Store and the secrets.php drop-in

The interfaces hosts can swap out through the secrets.php drop-in.

Running WordPress also means running PHP, and this month that matters twice. If you haven't yet, read our guide to PHP2Shell, the critical PHP RCE flaws you need to patch now. Laravel teams should also check the TokenGuard login bypass.

What's Next

Beta 2 is due on October 27, with release candidates from November 17 and the final release on December 8, per the WordPress 7.2 release schedule. Function names can still change before then, so test against each beta.

There's no admin screen for secrets yet. Mann's proposal deferred the UI to WordPress 7.3, so site owners won't see a "Secrets" page this year. The real test will be adoption: the API only helps once big plugins move their keys into it.

FAQ

Does the WordPress Secrets API protect against hacked plugins?

No. Any code running inside WordPress can read any secret. It protects data at rest, such as database dumps, backups and SQL injection reads.

Do I need to configure anything to use it?

No. It works out of the box using keys derived from your salts, but a dedicated WP_SECRETS_KEY in wp-config.php is the recommended setup.

When can I use the Secrets API on production sites?

When WordPress 7.2 ships, scheduled for December 8, 2026. Until then, test it on staging only.

Sources

Follow TheTechLane

Keep learning AI, development, and modern developer technologies with TheTechLane. Learn • Build • Share Follow @thetechlanehq for more developer guides, tutorials, and practical technology content.