Auf Beta-Websites ohne eigenen Schlüssel machte das Rotieren der Salts alle gespeicherten Zugangsdaten unlesbar. WordPress 7.2 streicht deshalb den Ersatzschlüssel aus den Salts. Bestehende Websites müssen die Konstante WP_SECRETS_KEY selbst in die wp-config.php eintragen, sonst speichert die Secrets API nichts.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenInhalt 5 Abschnitte
Eric Mann hat am 11. November im Entwicklerblog Make WordPress Core beschrieben, wie die Secrets API in WordPress 7.2 arbeitet.[1] Die Version soll am 8. Dezember erscheinen, die fünfte Beta kam am 10. November.[2] Die Secrets API legt API-Schlüssel und OAuth-Zugangsdaten von Plugins verschlüsselt ab und hält die vorherige Fassung zur Rotation bereit.[1]
Das Wichtigste in Kürze
- Ohne die Konstante WP_SECRETS_KEY in der wp-config.php scheitert jedes Schreiben und Lesen.
- Der Ersatz aus LOGGED_IN_KEY und LOGGED_IN_SALT aus den Betas ist gestrichen.
- Neue Installationen erhalten den Schlüssel automatisch, bestehende Websites tragen ihn selbst ein.
- Drop-ins aus den Betas müssen auf abstrakte Klassen umgestellt werden, sonst bricht jede Anfrage ab.
Was ändert sich für bestehende Websites?
Die Secrets API verschlüsselt jeden Eintrag mit libsodium und legt ihn in den Optionstabellen ab. Die Einzelschlüssel leitet WordPress aus einem zufälligen Hauptschlüssel ab, den wiederum die Konstante WP_SECRETS_KEY verschlüsselt.[1] Fehlt sie, ist leer, stammt aus der wp-config-sample.php oder ist aus den Salts kopiert, gilt sie als unbrauchbar. Jeder Zugriff liefert dann den Fehler secret_key_unavailable.[1]
Neue Installationen erhalten den Schlüssel vom Installer, bestehende brauchen eine Zeile unterhalb der Salts. Site Health erzeugt sie unter „Sicherheit“ zum Kopieren.[1] Die Betas ersetzten einen fehlenden Schlüssel durch einen Wert aus den Salts. Betreiber tauschen die Salts üblicherweise nach einem Einbruch, weil damit alle Sitzungen enden. Genau dann wären die Zugangsdaten verloren gewesen. Den neuen Schlüssel darf niemand mehr ändern, sobald Secrets existieren.[1]
Was schützt die Secrets API und was nicht?
Der Schlüssel liegt in einer Datei, die verschlüsselten Einträge liegen in der Datenbank. Ein Export, ein Backup oder eine SQL-Injection allein liefert nur verschlüsselte Daten. Wie offen Zugangsdaten bisher lagen, zeigte das Formular-Plugin MetForm. Zuletzt legte der Express-Checkout von WooCommerce Stripe Passwörter im Klartext ab.
Die Grenze nennt die Dokumentation selbst: Jeder Code auf der Website kann jedes Secret lesen, die Funktionen prüfen keine Berechtigungen, weil sie auch aus Cron und REST laufen müssen.[1] Ein bösartiges Plugin kommt also weiter an die Zugangsdaten. Hoster können den Speicher per Drop-in an einen externen Tresor anbinden. Drop-ins aus den Betas müssen dafür implements durch extends ersetzen, weil die Schnittstellen jetzt abstrakte Klassen sind.[1]
Was mit dem Schlüssel passieren kann
Die Tests in Site Health unter „Sicherheit“
Die Einstufungen stammen aus der Entwicklerdokumentation zu WordPress 7.2. Die Konstante braucht jede bestehende Website, neue Installationen bekommen sie vom Installer.
Nach einem Einbruch tauschen Betreiber die Salts. Dass sie dabei keine gespeicherten Zugangsdaten mehr verlieren, ist die richtige Entscheidung.
Markus Seyfferth, Chefredakteur Dr. Web
Was heißt das für Betreiber, Agenturen und Hoster?
Zugangsdaten zu Newsletter- und Zahlungsdiensten führen zu personenbezogenen Daten. Art. 32 DSGVO nennt die Verschlüsselung als mögliche Schutzmaßnahme. Ob sie im Einzelfall geschuldet ist, entscheidet die Risikoabwägung des Verantwortlichen.
Hoster und Werkzeuge, die die wp-config.php schreiben, sollen den Schlüssel zusammen mit den Salts anlegen, WP-CLI passt seinen Befehl wp config create an.[1] Betreiber gehen so vor:
- Prüfen: Nach dem Update auf 7.2 unter Werkzeuge › Website-Zustand den Test zur Schlüsselquelle ansehen.
- Eintragen: Die von Site Health erzeugte Zeile unterhalb der Salts in die wp-config.php kopieren und nicht mit den Salts mitrotieren.
- Sichern: Die Konstante in jede Sicherung der wp-config.php aufnehmen, denn der Hauptschlüssel in der Datenbank lässt sich nur mit ihr öffnen.
- Nachziehen: Wer in einer Beta ohne Schlüssel gespeichert hat, folgt den Migrationsschritten der Dokumentation, bevor er die Salts anfasst.
- Entwickeln: Plugin-Autoren fragen wp_is_secrets_api_available() ab, bevor sie Zugangsdaten umziehen, und fragen bei einem Lesefehler nicht neu ab.
Anbieter vergleicht der WordPress-Hosting-Vergleich. Sicherungen vergleicht der Backup-Plugin-Vergleich.
FAQ: WordPress 7.2 verlangt für die Secrets API einen eigenen Schlüssel
Was ist WP_SECRETS_KEY in WordPress 7.2?
WP_SECRETS_KEY ist eine Konstante in der wp-config.php. Die Konstante verschlüsselt den Hauptschlüssel, aus dem WordPress die Schlüssel für einzelne Zugangsdaten ableitet. Ohne einen brauchbaren Wert speichert die Secrets API nichts. Site Health erzeugt auf Wunsch eine passende Zeile zum Kopieren.
Muss ich nach dem Update auf WordPress 7.2 etwas tun?
Nur wenn ein Plugin die Secrets API nutzen soll. Neue Installationen bekommen den Schlüssel vom Installer. Auf bestehenden Websites trägt der Betreiber ihn unterhalb der Salts in die wp-config.php ein. Site Health zeigt unter „Sicherheit“, ob der Schlüssel fehlt.
Kann ich die Salts weiterhin tauschen?
Ja. In der Beta hingen gespeicherte Secrets ohne eigenen Schlüssel noch an LOGGED_IN_KEY und LOGGED_IN_SALT, in der Endfassung nicht mehr. Den WP_SECRETS_KEY dürfen Betreiber dagegen nicht ändern oder löschen, sonst sind alle Secrets unlesbar, bis der alte Wert zurückkommt.
Schützt die Secrets API vor einem bösen Plugin?
Nein. Jeder Code, der auf der Website läuft, kann jedes Secret lesen, weil die Funktionen keine Berechtigungen prüfen. Der Namensanteil vor dem Schrägstrich verhindert nur, dass Plugins sich versehentlich überschreiben. Geschützt sind Datenbank-Exporte und Backups.
Quellen
2 Quellen anzeigenQuellen ausblenden
- Make WordPress CoreThe Secrets API in WordPress 7.2 (Eric Mann)
- WordPress.org NewsWordPress 7.2 Beta 5
Mehr Newshunger?
- WordPress 7.2 soll API-Schlüssel von Plugins verschlüsselt speichern
- WordPress will KI-Agenten mit Version 7.3 direkt anbinden
- WordPress 7.2 Beta 1 ist da, die finale Version folgt am 8. Dezember
- WordPress 7.2 leitet /random/ auf einen beliebigen Beitrag um
- Sicherheitslücke bei WooCommerce Stripe im Express-Checkout
- Backup Plugins für WordPress Vergleich 2026
