WordPress 7.2 dejará de tratar las credenciales como un ajuste más
WordPress 7.2, la próxima versión del gestor de contenidos más utilizado de la web, incorporará una nueva Secrets API pensada para almacenar claves de API, tokens de acceso y otras credenciales cifradas en reposo. Hasta ahora, la práctica habitual en el ecosistema era guardar esos valores en texto plano dentro de la tabla de opciones de la base de datos, junto a ajustes tan inocuos como el título del sitio o el número de entradas por página. La nueva interfaz, que el equipo de core ha ido puliendo durante el ciclo de betas iniciado el 20 de octubre de 2026, ofrece a los desarrolladores de plugins y temas un lugar común y protegido para esa información sensible.
La función llega con un cambio de última hora que conviene conocer: desde la beta 5, publicada a mediados de noviembre, la API exige que el sitio defina la constante WP_SECRETS_KEY. Sin ella, la funcionalidad no está disponible. La versión candidata RC1 está prevista para el 17 de noviembre y el lanzamiento final para el 8 de diciembre de 2026, de modo que quienes mantienen plugins y quienes administran plataformas de alojamiento disponen de pocas semanas para adaptarse.
El motivo de fondo es sencillo de enunciar y difícil de resolver: una filtración de la base de datos o de una copia de seguridad de un sitio WordPress suele exponer, además del contenido, las llaves que ese sitio utiliza para hablar con pasarelas de pago, servicios de correo, proveedores de inteligencia artificial o plataformas de analítica. La Secrets API intenta que esa filtración, cuando ocurra, entregue datos cifrados en lugar de credenciales listas para usar.
Un problema histórico: secretos guardados como cualquier otra opción
Para entender la relevancia del cambio hay que mirar cómo funciona un plugin típico. Cuando un usuario instala una extensión que se conecta a un servicio externo, la pantalla de configuración le pide pegar una clave de API. El plugin recoge ese valor y lo guarda mediante la API de opciones, el mecanismo estándar que WordPress ofrece desde sus primeras versiones para persistir configuración. El resultado es una fila en la tabla de opciones con el nombre del ajuste y, al lado, la credencial completa, legible por cualquiera que tenga acceso a la base de datos.
Durante años, esta práctica se ha considerado aceptable por inercia. La API de opciones es cómoda, está documentada y funciona en cualquier alojamiento. El problema es que la base de datos de un sitio WordPress circula mucho más de lo que parece: se exporta para migraciones, se duplica en entornos de staging, se incluye en copias de seguridad que terminan en servicios de almacenamiento externos, se comparte con agencias o freelancers para depurar errores y, en ocasiones, queda expuesta por un volcado olvidado en un directorio público. Cada una de esas copias arrastra consigo las credenciales en texto plano.
A esto se suma la superficie de ataque propia del ecosistema. Las vulnerabilidades de inyección SQL en plugins, que permiten leer tablas arbitrarias, siguen apareciendo con regularidad. Basta una consulta bien construida contra la tabla de opciones para extraer de golpe todas las claves de terceros que el sitio tenga configuradas. Los episodios recientes de fallas críticas en sitios PHP recuerdan que la cadena de dependencias de una aplicación web es tan fuerte como su eslabón más débil, y que un fallo en apariencia acotado puede convertirse en una puerta hacia todo lo que el servidor guarda.
El impacto de una credencial filtrada rara vez se limita al sitio afectado. Una clave de un proveedor de correo transaccional permite enviar spam con la reputación del dominio legítimo; un token de una pasarela de pago puede abrir la puerta a consultas de transacciones o reembolsos; una clave de un proveedor de modelos de lenguaje puede traducirse en facturas inesperadas por consumo ajeno. La filtración se propaga hacia servicios que no tienen relación directa con la vulnerabilidad original, y la víctima a menudo tarda en darse cuenta.
Antecedentes: soluciones parciales y cada plugin por su cuenta
La comunidad no ha permanecido de brazos cruzados ante este problema, pero las respuestas han sido fragmentarias. Algunos desarrolladores de plugins optaron por cifrar las credenciales por su cuenta, a menudo derivando la clave de las constantes de salts definidas en el archivo de configuración. Otros recomendaban a sus usuarios definir las claves como constantes en wp-config.php, fuera de la base de datos, lo que reduce la exposición en copias de seguridad de la base de datos pero complica la experiencia de configuración para usuarios no técnicos. Y una parte significativa del ecosistema, simplemente, siguió guardando los valores tal cual.
Cada una de estas aproximaciones tenía sus debilidades. El cifrado artesanal, implementado plugin por plugin, multiplicaba el riesgo de errores criptográficos: algoritmos obsoletos, modos de operación inadecuados, vectores de inicialización reutilizados o claves almacenadas junto a los datos que supuestamente protegían. Las constantes en el archivo de configuración resolvían una parte del problema, pero no ofrecían ninguna interfaz unificada y obligaban a editar archivos del servidor, algo inviable en muchos alojamientos gestionados. Y la ausencia de un estándar significaba que un mismo sitio podía tener cinco plugins con cinco estrategias distintas, ninguna auditada en conjunto.
El núcleo de WordPress, por su parte, ya contaba con las piezas criptográficas necesarias. Desde hace varias versiones incluye una capa de compatibilidad con libsodium, la biblioteca criptográfica moderna que PHP incorpora de forma nativa y que el proyecto utiliza, entre otras cosas, para verificar firmas. Faltaba el paso de convertir esa base en una interfaz pública, coherente y pensada para que cualquier desarrollador pudiera guardar un secreto sin tener que convertirse en experto en criptografía.
Esa es precisamente la apuesta de la Secrets API: mover la responsabilidad del cifrado desde cada plugin hacia el núcleo, de manera que el cifrado de credenciales en WordPress deje de depender de la buena voluntad y el conocimiento de cada autor.
Qué es la Secrets API y cómo se organiza
La nueva interfaz se presenta como un sistema dedicado al almacenamiento de secretos, separado conceptualmente de la API de opciones. Su propósito es que los plugins y temas puedan guardar, leer, actualizar y eliminar credenciales a través de funciones específicas, sabiendo que el núcleo se encarga de cifrarlas antes de escribirlas y de descifrarlas cuando se necesitan.
Según los análisis publicados sobre la beta, el código vive en el archivo wp-includes/secrets.php, dentro del directorio de componentes internos del núcleo. Esa ubicación indica que no se trata de un plugin experimental ni de una funcionalidad opcional que deba activarse, sino de una pieza integrada en la base del sistema, disponible para cualquier extensión que quiera utilizarla, siempre que se cumplan los requisitos de configuración que el ciclo de betas ha ido endureciendo.
Las características principales que describen las notas de desarrollo son tres. En primer lugar, el cifrado en reposo: los secretos se almacenan cifrados, de modo que quien obtenga una copia de la base de datos no puede leerlos sin la clave correspondiente. En segundo lugar, la conservación de una versión previa de cada secreto, pensada para facilitar la rotación de credenciales sin cortes de servicio. En tercer lugar, la posibilidad de que los proveedores de alojamiento reemplacen el almacenamiento por defecto con su propio backend mediante un archivo drop-in llamado secrets.php.
Esa combinación responde a necesidades distintas. El cifrado protege frente a filtraciones; la versión previa reduce el riesgo operativo de cambiar una clave; y el drop-in abre la puerta a integraciones con infraestructuras de seguridad más robustas que la propia base de datos de WordPress.
Cifrado con libsodium y rotación de secretos
Desde el punto de vista técnico, la API recurre a libsodium y, de acuerdo con el análisis de la beta, utiliza el esquema XChaCha20-Poly1305. Se trata de un cifrado autenticado: además de ocultar el contenido, garantiza que el texto cifrado no ha sido manipulado. Si alguien modifica el valor almacenado en la base de datos, el descifrado falla en lugar de devolver datos corruptos o alterados de forma maliciosa.
La elección de XChaCha20-Poly1305 tiene sentido en un entorno como WordPress. Esta variante utiliza nonces de gran tamaño, lo que permite generarlos de forma aleatoria con un riesgo de colisión despreciable, sin necesidad de llevar contadores ni de coordinar estados entre procesos. En un sistema donde múltiples peticiones PHP pueden escribir en paralelo y donde no existe un servicio central que lleve la cuenta de los nonces usados, esa propiedad elimina una de las trampas clásicas de la criptografía aplicada. Además, ChaCha20 ofrece un buen rendimiento en software incluso en servidores sin aceleración por hardware para AES, algo relevante en un ecosistema que abarca desde grandes plataformas hasta alojamientos compartidos modestos.
El segundo pilar es la rotación. La API admite la rotación de claves y, además, conserva una versión previa de cada secreto. En la práctica, esto significa que cuando un administrador sustituye una credencial, por ejemplo porque el proveedor externo ha emitido una nueva o porque se sospecha de una exposición, el valor anterior no desaparece de inmediato. Esa ventana resulta útil en escenarios donde la nueva clave tarda en propagarse o donde conviene verificar que funciona antes de descartar la antigua. La rotación de claves de API es una de las prácticas que más se recomiendan en seguridad y una de las que menos se aplican, precisamente porque cambiar una credencial suele implicar riesgo de interrupciones.
Facilitar ese proceso desde el núcleo es una forma de empujar al ecosistema hacia hábitos más sanos. Las buenas prácticas para gestionar claves de API insisten en limitar permisos, renovar credenciales con regularidad y almacenarlas fuera del código y de lugares legibles; la Secrets API cubre parte de ese recorrido dentro de la propia plataforma.
El giro de la beta 5: WP_SECRETS_KEY pasa a ser obligatoria
El cambio más importante del ciclo de desarrollo llegó con la beta 5. A partir de esa versión, la API exige que el sitio defina la constante WP_SECRETS_KEY. Si la constante no existe, la Secrets API no está disponible, y las llamadas que necesitan la clave de cifrado devuelven un error identificado como secret_key_unavailable.
Para entender por qué se tomó esta decisión hay que mirar el diseño anterior. En las primeras betas, la clave de cifrado se derivaba de las salts de inicio de sesión, las cadenas aleatorias que WordPress define en su archivo de configuración y que utiliza para firmar cookies de autenticación. A primera vista parecía una solución elegante: todos los sitios tienen esas salts, por lo que la API funcionaba sin configuración adicional.
El problema es que esas salts tienen una función distinta y un ciclo de vida propio. Rotarlas es una práctica recomendada cuando se sospecha que una sesión ha sido comprometida, porque invalida todas las cookies activas y obliga a los usuarios a volver a iniciar sesión. Con el diseño original, esa medida de seguridad tenía un efecto secundario grave: al cambiar las salts cambiaba también la clave derivada, y todos los secretos guardados quedaban inaccesibles. Un administrador que hacía lo correcto ante un incidente podía terminar rompiendo todas las integraciones de su sitio.
Separar la clave de cifrado de secretos en una constante propia resuelve ese acoplamiento. Cada material criptográfico pasa a tener un propósito único, que es una regla básica de diseño en seguridad: las salts protegen sesiones y la constante WP_SECRETS_KEY protege secretos, y rotar una no afecta a la otra. A cambio, la configuración deja de ser automática y exige una acción explícita por parte de quien administra el sitio o del proveedor de alojamiento.
Hay un punto en el que conviene ser prudente. La información disponible sobre qué ocurre con los secretos que se guardaron durante las betas anteriores, cuando la clave se derivaba de las salts y no existía la constante, resulta contradictoria. Las fuentes no coinciden en si esos valores pueden recuperarse, migrarse o si deben volver a introducirse. Quienes hayan probado la API en betas tempranas deberían consultar las notas oficiales del lanzamiento antes de dar por hecho cualquier comportamiento, y en entornos de prueba lo más sensato es contar con tener que volver a guardar las credenciales.
El papel de los hostings y el drop-in secrets.php
WordPress utiliza desde hace mucho tiempo el concepto de drop-in: archivos con nombres específicos que, colocados en el directorio de contenido, sustituyen comportamientos del núcleo. Es el mecanismo con el que se reemplaza la caché de objetos o la capa de base de datos. La Secrets API se suma a esa tradición con un drop-in llamado secrets.php, que permite a los proveedores de alojamiento sustituir el almacenamiento por defecto por su propio backend.
Las implicaciones son considerables. Un proveedor de alojamiento gestionado puede conectar la API a un servicio de gestión de secretos dedicado, a un módulo de seguridad por hardware o a cualquier infraestructura que ya utilice para proteger datos sensibles de sus clientes. En ese escenario, los secretos no residirían en la base de datos del sitio, ni siquiera cifrados, sino en un sistema externo con sus propios controles de acceso, auditoría y políticas de rotación.
Para los desarrolladores de plugins, la ventaja es que no necesitan saber qué hay detrás. Si su código utiliza la Secrets API, funcionará igual en un alojamiento compartido básico que guarda los secretos cifrados en la base de datos y en una plataforma empresarial que los delega en un gestor externo. La abstracción separa el qué, guardar un secreto, del cómo, que depende del entorno.
Para los proveedores de alojamiento, la beta 5 añade además una responsabilidad práctica. Si la API exige la constante WP_SECRETS_KEY, alguien tiene que generarla y definirla. En instalaciones gestionadas, lo previsible es que sean los propios proveedores quienes la configuren de forma automática al crear o actualizar sitios, del mismo modo que hoy generan las salts. Cómo gestionen esa clave, dónde la guarden y cómo la protejan frente a sus propios incidentes se convierte en una parte relevante de su oferta de seguridad.
Qué cambia para los desarrolladores de plugins
El impacto más directo recae sobre los autores de plugins que manejan credenciales de terceros. Hasta ahora, la decisión de cómo guardar una clave de API dependía de cada uno; a partir de 7.2, existe una vía oficial. Eso no significa que el cambio sea automático: los plugins existentes seguirán guardando sus claves en la tabla de opciones hasta que sus autores decidan migrar.
Esa migración plantea varias cuestiones prácticas. La primera es la compatibilidad hacia atrás. Un plugin que quiera seguir funcionando en versiones anteriores a 7.2 tendrá que detectar si la API existe y, en caso contrario, recurrir al almacenamiento tradicional. La segunda, introducida por la beta 5, es que incluso en sitios con 7.2 la API puede no estar disponible si falta la constante WP_SECRETS_KEY. Los plugins tendrán que comprobar esa situación, manejar el error secret_key_unavailable y decidir qué hacer: avisar al administrador, recurrir a un almacenamiento alternativo o desactivar la funcionalidad que depende del secreto.
La tercera cuestión es el traslado de los datos existentes. Un plugin que ya tiene miles de instalaciones con claves guardadas en opciones necesitará una rutina que lea esos valores, los guarde mediante la nueva API y elimine los originales de la tabla de opciones. Este último paso es crucial: si la copia en texto plano permanece, el beneficio de cifrar desaparece. También conviene tener en cuenta que las copias de seguridad antiguas seguirán conteniendo las credenciales en claro, por lo que la migración es un buen momento para considerar la rotación de las claves en el proveedor externo.
Hay además un aspecto de experiencia de usuario. WordPress 7.2 no incluye una interfaz de administración para gestionar secretos; según el equipo de core, esa pantalla está prevista para una versión posterior. En la práctica, cada plugin seguirá ofreciendo su propio formulario para que el usuario introduzca la clave, aunque por debajo la guarde a través de la nueva API. A medio plazo, una interfaz unificada permitiría a los administradores ver qué secretos existen, qué plugin los utiliza y cuándo se rotaron por última vez, algo que hoy resulta prácticamente imposible.
Para quienes desarrollan sobre WordPress en proyectos a medida, la recomendación implícita es clara: el código nuevo que maneje credenciales debería apoyarse en la Secrets API desde el principio, contemplando el caso de que no esté disponible. Adoptar el almacenamiento cifrado de secretos cuando se escribe una integración es mucho más barato que migrar cuando ya está en producción.
Lo que la Secrets API no resuelve
Una parte importante de la comunicación del equipo de core ha consistido en delimitar con claridad el alcance de la nueva interfaz, y conviene repetirlo para evitar falsas expectativas. La Secrets API protege frente a filtraciones de bases de datos y de copias de seguridad. No protege frente a código malicioso que ya se está ejecutando dentro de WordPress.
La razón es estructural. Para que un plugin legítimo pueda usar una clave de API, el núcleo tiene que descifrarla y entregársela en memoria durante la ejecución. Cualquier código que se ejecute en ese mismo proceso, con los mismos permisos, puede hacer exactamente lo mismo. Un plugin comprometido, un tema con una puerta trasera o un atacante que haya logrado ejecutar código PHP en el servidor tendrán acceso a la constante WP_SECRETS_KEY y a las funciones de descifrado. El cifrado en reposo no tiene respuesta para un adversario que ya está dentro.
Esto no resta valor a la medida, pero sí la sitúa en su contexto. El escenario que cubre, la exposición de datos sin ejecución de código, es frecuente y dañino: inyecciones SQL que solo permiten leer, volcados de base de datos accesibles por error, copias de seguridad almacenadas en servicios mal configurados o entregadas a terceros. En todos esos casos, el atacante obtiene la base de datos pero no el archivo de configuración donde reside la clave, y la Secrets API marca la diferencia.
Hay un matiz adicional que los administradores deberían considerar. Si la constante WP_SECRETS_KEY se define en wp-config.php y una copia de seguridad incluye tanto la base de datos como los archivos del sitio, quien obtenga esa copia tendrá ambas piezas. La protección depende, por tanto, de que la clave y los datos cifrados no viajen juntos. Las políticas de copia de seguridad deberían revisarse con esa idea en mente, y es aquí donde el drop-in para proveedores de alojamiento puede aportar una capa adicional al mantener la clave o los propios secretos fuera del alcance del sistema de archivos del sitio.
Los incidentes recientes en otros sectores ilustran por qué esta distinción importa. La brecha de Fireworks AI, que terminó afectando a conjuntos de datos y secretos, muestra cómo una intrusión puede extenderse a credenciales almacenadas cuando estas no están aisladas. Ninguna capa de cifrado sustituye a una arquitectura que limite el acceso, registre su uso y permita revocar rápidamente lo que se haya expuesto.
Comparativa con otros gestores de secretos
La Secrets API no aparece en el vacío. Otros ecosistemas de desarrollo web llevan años ofreciendo mecanismos similares, y compararlos ayuda a situar la propuesta de WordPress.
En el mundo de los frameworks PHP, Laravel dispone desde hace tiempo de utilidades de cifrado basadas en una clave de aplicación definida en la configuración del entorno. El planteamiento es parecido al que adopta WordPress tras la beta 5: una clave dedicada, separada de otros materiales criptográficos, que se utiliza para cifrar valores almacenados. La diferencia es que en Laravel la gestión de secretos queda en manos del desarrollador de la aplicación, mientras que WordPress aspira a ofrecer una interfaz común para miles de plugins de autores distintos que conviven en el mismo sitio.
Ruby on Rails, por su parte, popularizó el modelo de credenciales cifradas en un archivo versionado junto al código, que solo se puede leer con una clave maestra mantenida fuera del repositorio. Ese enfoque está pensado para secretos que define el equipo de desarrollo durante el despliegue, no para claves que introduce un usuario final desde un panel de administración, que es el caso dominante en WordPress.
En el terreno de la infraestructura, los gestores de secretos dedicados, como HashiCorp Vault o los servicios equivalentes de los grandes proveedores de nube, como AWS Secrets Manager, ofrecen capacidades que van mucho más allá: control de acceso granular, registros de auditoría, rotación automática y, en algunos casos, credenciales dinámicas que se generan bajo demanda y caducan solas. Kubernetes, con su objeto Secret, es un ejemplo de lo que ocurre cuando el nombre promete más de lo que da por defecto: los valores se codifican en base64 y su cifrado en reposo depende de que el clúster se configure para ello.
Frente a ese panorama, la Secrets API de WordPress ocupa un punto intermedio. No pretende competir con Vault ni con los servicios en la nube, pero tampoco se limita a ofuscar valores. Su diseño con un drop-in reemplazable es, de hecho, el puente entre ambos mundos: en un alojamiento modesto, ofrece cifrado en reposo con primitivas modernas; en una plataforma sofisticada, puede delegar en un gestor profesional sin que los plugins lo noten. Esa flexibilidad es probablemente su característica más valiosa a largo plazo.
Situación actual del ciclo de desarrollo
Al momento de escribir esta noticia, WordPress 7.2 se encuentra en la recta final de su fase beta. El calendario arrancó con la beta 1 el 20 de octubre de 2026, y la beta 5, la que introdujo la obligatoriedad de WP_SECRETS_KEY, se publicó a mediados de noviembre. La primera versión candidata, RC1, está prevista para el 17 de noviembre, y el lanzamiento final se espera para el 8 de diciembre de 2026.
La entrada en fase de versiones candidatas suele implicar una congelación de cambios de fondo, por lo que el diseño actual de la Secrets API, con la constante obligatoria y el drop-in para proveedores de alojamiento, es previsiblemente el que llegará a la versión estable. Aun así, los cambios de última hora no son imposibles y conviene seguir las notas de desarrollo hasta el lanzamiento.
La Secrets API no es la única novedad de la versión. WordPress 7.2 también incorpora el tema Ipsum y mejoras en Notes, la funcionalidad de notas colaborativas del editor. Sin embargo, la propia beta 1 confirmó que el modo de sugerencias de Notes, una de las funciones más esperadas por los equipos editoriales, se pospone a WordPress 7.3. Ese aplazamiento ilustra la disciplina del ciclo de lanzamientos: las funciones que no alcanzan la madurez necesaria se trasladan a la siguiente versión en lugar de retrasar todo el calendario.
Para desarrolladores y proveedores de alojamiento, las semanas que restan hasta diciembre son el momento de probar. Instalar la versión candidata en un entorno de staging, definir la constante, comprobar cómo se comportan los plugins propios cuando la API está disponible y cuando no, y revisar las notas oficiales sobre el tratamiento de secretos guardados en betas anteriores son tareas que conviene completar antes del lanzamiento, no después.
Análisis: un paso tardío, pero bien orientado
Resulta inevitable señalar que la Secrets API llega tarde. WordPress impulsa una fracción enorme de la web y su ecosistema de plugins maneja desde hace muchos años credenciales de servicios críticos. Que la plataforma no ofreciera hasta ahora una vía estándar para protegerlas ha sido una carencia evidente, cubierta solo a medias por iniciativas individuales.
Dicho eso, el diseño que se ha ido perfilando durante las betas muestra decisiones sensatas. La elección de libsodium y de un cifrado autenticado moderno evita los errores del cifrado artesanal. La conservación de una versión previa reconoce que la seguridad tiene un componente operativo y que una rotación que rompe servicios es una rotación que nadie hará. El drop-in respeta la arquitectura histórica de WordPress y deja espacio para que los proveedores de alojamiento aporten valor.
El cambio de la beta 5 merece una valoración especial. Exigir una constante dedicada complica la adopción, porque añade un requisito de configuración en un ecosistema que presume de instalaciones en pocos minutos. Pero la alternativa, mantener la clave derivada de las salts, convertía una buena práctica de respuesta a incidentes en una fuente de pérdida de datos. Corregirlo antes de la versión estable, aun a costa de fricción, evita un problema que habría sido mucho más difícil de resolver con millones de sitios en producción.
La gran incógnita es la adopción. Una API que nadie usa no protege nada. El éxito de la iniciativa dependerá de que los autores de plugins populares migren sus credenciales, de que los proveedores de alojamiento definan la constante por defecto y de que la futura interfaz de administración haga visible el estado de los secretos para quienes gestionan los sitios. La seguridad de plugins de WordPress siempre ha sido un esfuerzo colectivo, y esta herramienta no es una excepción.
Lecciones para equipos de desarrollo
Más allá de WordPress, la evolución de esta API deja enseñanzas aplicables a cualquier proyecto. La primera es que el material criptográfico debe tener un único propósito. Reutilizar una clave pensada para firmar sesiones como base para cifrar datos persistentes parecía una comodidad y resultó ser una trampa; el mismo error aparece en muchas aplicaciones que derivan todo de un único secreto maestro.
La segunda lección es que el cifrado en reposo tiene un modelo de amenaza concreto y limitado. Protege frente a quien obtiene los datos sin la clave, no frente a quien ejecuta código con los privilegios de la aplicación. Comunicar ese alcance con honestidad, como ha hecho el equipo de core, evita una falsa sensación de seguridad que puede ser más peligrosa que la ausencia de protección.
La tercera es que la separación entre datos y claves debe mantenerse en todo el ciclo de vida, incluidas las copias de seguridad. De poco sirve cifrar una base de datos si el archivo que contiene la clave viaja en el mismo paquete comprimido hacia el mismo destino.
La cuarta tiene que ver con la arquitectura. Ofrecer una interfaz estable con un backend reemplazable permite que la misma aplicación funcione en entornos con capacidades muy distintas. Es un patrón que cualquier equipo puede aplicar a su propia gestión de secretos: el código de negocio pide una credencial por su nombre y una capa intermedia decide si la obtiene de una variable de entorno, de un archivo cifrado o de un gestor externo.
Por último, la rotación debe diseñarse desde el principio. Conservar la versión anterior de un secreto durante la transición es una idea sencilla que reduce drásticamente el riesgo de cambiar credenciales, y es precisamente ese riesgo el que hace que tantas claves permanezcan años sin renovarse.
Conclusiones
WordPress 7.2 introduce con la Secrets API una pieza que el ecosistema necesitaba desde hace tiempo: un mecanismo oficial para guardar claves de API, tokens y otras credenciales cifradas en reposo, en lugar de dejarlas en texto plano en la tabla de opciones. El diseño apuesta por libsodium y el cifrado autenticado XChaCha20-Poly1305, conserva una versión previa de cada secreto para facilitar la rotación y permite a los proveedores de alojamiento sustituir el almacenamiento con su propio backend a través del drop-in secrets.php.
El ajuste de la beta 5, que hace obligatoria la constante WP_SECRETS_KEY y devuelve el error secret_key_unavailable cuando falta, corrige un acoplamiento peligroso con las salts de inicio de sesión, cuya rotación dejaba inaccesibles los secretos guardados. A cambio, introduce un requisito de configuración que plugins y proveedores de alojamiento deberán atender. Sobre el destino de los secretos creados en betas anteriores, la información disponible no es concluyente, y lo prudente es atenerse a las notas oficiales.
La API tiene límites claros: no incluye todavía una interfaz de administración, prevista para una versión posterior, y protege frente a filtraciones de bases de datos y copias de seguridad, no frente a código malicioso que ya se ejecuta dentro de WordPress. Con la RC1 prevista para el 17 de noviembre y el lanzamiento final para el 8 de diciembre de 2026, junto al tema Ipsum y las mejoras en Notes, el reto ahora es la adopción. Si los autores de plugins migran sus credenciales y los proveedores de alojamiento facilitan la configuración, la próxima filtración de una base de datos de WordPress podría exponer bastante menos de lo que hoy expone.