WordPress 7.2 bekommt eine Secrets API, die API-Schlüssel und OAuth-Client-Secrets, also vertrauliche Zugangsdaten, verschlüsselt speichert. Eric Mann beschreibt sie in einer Dev Note vom 11. November 2026 auf make.wordpress.org. Der Release von WordPress 7.2 ist für den 8. Dezember 2026 geplant.
Für Website-Betreiber hängt daran ein einzelner Schritt: Die Verschlüsselung läuft nur mit einem Schlüssel namens WP_SECRETS_KEY in der wp-config.php. Fehlt dieser Schlüssel, speichert die API nichts. Beschränkungen nach Ländern oder Sprachen nennt die Dev Note nicht.
Wie schützt die Secrets API gespeicherte Zugangsdaten?
WordPress verschlüsselt jedes Secret mit libsodium (XChaCha20-Poly1305) und legt es in den Options-Tabellen der Datenbank ab. Die Einzelschlüssel leitet WordPress aus einem zufälligen Root-Key (Hauptschlüssel) ab. Dieser liegt verschlüsselt in der Datenbank und ist mit WP_SECRETS_KEY geschützt, einem zufälligen, base64-kodierten 32-Byte-Schlüssel in der wp-config.php.
Secrets API: Was sie kann und was nicht
Neu in WordPress 7.2, Release geplant für den 8. Dezember 2026
- Verschlüsselt API-Schlüssel und OAuth-Client-Secrets
- Behält zu jedem Secret die vorherige Version für den Schlüsselwechsel
- Zeigt Werte in Ausgabe, Logs und JSON nur als Ersatztext
- Speichert nichts ohne WP_SECRETS_KEY in der wp-config.php
- Prüft keine Berechtigungen der Aufrufer
- Schützt nicht vor anderem Code auf der Website
Stand der Dev Note vom 11. November 2026, WordPress 7.2 ist noch in der Beta.
Quellen: Make WordPress Core, WordPress News
Laut der Dev Note erzeugt Site Health eine fertige Zeile für den Schlüssel zum Kopieren, und auch WP-CLI soll ihn mit wp config create schreiben. Anders als die Salts darfst du den Schlüssel nicht einfach ändern oder entfernen, sonst sind alle gespeicherten Secrets unlesbar. Ein leerer Wert, der Beispielwert aus der wp-config-sample.php oder die Kopie eines Auth-Keys oder Salts zählt nicht als brauchbarer Schlüssel. In diesen Fällen meldet die API den Fehler secret_key_unavailable.
Im Code arbeiten Plugin-Autoren mit wp_set_secret() und wp_get_secret(). Das zurückgegebene Objekt der Klasse WP_Secret zeigt bei Ausgabe, Protokollierung und JSON nur einen Ersatztext wie [secret:name]. Den Wert liefert allein die Methode reveal(). Zu jedem Secret bleibt die vorherige Version erhalten, damit sich Schlüssel austauschen lassen.
Wo liegen die Grenzen der Secrets API?
Die Funktionen prüfen keine Berechtigungen. Plugin-Autoren müssen selbst kontrollieren, wer einen Wert eingeben oder verwalten darf, denn Cron und REST wären sonst ungeschützt. Außerdem kann jeder Code auf der Website jedes Secret lesen. Der Namensanteil vor dem Schrägstrich, etwa plugin-slug/secret-name, verhindert nur ein versehentliches Überschreiben zwischen Plugins und ist keine Zugriffskontrolle.
Hosting-Anbieter können den Schutz des Schlüssels, den Speicherort oder die gesamte Verwaltung über ein Drop-in namens wp-content/secrets.php an einen eigenen Dienst übergeben, etwa an ein Key Management System. Ein fehlerhaftes Drop-in greift nicht auf die Standardwerte zurück, jeder Aufruf gibt dann einen Fehler zurück.
Site Health bekommt im Bereich „Security“ drei neue Tests. Der Test zur Schlüsselquelle meldet den Status „recommended“ (empfohlen), wenn der Schlüssel fehlt, und „critical“ (kritisch), wenn sich der Root-Key nicht entschlüsseln lässt. Ein zweiter Test wird „critical“, sobald gespeicherte Secrets unlesbar sind. Der dritte meldet „recommended“, wenn Zugangsdaten für einen Wechsel vorgemerkt sind.
Was das für dich bedeutet
Teste die Secrets API zuerst in einer Testumgebung mit der Beta, denn das WordPress-Team schreibt im Beitrag zu Beta 5, die Beta sei nur zum Testen und für die Entwicklung gedacht. Setze dort am besten WP_SECRETS_KEY in der wp-config.php und sieh in Site Health nach, was der Test zur Schlüsselquelle meldet.
Unsere Einschätzung: Bewahre den Schlüssel am besten zusätzlich außerhalb der Website auf, etwa im Passwortmanager, und nimm ihn ins Backup auf. Ohne ihn lassen sich die Secrets aus einem Datenbank-Backup nicht mehr lesen. Allerdings schützt die Verschlüsselung die Werte in der Datenbank nur, solange der Schlüssel nicht gemeinsam mit einem Datenbank-Export weitergegeben wird.
Entwickelst du Plugins oder Kundenseiten mit eigenen Zugangsdaten, prüf vor der Umstellung mit wp_is_secrets_api_available(), ob die API zur Verfügung steht. Behandle einen Fehler von wp_get_secret() außerdem nicht als „fehlend“, sonst überschreibt dein Code einen funktionierenden Zugang. Die Funktion wp_import_option_as_secret() kopiert eine bestehende Option in ein Secret. Die Option bleibt bestehen, und du löschst sie von Hand.
Eric Mann hat die Dev Note am 11. November 2026 veröffentlicht.
Quellen
