Website & Technik1. Oktober 2026 

WordPress Secrets API: Wo deine API-Schlüssel heute liegen und was 7.2 ändern soll

Veröffentlicht:

Lesedauer
min
WordPress Secrets API: Wo deine API-Schlüssel heute liegen und was 7.2 ändern soll

Das Wichtigste in Kürze

  • WordPress 7.2 soll eine Secrets API bekommen: Plugins können Zugangsdaten dann verschlüsselt speichern, statt sie wie bisher meist im Klartext in die Datenbank zu schreiben. Der Patch dafür ist eingereicht, am 6. Oktober 2026 aber noch nicht in WordPress eingebaut.
  • Eine Oberfläche zum Verwalten ist erst für 7.3 vorgesehen. Wirken wird die API erst, wenn eure Plugins sie nutzen.
  • Bis dahin hilft eine Inventur: Welche Schlüssel liegen auf der Website, wer kann sie lesen, wo landen Kopien?

Sobald eine WordPress-Firmenwebsite Formulare verschickt, ein CRM anbindet oder Besucher zählt, liegen dort Zugangsdaten zu anderen Diensten: das Passwort für den Mailversand, der Schlüssel fürs CRM, der Zugang zu Google-Diensten, inzwischen oft ein Schlüssel für einen KI-Anbieter. WordPress selbst hat bis heute keinen eigenen, geschützten Platz dafür. Das steht so im Vorschlag für eine „Secrets API“, die mit WordPress 7.2 kommen soll. Geplant ist der 8. bis 10. Dezember 2026.

Die gute Nachricht: Du musst nicht bis Dezember warten, um zu wissen, wo eure Schlüssel liegen. Plane für die Inventur eine Stunde ein. Sie lohnt sich unabhängig davon, ob die neue Schnittstelle pünktlich kommt.

Was der Vorschlag genau sagt

Der Vorschlag vom 25. August 2026 auf make.wordpress.org beschreibt das Problem so: Jedes Plugin, das einen API-Schlüssel braucht, schreibt ihn heute in die Options-Tabelle (die Tabelle wp_options, in der WordPress auch den Seitentitel und die Untertitelzeile speichert). In der Regel im Klartext.

Der Vorschlag betont, dass das kein Vorwurf an Plugin-Entwickler ist. Es gab schlicht keinen anderen Weg. Manche Plugins verschlüsseln selbst, als Beispiel nennt der Text Site Kit für die Google-Zugangsdaten. Jedes davon macht es aber anders, mit eigener Schlüsselableitung und eigenen Fehlerquellen.

Die Folge beschreibt der Vorschlag so: Die Zugangsdaten landen in jedem Datenbank-Export, in jedem Backup und in jeder Staging-Kopie (einer Testkopie der Website, oft bei einem anderen Dienstleister oder Hoster).

Einen Punkt hebt der Text besonders hervor. Früher lagen auf einer typischen Website ein Newsletter-Schlüssel und ein reCAPTCHA-Schlüssel. Mit KI-Anbindungen kommen Schlüssel dazu, die direkt Geld kosten, weil der Anbieter nach Verbrauch abrechnet. Wer so einen Schlüssel abgreift, nutzt ihn auf eure Rechnung.

Was sich mit WordPress 7.2 ändern soll

Die Roadmap zu 7.2 vom 18. September nennt drei Sicherheitsvorhaben: die Secrets API, einen „Sudo-Modus“ und eine Härtung der Application Passwords. Für die Secrets API sieht der Vorschlag Folgendes vor:

PunktWas geplant ist
VerschlüsselungImmer an. Es gibt keinen Schalter, um sie abzuschalten, und keinen Klartext-Modus.
SpeicherortStandardmäßig weiter die Options-Tabelle, aber nur als verschlüsselter Block. Nicht über die REST-Schnittstelle für Einstellungen auslesbar.
Externe TresoreÜber eine Zusatzdatei secrets.php lassen sich externe Speicher wie Vault oder ein Schlüsseldienst des Hosters anbinden.
Schutz in LogsEin gespeicherter Schlüssel erscheint in Fehlermeldungen und Debug-Ausgaben maskiert.
ProtokollBei jeder Änderung löst WordPress ein Ereignis aus, das festhält, wer wann geändert hat. Sichtbar ist ein Fingerabdruck des Werts, nicht der Wert selbst.
BerechtigungenZwei neue Rechte: manage_secrets und für Multisite manage_network_secrets.
KommandozeileBefehle für WP-CLI (das Kommandozeilen-Werkzeug für WordPress), damit Schlüssel nicht mehr im Befehlsverlauf des Servers landen. Sie liegen im Feature-Plugin, der Patch für WordPress selbst enthält keine.
OberflächeErst in WordPress 7.3.

Das Feature-Plugin, das der Vorschlag angekündigt hat, liegt seit dem 4. September 2026 auf GitHub, zuletzt als Version 0.2.1, lauffähig ab WordPress 6.6. Es trägt den Status „pre-core-merge“: Der Patch für WordPress selbst ist als Trac-Ticket #66187 eingereicht und wird geprüft, am 6. Oktober war er noch nicht eingebaut. Wer das Plugin ausprobieren will, installiert es auf der Staging-Kopie, nicht auf der Live-Website.

