WordPress 7.2, previsto para el 8 de diciembre de 2026, incorpora una Secrets API: una forma oficial de guardar claves de API, secretos de OAuth y credenciales similares cifradas en la base de datos. La nota técnica que el equipo del core publicó el 11 de noviembre, firmada por Eric Mann, trae un cambio respecto a las betas: la API ahora depende de una constante nueva, WP_SECRETS_KEY, en wp-config.php. Las instalaciones nuevas reciben esa clave automáticamente. Los sitios que ya existen, no.
Qué llega en la 7.2
Hoy la mayoría de los plugins guarda las claves de servicios externos (pagos, correo transaccional, CRM, modelos de IA) como una opción común, en texto plano en la tabla wp_options. Quien tenga una copia de la base de datos tiene las claves.
Con la 7.2, los plugins pueden llamar a wp_set_secret() y wp_get_secret(). El valor se cifra con libsodium (XChaCha20-Poly1305) y va a la misma tabla de opciones, y la versión anterior se conserva para poder rotar una clave sin romper la integración. El objeto devuelto no aparece en logs, var_dump ni JSON; el valor solo sale cuando el código llama a reveal(). También existe wp_import_option_as_secret(), que copia una opción existente al almacén y marca el secreto como pendiente de rotación.
La nota deja dos límites explícitos. El prefijo en el nombre del secreto (plugin/nombre) evita que un plugin sobrescriba el de otro, pero no es control de acceso: cualquier código que se ejecute en el sitio puede leer cualquier secreto. Y las funciones no comprueban permisos del usuario, porque tienen que funcionar desde cron y REST; esa comprobación sigue siendo responsabilidad del plugin.
La clave nueva y qué pasa sin ella
El cifrado depende de WP_SECRETS_KEY. En las betas, cuando la constante no existía, el core derivaba una clave de LOGGED_IN_KEY y LOGGED_IN_SALT. Ese atajo se eliminó. Sin la constante, la API no guarda nada: toda escritura y toda lectura de un secreto devuelven el error secret_key_unavailable. Un valor vacío, el texto de ejemplo de wp-config-sample.php o una copia de una de las salts tampoco sirven.
En los sitios existentes, Site Health muestra un aviso y genera la línea define() para pegar en wp-config.php, debajo de las salts. Los hostings y las herramientas que escriben ese archivo deben incluir la constante; según la nota, el wp config create de WP-CLI "se está actualizando" para hacerlo.
La nota también advierte que esta clave no se trata como las salts. Cambiar las salts cierra la sesión de los usuarios. Cambiar o perder WP_SECRETS_KEY deja ilegibles todos los secretos guardados hasta que vuelva el valor anterior. En la práctica, wp-config.php deja de ser un archivo que se recrea desde cero en una migración y pasa a formar parte de la copia de seguridad, junto con la base de datos. Un volcado restaurado sin la clave original trae los secretos, pero no abre ninguno.
Quién tiene que actuar
Quien mantiene sitios WordPress fuera de un hosting gestionado tiene que decidir dónde vivirá esa clave y quién guarda una copia. Si wp-config.php lo genera un pipeline, una plantilla de servidor o una imagen de contenedor, la constante tiene que entrar en ese proceso, no pegarse a mano en producción. Si el sitio lo entregó una agencia y hoy nadie sabe bien quién toca el servidor, este es uno de los primeros datos que se pierden; escribí sobre ese vacío en ¿Quién cuida el sistema cuando termina el proyecto?.
Los hostings que quieran guardar la clave en un KMS o HSM, o enviar los secretos a un gestor externo, lo hacen mediante un drop-in wp-content/secrets.php. Aquí hay un cambio incompatible para quien probó las betas: los puntos de extensión pasaron a ser clases abstractas, así que un drop-in que todavía use implements en lugar de extends provoca un error fatal en todas las peticiones, según la nota. Ese ajuste tiene que llegar a producción junto con la 7.2.
Quien probó las betas y ya guardó secretos sin la constante tiene que migrarlos antes de tocar las salts, porque la clave antigua se deriva de ellas. La nota describe tres pasos: definir la clave nueva y WP_SECRETS_KEY_PREVIOUS, ejecutar la rotación de la clave raíz con wp eval y eliminar la línea temporal.
Para el resto, no hay un plazo estricto el 8 de diciembre. Un sitio sin la constante sigue funcionando; solo la Secrets API queda no disponible. El plazo real llega cuando algún plugin del sitio empiece a depender de ella, y la nota no dice cómo se comportará cada plugin en ese caso. Mi lectura: conviene añadir la clave y guardar una copia fuera del servidor antes de actualizar, porque hacerlo después de que un plugin ya haya guardado secretos tiene más riesgo que hacerlo ahora.
Lo que todavía no está claro
La nota no indica cuándo sale en WP-CLI la actualización de wp config create, ni si los grandes hostings gestionados añadirán la constante por su cuenta o dejarán la tarea al cliente. Tampoco hay señales de qué plugins populares adoptarán la API en el lanzamiento, ni de cómo tratarán un sitio sin la clave: volver a la opción en texto plano o rechazar la configuración. La RC1 de la 7.2 está prevista para el 17 de noviembre, y los detalles aún pueden cambiar hasta entonces.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
