O WordPress 7.2, marcado para 8 de dezembro de 2026, ganha uma Secrets API: um jeito oficial de guardar chaves de API, segredos de OAuth e credenciais parecidas de forma criptografada no banco. A nota técnica publicada pela equipe do core em 11 de novembro, assinada por Eric Mann, traz uma mudança em relação aos betas: a API agora depende de uma constante nova, WP_SECRETS_KEY, no wp-config.php. Instalações novas recebem essa chave automaticamente. Sites que já existem, não.
O que entra no 7.2
Hoje a maior parte dos plugins grava chaves de serviços externos (pagamento, e-mail transacional, CRM, modelos de IA) como opção comum, em texto puro na tabela wp_options. Quem tem acesso a um dump do banco tem as chaves.
Com o 7.2, plugins podem chamar wp_set_secret() e wp_get_secret(). O valor vai criptografado com libsodium (XChaCha20-Poly1305) para a mesma tabela de opções, e a versão anterior fica guardada para permitir rotação sem derrubar a integração. O objeto devolvido não aparece em log, var_dump ou JSON; o valor só sai quando o código chama reveal(). Há também wp_import_option_as_secret(), que copia uma opção existente para o cofre e marca o segredo como pendente de rotação.
A nota deixa dois limites explícitos. O prefixo no nome do segredo (plugin/nome) evita que um plugin sobrescreva o de outro, mas não é controle de acesso: qualquer código rodando no site pode ler qualquer segredo. E as funções não checam permissão do usuário, porque precisam rodar em cron e REST; essa checagem continua sendo do plugin.
A chave nova e o que acontece sem ela
A criptografia depende de WP_SECRETS_KEY. Nos betas, quando a constante não existia, o core derivava uma chave de LOGGED_IN_KEY e LOGGED_IN_SALT. Esse atalho foi removido. Sem a constante, a API não grava nada: toda escrita e toda leitura de segredo retornam o erro secret_key_unavailable. Valor vazio, o texto de exemplo do wp-config-sample.php ou uma cópia de um dos salts também não valem.
Para sites existentes, o Site Health passa a mostrar um aviso e gera a linha define() para colar no wp-config.php, abaixo dos salts. Hospedagens e ferramentas que escrevem esse arquivo devem incluir a constante; segundo a nota, o wp config create do WP-CLI "está sendo atualizado" para isso.
A nota também avisa para não tratar essa chave como os salts. Trocar os salts desloga os usuários. Trocar ou perder WP_SECRETS_KEY deixa todos os segredos guardados ilegíveis até que o valor antigo volte. Na prática, o wp-config.php deixa de ser um arquivo que se recria do zero numa migração e passa a ser parte do backup, junto com o banco. Um dump restaurado sem a chave original traz os segredos, mas não abre nenhum deles.
Quem precisa agir
Quem mantém sites WordPress fora de hospedagem gerenciada precisa decidir onde essa chave vai morar e quem tem cópia dela. Se o wp-config.php é gerado por pipeline, template de servidor ou imagem de container, a constante precisa entrar nesse processo, e não ser colada à mão em produção. Se o site foi entregue por uma agência e hoje ninguém sabe ao certo quem mexe no servidor, essa é uma das informações que se perdem primeiro; escrevi sobre esse vazio em Quem cuida do sistema depois que o projeto acaba?.
Hospedagens que querem guardar a chave num KMS ou HSM, ou mandar os segredos para um gerenciador externo, fazem isso por um drop-in wp-content/secrets.php. Aqui há uma quebra para quem testou os betas: as extensões viraram classes abstratas, então um drop-in que ainda usa implements em vez de extends causa erro fatal em todas as requisições, segundo a nota. Esse ajuste precisa ir para produção junto com o 7.2.
Quem testou os betas e já gravou segredos sem a constante precisa migrá-los antes de mexer nos salts, porque a chave antiga deriva deles. A nota descreve três passos: definir a chave nova e WP_SECRETS_KEY_PREVIOUS, rodar a rotação da chave raiz via wp eval e remover a linha temporária.
Para o resto, não há prazo duro em 8 de dezembro. Um site sem a constante continua funcionando; só a Secrets API fica indisponível. O prazo real chega quando algum plugin do site passar a depender dela, e a nota não diz como cada plugin vai se comportar nesse caso. Minha leitura: vale adicionar a chave e guardar uma cópia fora do servidor antes de atualizar, porque fazer isso depois de um plugin já ter gravado segredos é mais arriscado do que fazer agora.
O que ainda não está claro
A nota não informa quando a atualização do wp config create sai no WP-CLI, nem se grandes hospedagens gerenciadas vão incluir a constante sozinhas ou deixar a tarefa para o cliente. Também não há sinal de quais plugins populares vão adotar a API no lançamento, nem de como eles vão tratar um site sem a chave: cair de volta para a opção em texto puro ou recusar a configuração. O RC1 do 7.2 está previsto para 17 de novembro, e detalhes ainda podem mudar até lá.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