Für Plugins gibt es eine Umzugsfunktion: wp_import_option_as_secret() übernimmt einen bestehenden Wert aus der Options-Tabelle in den verschlüsselten Speicher und markiert ihn zum Austausch, weil er vorher im Klartext lag. Ob und wann eure Plugins das nutzen, entscheiden deren Hersteller.

Der Sudo-Modus

Der Sudo-Modus soll besonders heikle Aktionen im Backend hinter eine erneute Passwortabfrage legen, auch wenn jemand schon eingeloggt ist. Das Prinzip kennst du vom Online-Banking: Angemeldet bist du, für die Überweisung fragt die Bank trotzdem noch einmal nach. Laut Roadmap beginnen die Arbeiten daran gerade erst.

Application Passwords

Application Passwords (Zugangsdaten, mit denen externe Programme über die Schnittstelle auf WordPress zugreifen) gibt es schon. Auf der Liste für 7.2 stehen unter anderem eine E-Mail-Benachrichtigung, wenn jemand ein neues Application Password anlegt, und eine korrigierte Umgebungsprüfung für Websites ohne HTTPS. Beides sind offene Tickets, keine fertigen Funktionen.

Was die Roadmap ausdrücklich offenlässt

Die Roadmap schreibt selbst, dass nicht jeder Punkt sicher im fertigen Release landet. Für die Planung heißt das:

  • Der Termin ist ein Plan. Beta 1 ist für den 20. bis 22. Oktober angesetzt, das Release für den 8. bis 10. Dezember 2026 (Zeitplan auf make.wordpress.org).
  • Die API schützt nur, was sie nutzt. Ein Schlüssel, den ein Plugin weiter in die Options-Tabelle schreibt, bleibt dort im Klartext, auch nach dem Update auf 7.2.
  • Alte Kopien bleiben alt. Backups und Staging-Kopien von vor dem Umzug enthalten die Schlüssel weiterhin lesbar.

Dieser Teil geht beim Update leicht unter: Die Website wird sicherer, ihre Vergangenheit nicht. Was dagegen hilft, steht weiter unten bei der Rotation: Ein neuer Schlüssel macht jede alte Kopie wertlos.

Die Inventur: fünf Fragen für die nächste Stunde

Die Inventur braucht keinen Entwickler. Du brauchst Admin-Zugang und eine Liste der aktiven Plugins.

  1. Welche Dienste sind angebunden? Geh die Plugin-Liste durch und notiere jedes Plugin, das mit einem externen Dienst spricht: Mailversand (SMTP), Formulare mit CRM-Anbindung, Newsletter, Zahlungsanbieter, Analytics, Übersetzung, KI-Funktionen.
  2. Welcher Schlüssel gehört zu welchem Konto? Schreib zu jedem Dienst, auf wessen Konto der Schlüssel läuft. Manchmal ist es das private Konto eines ehemaligen Mitarbeiters oder des früheren Dienstleisters.
  3. Kostet der Schlüssel Geld pro Nutzung? Bei KI-Anbietern und manchen Übersetzungsdiensten ja. Für diese Schlüssel lohnt ein Ausgabelimit im Konto des Anbieters, sofern der Anbieter eines anbietet.
  4. Wo liegen Kopien der Datenbank? Backups beim Hoster, Backups im Plugin, Staging-Kopien, ein Export auf dem Laptop für den letzten Relaunch. Jede Kopie enthält die Schlüssel.
  5. Wer hat Admin-Rechte? Ein Admin-Konto kann heute praktisch jede Einstellung lesen. Ungenutzte Admin-Konten zurückstufen oder löschen ist der schnellste Schutz für alle Schlüssel zugleich.

Bei Schlüsseln, die auf Konten von Personen laufen, die nicht mehr im Haus sind, empfehlen wir einen neuen Schlüssel beim Anbieter und das Löschen des alten. Das nennt man Rotation (Austausch eines Schlüssels gegen einen neuen). Danach sind alle alten Kopien wertlos, egal wo sie liegen.

Warum gerade der Mailversand dazugehört

SMTP-Zugangsdaten (Benutzername und Passwort für den Mailserver) stecken auf vielen Firmenwebsites, weil Formulare sonst nicht zuverlässig zustellen. Im Sommer hat eine Lücke im Plugin Gravity SMTP gezeigt, was passiert, wenn so ein Plugin seine Schnittstelle nicht absichert: Fremde konnten ohne Login Zugangsdaten auslesen. Den Fall haben wir hier aufgeschrieben: Eine WordPress-Lücke, 17 Millionen Angriffe.

Eine Secrets API hätte diese Lücke nicht geschlossen, denn der Fehler lag in der Schnittstelle des Plugins. Sie hätte aber verhindert, dass der Schlüssel in jedem Backup und jedem Testsystem im Klartext mitwandert. Beides gehört zusammen: Updates schließen Lücken, verschlüsselte Ablage begrenzt, was über Kopien abfließt.

