Die für WordPress 7.2 geplante Secrets API soll Zugangsdaten wie API-Schlüssel und OAuth-Geheimnisse verschlüsselt speichern. Nach Änderungen in der fünften Beta benötigen vorhandene Websites dafür jedoch einen eigenen Schlüssel namens WP_SECRETS_KEY, den ein normales Upgrade nicht automatisch einrichtet. Das WordPress-Hosting-Team hat am 12. November 2026 zu Tests dieser Umstellung aufgerufen.
Zugleich ist das Sicherheitskonzept umstritten. Der langjährige WordPress-Entwickler Ryan McCue hält es für problematisch, dass Geheimnisse direkt aus einer laufenden Anwendung geschrieben werden können. WordPress-Mitgründer Matt Mullenweg schloss sich seiner Kritik am 13. November öffentlich an. Ob sich dadurch der geplante Funktionsumfang ändert, ist noch offen.
Verschlüsselung für Zugangsdaten von Plugins
WordPress-Plugins verwalten regelmäßig Zugangsdaten zu Zahlungsdiensten, Newsletter-Plattformen oder externen Schnittstellen. Die neuen Funktionen wp_set_secret() und wp_get_secret() schaffen dafür eine gemeinsame Schnittstelle. Die Standardimplementierung speichert verschlüsselte Einträge in den WordPress-Optionstabellen. Dabei wird libsodium mit XChaCha20-Poly1305 eingesetzt; ein zufälliger Root-Key wird wiederum durch einen separaten Schlüssel in wp-config.php geschützt.
Die vorherige Fassung eines Geheimnisses kann für eine kontrollierte Rotation erhalten bleiben, wenn nicht alle angebundenen Dienste gleichzeitig umgestellt werden. Bestehende Klartextwerte werden durch den WordPress-Kern allerdings nicht automatisch migriert: Erweiterungen müssen die API zunächst selbst verwenden. Wichtig ist außerdem ihre Grenze: Die Namensräume der Plugins sind keine Zugriffsbeschränkung. Bereits kompromittierter PHP-Code innerhalb einer Installation kann auch Geheimnisse anderer Erweiterungen auslesen.
Warum aktualisierte Websites noch keinen Schlüssel besitzen
Seit WordPress 7.2 Beta 5 leitet das System den Schutzschlüssel nicht mehr ersatzweise aus bisherigen Authentifizierungsschlüsseln und Salts ab. Ohne gültigen WP_SECRETS_KEY kann die neue API keine Geheimnisse ablegen und vorhandene Werte nicht entschlüsseln; sie meldet secret_key_unavailable. Eine übliche Änderung der WordPress-Salts soll dadurch nicht länger versehentlich den Zugriff auf verschlüsselte Zugangsdaten unterbrechen.
Bei einer Neuinstallation über den Browser erzeugt der Installer nach aktuellem Stand den zusätzlichen Schlüssel. Bestehende Websites erhalten ihn durch ein Upgrade nicht automatisch. Das gilt bislang auch für Installationen, deren Konfiguration etwa über WP-CLI, One-Click-Installer oder eigene Provisionierung geschrieben wird. Der WordPress-Kern greift selbst noch nicht auf die neue API zu. Das Upgrade allein legt daher nicht pauschal eine laufende Website lahm; relevant wird der fehlende Schlüssel vor allem, wenn Erweiterungen auf die neue Speicherung umstellen. Hoster sollten ihre Bereitstellungsskripte deshalb vorab prüfen.
Provider, Backups und Fehlerfälle berücksichtigen
Hoster können über ein wp-content/secrets.php-Drop-in einen separaten Schlüsseldienst oder einen externen Secrets-Provider anbinden. Ein solcher Provider darf ausdrücklich schreibgeschützt sein. Plugin-Entwickler müssen deshalb die Verfügbarkeit über wp_is_secrets_api_available() und gegebenenfalls die Schreibfähigkeit über wp_secrets_provider_is_writable() prüfen. Auch Rückgabewerte vom Typ WP_Error dürfen nicht ignoriert werden.
Ein fehlgeschlagener Lesezugriff ist nicht mit einem bisher nicht gespeicherten Secret gleichzusetzen: wp_get_secret() liefert nur im zweiten Fall null. Auch Backups brauchen Aufmerksamkeit. Wird eine verschlüsselte Datenbankkopie mit anderem Schlüssel auf einer Staging-Installation wiederhergestellt, sind die gespeicherten Werte nicht ohne Weiteres lesbar. Schlüsselrotation und Wiederherstellung sollten deshalb dokumentiert und getestet werden. Bei Multisite-Installationen müssen nach der am 13. November überarbeiteten Anleitung insbesondere die einzelnen Netzwerke berücksichtigt werden.
Ältere Beta-Drop-ins können nach dem Update scheitern
Die Schnittstelle hat sich während der Testphase geändert. WP_Secrets_Keyring, WP_Secrets_Store und WP_Secrets_Provider sind inzwischen abstrakte Klassen statt Interfaces. Wer ein eigenes Drop-in auf Basis einer älteren Beta noch mit implements statt extends einbindet, riskiert einen fatalen PHP-Fehler. Die Anpassung muss zusammen mit dem getesteten WordPress-Stand erfolgen.
Für Testumgebungen, die mit älteren Beta-Versionen ohne eigenen Schlüssel bereits Secrets gespeichert haben, ist eine kontrollierte Migration möglich. Die Entwickler dokumentieren dafür WP_SECRETS_KEY_PREVIOUS und eine Neuschlüsselung. Bestehende Salts oder Schlüssel sollten vor Abschluss einer solchen Migration nicht auf Verdacht geändert werden. Für normale produktive WordPress-Websites besteht kein Grund, eine Beta zu installieren.
Kritik an der Verwaltung sensibler Zugangsdaten
In der Diskussion unter den offiziellen Entwicklerhinweisen kritisiert Ryan McCue vor allem die Vermischung von zwei Aufgaben: extern bereitgestellte Secrets lesen und neue Secrets direkt aus der Webanwendung heraus schreiben. Für professionelle Hosting-Umgebungen sei eine getrennte, möglichst schreibgeschützte Verwaltung häufig die robustere Architektur. Matt Mullenweg unterstützte diesen Einwand in zwei Kommentaren vom 13. November. Eine formelle Entscheidung, die API aus WordPress 7.2 zu entfernen, ist damit bisher nicht verbunden.
Der an der neuen Schnittstelle arbeitende Entwickler Eric Mann argumentiert dagegen, dass viele WordPress-Websites keinen externen Secrets-Manager besitzen. Dort landen Zugangsdaten bislang häufig als Klartext in Plugin-Optionen, Backups und Datenbankexporten. Die gemeinsame Schnittstelle solle sowohl eine verschlüsselte Standardablage als auch externe, schreibgeschützte Provider ermöglichen. Unabhängig davon müssen Erweiterungen mit diesen unterschiedlichen Betriebsarten korrekt umgehen; ein fehlgeschlagener Schreibversuch darf nicht stillschweigend auf eine unverschlüsselte Option ausweichen.
Release Candidate steht bevor
Vor allem Entwickler eigener Plugins, Betreiber automatisierter Hosting-Plattformen und Verantwortliche für Multisite-Installationen sollten die fünfte Beta auf getrennten Testsystemen prüfen: Schlüsselbereitstellung, Fehlerausgabe, das Verhalten mit schreibgeschützten Providern und die Wiederherstellung von Sicherungen. Für gewöhnliche Website-Betreiber entsteht praktischer Handlungsbedarf erst mit der Einführung von Plugins, die diese API tatsächlich nutzen. Die erste Release-Candidate-Version von WordPress 7.2 ist für den 17. November 2026 geplant, die finale Ausgabe für den 8. Dezember. Bis dahin können sich Details ändern.
Die offiziellen Entwicklerhinweise zur Secrets API erläutern Funktionen, Änderungen und Migrationsregeln. Für Hosting-Anbieter enthält der Testaufruf des WordPress-Hosting-Teams zusätzliche Prüfpunkte. Die vorgesehenen Termine stehen auf der WordPress-7.2-Projektseite.
Meroth IT-Service ist Ihr lokaler IT-Dienstleister in Frankfurt am Main für kleine Unternehmen, Selbstständige und Privatkunden
Kostenfreie Ersteinschätzung Ihres Anliegens?
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten