Encryption at rest for the WordPress Connectors API is the security improvement a lot of people assumed would arrive with WordPress 7.0, and did not. When 7.0 shipped in May 2026 with the new Connectors API, credentials entered through the admin screen still landed in the wp_options table as plaintext. The work to change that got pushed to a follow-up core ticket, #64789, and that is where connectors api encryption at rest sits today: an open proposal rather than shipped code. This is a status check on where the ticket stands as of late July 2026, what the core team has actually agreed on, what is blocking progress, and what builders should do in the meantime.
We covered the underlying storage weakness in depth in Securing the WordPress 7.0 Connectors API. This piece is narrower: it tracks the one core ticket that would fix the problem at the platform level, and it is deliberately honest about how far along that work actually is.
What shipped in 7.0, and what did not
The Connectors API is a centralized credential registry. Instead of every AI-related plugin shipping its own settings screen and its own key storage, plugins register a connector type with core and read credentials from a shared surface at Settings then Connectors. The feature was introduced in the Make WordPress Core announcement in March 2026 and landed in the 7.0 release. For the broader release context, see our WordPress 7.0 overview.
What did not ship is any encryption of the stored values. In the 7.0 release candidates, connector credentials were ordinary REST-writable settings sitting behind the broad manage_options capability gate. They were not encrypted. The admin interface masks the characters with bullet points, and a filter on the option redacts the value in REST responses and on the Connectors page, but the raw key is still visible in plaintext to anyone who opens the hidden options.php screen in wp-admin. Masking is a UI affordance. It is not encryption.
Encryption was on the table during the 7.0 cycle and was explicitly deferred. According to the ticket discussion, the trunk patch was pulled before RC3 and the work was moved to a future release. The community shipped 7.0 with the baseline of no encryption and opened #64789 to explore the design properly rather than rush it.
Why this matters for security and compliance
The reason a plaintext credential in wp_options is worse under the Connectors API than it was before is centralization. Pre-Connectors, a database leak exposed whichever plugins happened to store their own keys. Post-Connectors, one query against the options table yields every connected external service at once. Database backups, production-to-staging pulls, and any SQL injection vulnerability in any installed plugin all become single-query credential dumps.
For teams with a compliance obligation, this is not an abstract concern. Storing third-party API credentials in cleartext inside a routinely backed-up and copied database is difficult to reconcile with the data-protection posture most frameworks expect. If any of those credentials can reach personal data, the exposure question lands squarely in scope of regimes like the ones we outlined in what GDPR actually requires. Encryption at rest is the control auditors ask about by name, which is a large part of why the ticket exists.
What ticket #64789 actually proposes
Here is where honesty matters more than tidiness. Ticket #64789 is titled "Security audit for API key storage on the Connectors screen." It is not a finished specification for a specific encryption scheme. It is the tracking ticket where the core team agreed on the baseline (no encryption in 7.0) and where the design conversation for a future implementation is happening.
The direction under discussion is support for two-way encryption of sensitive option values, most likely as an opt-in mechanism that integrates with external key management rather than a scheme WordPress core owns end to end. What the ticket does not yet contain, as of this writing, is a merged patch, a committed target version, or a settled answer to the hard problem below. Anyone quoting you a specific release for connectors api encryption at rest is guessing.
The key-management problem that is blocking it
The blocker is not enthusiasm. It is key management, and it is a genuinely hard problem inside WordPress’s constraints.
There is currently no clean way to store a reversibly encrypted value in WordPress without tying it to a secret. The two candidate anchors are the authentication keys and salts already defined in wp-config.php, or a brand-new dedicated secret. Both have sharp edges. Tying credential encryption to the existing wp-config.php keys risks silent data loss, because those keys are routinely rotated, and they change whenever a site is migrated, exported, or copied to another environment. Rotate the anchor and every encrypted credential becomes undecryptable.
The minimum viable version of the feature therefore requires a new, explicitly documented encryption constant that site operators are told never to rotate, plus a migration story for existing plaintext values and a recovery story for the day someone loses the key. That is a lot of surface area to get right, and getting it wrong means locking site owners out of their own credentials. This is exactly the kind of design that should not be rushed into a release candidate, which is why it was not.
Where it stands, and the honest timeline
As of late July 2026: the ticket is open, the baseline decision (plaintext in 7.0) is made, the direction (opt-in two-way encryption anchored to a non-rotating secret) is broadly favored, and no implementation has been committed to a version. Given the unresolved key-management design and the usual WordPress core cadence, it would be optimistic to expect this in 7.1. A later point in the 7.x line is more plausible, and even that assumes the constant-and-migration design converges. Treat any version number, including the ones in this paragraph, as a directional guess rather than a commitment.
What builders should do meanwhile
The practical guidance has not changed since 7.0 shipped, because the platform-level fix is not close.
Keep credentials out of the database entirely by using the higher tiers of the credential waterfall. The Connectors API resolves in a strict order: environment variables first, PHP constants in wp-config.php second, database options last. Setting an env var short-circuits the plaintext path completely, so the value never gets read from the database even if a record exists there. Our environment-variable migration checklist walks through the inventory and cutover, and on Pantheon specifically, platform Secrets feed those env vars without putting anything in the repo or the database.
Three more habits carry the load until the ticket lands:
- Audit your
wp_optionstable forconnectors_%_api_keyrecords. Anything you find is a plaintext credential. Once the env-var path is verified, delete the obsolete rows. - Encrypt database backups at rest, and filter connector option records out of production-to-staging pulls so keys do not sprawl across environments.
- If you genuinely need database-level encryption today, third-party plugins such as Lockr offer key-vault integrations, with the tradeoff that you are now depending on and paying for an external service rather than a core primitive.
Encryption at rest for the Connectors API is coming to WordPress core eventually. It is not here now, it is not scheduled, and building as though it were shipped is the mistake to avoid. Configure the waterfall, keep the secrets out of the database, and watch the ticket.
Frequently Asked Questions
Did WordPress 7.0 encrypt Connectors API credentials?
No. When WordPress 7.0 shipped in May 2026, credentials entered through the Connectors screen were stored as plaintext in the wp_options table. The admin UI masks the characters with bullet points and a filter redacts the value in REST responses, but that is display masking, not encryption. The raw key remains readable in plaintext on the hidden options.php screen in wp-admin.
What is WordPress core ticket #64789?
It is the open Trac ticket titled “Security audit for API key storage on the Connectors screen.” It is where the core team recorded the decision to ship 7.0 without encryption and where the design discussion for future encryption at rest is happening. It is a tracking and exploration ticket, not a merged, finished feature.
When will encryption at rest ship for the Connectors API?
There is no committed release as of late July 2026. The encryption work was deferred out of the 7.0 cycle to a future release, and the key-management design that would unblock it is still unresolved. Any specific version number, including 7.1, is a guess rather than a commitment.
Why is encryption at rest taking so long to implement?
The blocker is key management. WordPress has no clean way to store a reversibly encrypted value without tying it to a secret, and the obvious anchors (the wp-config.php authentication keys) are routinely rotated and change on migration or export, which would render encrypted credentials undecryptable. A safe implementation needs a new, never-rotated encryption constant plus migration and recovery paths, which is deliberately not being rushed.
How do I protect Connectors credentials right now?
Use the credential waterfall. Set the credential as an environment variable (best) or a PHP constant in wp-config.php (second best). Both take precedence over the database, so the plaintext option is never read. On managed hosts, platform secrets features feed those env vars. Then audit and delete any existing connectors_*_api_key rows in wp_options.
Does the plaintext storage create a compliance problem?
It can. Storing third-party API keys in cleartext inside a database that gets backed up and copied to staging environments is hard to square with the data-protection controls most frameworks expect, especially where those credentials can reach personal data. Encryption at rest is a control auditors ask about directly, which is one reason the ticket exists. Moving secrets to env vars is the practical mitigation until core support lands.
Are there plugins that encrypt the credentials today?
Yes. Third-party key-vault plugins such as Lockr integrate external secret storage and can encrypt sensitive values now. The tradeoff is a dependency on, and usually a subscription to, an external service rather than a WordPress core primitive. For most sites, moving credentials to environment variables achieves the security goal without adding a plugin.
Where can I follow the ticket myself?
The ticket lives at core.trac.wordpress.org/ticket/64789. The Connectors API itself was introduced in the Make WordPress Core announcement in March 2026. Both are public, and the ticket page carries the full discussion history and any linked patches as the design progresses.