Wie wichtig zügige Updates sind, zeigt WordPress 7.1.2 vom 22. September: Die Sicherheitsmeldung nennt eine kritische Lücke, über die Angreifer ohne Login unter bestimmten Bedingungen Code auf dem Server ausführen konnten. Was Betreiber dazu prüfen, steht in unserem Beitrag zu WordPress 7.1.1 und 7.1.2.

Was du bis Dezember konkret tun kannst

  • Jetzt: Inventur nach den fünf Fragen oben. Ergebnis ist eine Tabelle mit Dienst, Plugin, Kontoinhaber, Kostenrisiko und Ablageort der Kopien.
  • Im Oktober: Alte Staging-Kopien und Exporte löschen, die niemand mehr braucht. Schlüssel auf fremden oder privaten Konten austauschen.
  • Ab Beta 1: Bei den Herstellern eurer wichtigsten Plugins nachfragen, ob sie die Secrets API unterstützen wollen. Ein Ticket im Support-Forum reicht.
  • Nach dem Release: 7.2 zuerst auf der Staging-Kopie einspielen und Mailversand, Formulare und Schnittstellen testen, dann auf der Live-Website.

Wer Schlüssel schon heute aus der Datenbank heraushalten will, kann sie bei vielen Plugins als Konstante in die Datei wp-config.php schreiben (die zentrale Konfigurationsdatei von WordPress). Ob ein Plugin das unterstützt, steht in seiner Dokumentation. Das ist kein Ersatz für Verschlüsselung, aber die Werte wandern dann nicht mehr mit jedem Datenbank-Export mit.

Zugangsdaten-Inventur gemeinsam durchgehen

Wenn du die Inventur nicht allein machen willst oder bei einzelnen Plugins unsicher bist, wo die Schlüssel liegen, schauen wir uns das gemeinsam an. Am Ende steht eine Liste mit allen angebundenen Diensten, dem Ablageort der Zugangsdaten und den Schlüsseln, die ihr tauschen solltet. Das Erstgespräch dauert 15 Minuten und kostet nichts. Mehr zu unserer WordPress-Betreuung steht auf der Leistungsseite.

Zugangsdaten-Inventur im Erstgespräch durchgehen

Häufige Fragen

Was ist die WordPress Secrets API?

Eine geplante Schnittstelle, über die Plugins Zugangsdaten wie API-Schlüssel und Passwörter verschlüsselt speichern. Sie soll mit WordPress 7.2 kommen, geplant für den 8. bis 10. Dezember 2026. Eine Verwaltungsoberfläche ist erst für 7.3 vorgesehen.

Sind meine Zugangsdaten nach dem Update auf 7.2 automatisch verschlüsselt?

Nein. Die Secrets API schützt nur Schlüssel, die ein Plugin aktiv dort ablegt. Plugins, die weiter in die Options-Tabelle schreiben, speichern dort weiter im Klartext. Auch alte Backups und Staging-Kopien bleiben unverändert.

Was ist der Sudo-Modus in WordPress?

Eine geplante Funktion, die besonders heikle Aktionen im Backend hinter eine erneute Passwortabfrage legt, auch bei bestehender Anmeldung. Laut Roadmap vom 18. September 2026 beginnen die Arbeiten erst. Ob er in 7.2 landet, ist offen.

Was kann ich vor WordPress 7.2 tun?

Eine Inventur aller angebundenen Dienste machen, alte Datenbank-Kopien löschen, Schlüssel auf fremden Konten austauschen und ungenutzte Admin-Konten entfernen. Für kostenpflichtige Schlüssel, etwa bei KI-Anbietern, lohnt ein Ausgabelimit beim Anbieter.

Ersetzen Application Passwords die Secrets API?

Nein. Application Passwords regeln, wie externe Programme sich bei WordPress anmelden. Die Secrets API regelt, wie WordPress und seine Plugins Zugangsdaten zu fremden Diensten speichern. Das sind zwei verschiedene Richtungen. ---

Quellen

  • Make WordPress Core, Roadmap to 7.2, 18.09.2026, zuletzt geändert 28.09.2026. make.wordpress.org
  • Make WordPress Core, Proposal: A Secrets API for WordPress 7.2, 25.08.2026. make.wordpress.org
  • Make WordPress Core, WordPress 7.2, zuletzt geändert 28.09.2026. make.wordpress.org
  • GitHub, ericmann/secrets-api, README 'Status: feature plugin, pre-core-merge', WordPress 6.6+, Tags v0.1.0 bis v0.2.1, abgerufen 06.10.2026. github.com
  • WordPress Core Trac, Ticket #66187 Secrets API. core.trac.wordpress.org
  • WordPress.org News, WordPress 7.1.2 Release, 22.09.2026. wordpress.org
  • WordPress Developer Resources, Application Passwords, abgerufen 01.10.2026. developer.wordpress.org