# WordPress 7.2 Beta 1 adds a Secrets API so plugins can stop storing API keys as plaintext options WordPress 7.2's first beta includes a native encrypted credential store with explicit retrieval, rotation and provider hooks. It could replace scattered plaintext wp_options patterns for plugins, but adoption is opt-in, key management remains critical and it cannot protect secrets from code already running inside WordPress. WordPress 7.2 Beta 1 landed October 20 with wp_set_secret and wp_get_secret, encrypted storage, current/previous versions and pluggable back ends. Existing plugin credentials do not migrate automatically; the final release is scheduled for December 8. - Status: Active - Published: 2026-10-21T19:16:57+13:00 - Updated: 2026-10-21T19:16:57+13:00 - Categories: Web Development, PHP, WordPress - Tags: API security, security, WordPress 7.2 - Canonical HTML: https://beyondthe.news/dossiers/wordpress-7-2-beta-secrets-api-encrypted-plugin-credentials ## What changed WordPress released 7.2 Beta 1 on October 20, 2026. Among the developer additions is a new first-party Secrets API for plugins and integrations to store credentials such as SMTP, payment and AI provider keys without putting their values in plaintext options. The API provides wp_set_secret(), wp_get_secret(), wp_delete_secret() and a deliberate import helper, with WP_Secret objects that require explicit reveal() access. Its design uses encryption at rest, configurable keyring/storage providers and current/previous value slots to support credential rotation. The feature is in beta and the final 7.2 release is scheduled for December 8. ## Why it matters WordPress plugins commonly persist tokens and API keys in wp_options, which is routinely copied into backups, staging sites and support exports. A standard encrypted credential interface offers a consistent hardening path, with a central API that plugin authors and hosts can audit. However, encrypted-at-rest storage reduces database-leak exposure; it is not a sandbox between plugins and cannot prevent code execution inside WordPress from retrieving usable secrets. ## What developers can use The proposed API includes wp_set_secret(name,value), wp_get_secret(name,version), wp_delete_secret(name) and wp_import_option_as_secret(option,name). Retrieval distinguishes a missing secret (null) from a key or decryption failure (WP_Error) and returns an object rather than plaintext by default. A plugin should explicitly handle all three states and call reveal() only when passing the credential to its intended service. ## Encryption and rotation boundaries The core design encrypts secrets using a key hierarchy with a dedicated key configuration preferred and a salts-derived fallback. Current and previous secret versions support rotation without an unlimited history. If the wrapping key is lost or salts change without a migration plan, stored credentials can become unreadable; recovery may require re-entering and rotating credentials. Encryption does not stop malicious PHP code executing inside WordPress from calling the same retrieval API. ## Hosting providers raised a real integration issue During design review, engineers from managed WordPress hosts questioned whether a write-capable local encryption model fits read-only external secret stores backed by services such as AWS Secrets Manager. The proposal's author subsequently discussed pluggable provider implementations. Builders using a host-managed secrets system should verify the beta's actual provider behaviour rather than assuming every existing keyring or read-only store is interchangeable. ## Migration is not automatic WordPress cannot safely infer which arbitrary options contain credentials. Plugin authors must deliberately import known values and rotate them, because encrypting a previously exposed key does not remove plaintext copies from old database dumps or backups. The beta is for testing on staging or local environments, not production deployment; API signatures and behaviour should be checked again before the December stable release. ## Key details - WordPress 7.2 Beta 1 announced October 20, 2026; final planned December 8. - First-party wp_set_secret/wp_get_secret and related APIs target plugin credentials. - Encrypted-at-rest default with configurable storage and key providers. - Current/previous versions enable credential rotation; key-loss can make secrets unreadable. - No automatic migration of legacy wp_options credentials. - No protection against arbitrary code execution inside the WordPress process. ## Builder takeaways - Test the beta API with non-production credentials and a staging copy of your plugin. - Handle missing, inaccessible and present secret states separately. - Plan explicit option migration plus rotation; don't assume encryption cleans old backups. - Validate salt/key changes, staging clones and host-managed read-only secret-store behaviour before production adoption. ## What to watch - Changes to Secrets API signatures and provider semantics before the December 8 stable release. - Host and plugin ecosystem adoption, especially payment and email integrations. - Security review findings around key management, rotation and multisite. ## Uncertainties - The 7.2 API is beta and may change before the final release. - Managed-host integration patterns and independent security assessment remain incomplete. - The core feature alone does not migrate or rotate any existing plugin credentials. ## Sources - [WordPress 7.2 Beta 1 is ready for download and testing](https://wordpress.org/news/2026/10/wordpress-7-2-beta-1-is-ready-for-download-and-testing/) — WordPress.org · primary release announcement · 2026-10-20T00:00:00+13:00. Beta availability, final release date, Secrets API scope and testing guidance. - [Proposal: A Secrets API for WordPress 7.2](https://make.wordpress.org/core/2026/08/25/proposal-a-secrets-api-for-wordpress-7-2/) — Make WordPress Core · primary design and maintainer discussion · 2026-08-25T00:00:00+12:00. API methods, threat model, rotation and migration semantics, host-provider objections and maintainer responses. - [WordPress Secrets API follow-up changeset 64344](https://core.trac.wordpress.org/changeset/64344) — WordPress Core Trac · primary code change · 2026-10-14T00:00:00+13:00. Core implementation follow-up to 64337 confirms code landed before Beta 1; full ticket access was limited. - [WordPress is bringing a Secrets API in December. Should we use it?](https://www.reddit.com/r/ProWordPress/comments/1x6hmlf/wordpress_is_bringing_a_secrets_api_in_december/) — r/ProWordPress · developer community testing · 2026-10-15T00:00:00+13:00. Independent user report of key migration/rotation footgun; anecdotal, not formal security audit.