Application Passwords: die Hintertür, die 2FA aushebelt

Veröffentlicht: 06.09.2026 · Letzte Aktualisierung: 06.09.2026

Ein Kunde stellt nach einem Vorfall alle Passwörter um, aktiviert Zwei-Faktor-Authentifizierung für jedes Konto und hält die Site für abgesichert. Drei Wochen später tauchen wieder fremde Inhalte auf. Der Angreifer hatte sich in der Zeit seines Zugriffs ein Application Password angelegt. Das übersteht den Passwort-Reset, und der zweite Faktor greift bei dieser Zugangsart nicht.

Dieses Szenario ist kein Einzelfall, sondern die logische Folge einer Core-Funktion, die kaum jemand auf dem Radar hat.

Was sind Application Passwords?

Application Passwords sind Zusatzpasswörter, die WordPress seit Version 5.6 (Dezember 2020) für jedes Benutzerkonto anbietet. Sie sind 24 Zeichen lang, bestehen aus Buchstaben und Ziffern und werden im Benutzerprofil erzeugt. Gedacht sind sie für Programme, die sich ohne Browser an der Site anmelden müssen: eine App, die per REST-API Beiträge veröffentlicht, ein Backup-Dienst, ein Deployment-Skript, ein Newsletter-Tool.

Auf HTTPS-Sites ist die Funktion standardmäßig aktiv. Sie haben sie nie eingeschaltet, sie ist einfach da. Jeder Benutzer kann sich in seinem Profil unter Benutzer, Profil, Anwendungspasswörter beliebig viele davon anlegen. WordPress speichert zu jedem Eintrag den Namen, das Erstellungsdatum, den Zeitpunkt der letzten Nutzung und die IP-Adresse, von der aus zuletzt zugegriffen wurde.

Warum umgehen Application Passwords die Zwei-Faktor-Authentifizierung?

Application Passwords umgehen den zweiten Faktor nicht durch eine Lücke, sondern per Design. 2FA-Plugins hängen sich in den interaktiven Login: Formular ausfüllen, Code eingeben, Sitzung erhalten. Ein Programm kann aber keinen Code aus einer Authenticator-App abtippen. Genau dafür wurden Application Passwords geschaffen: ein Anmeldeweg für Maschinen, der ohne den zweiten Schritt auskommt.

Die Konsequenz: Wer ein gültiges Application Password eines Admin-Kontos besitzt, hat vollen API-Zugriff auf die Site. Beiträge ändern, Benutzer anlegen, Plugins steuern, je nach Rolle des Kontos. Der zweite Faktor, das Login-Limit und die Login-Benachrichtigung Ihres Sicherheits-Plugins bekommen davon nichts mit, weil nie ein Login-Formular durchlaufen wird.

Das Incident-Szenario: der Reset, der nichts zurücksetzt

Nach einem Einbruch lautet der Standard-Ratschlag: alle Passwörter ändern. Das ist richtig und reicht nicht. Ein Application Password ist ein eigenes Geheimnis, unabhängig vom Kontopasswort. Es bleibt gültig, bis es einzeln widerrufen wird.

Für einen Angreifer mit temporärem Admin-Zugriff ist das Anlegen eines Application Passwords deshalb der naheliegendste Weg, sich den Zugang zu erhalten: 30 Sekunden Aufwand, kein Datei-Upload, kein Schadcode, den ein Scanner finden könnte. Nur ein unauffälliger Eintrag im Benutzerprofil, oft mit einem harmlosen Namen wie „Backup“ oder „Jetpack“.

Deshalb gehört zu jeder Aufräumaktion nach einem Vorfall zwingend: alle Application Passwords aller Konten sichten und im Zweifel komplett widerrufen. Wer diesen Schritt auslässt, hat die Hintertür offen gelassen. Was im Akutfall sonst noch zu tun ist, steht in unserem Leitfaden WordPress gehackt.

Wie prüfen Sie Ihre Application Passwords?

Die Prüfung geht manuell, Konto für Konto:

1. Im WordPress-Admin unter Benutzer die Liste aller Konten öffnen.
2. Jedes Konto mit Admin- oder Redakteursrechten einzeln aufrufen und zum Abschnitt Anwendungspasswörter scrollen.
3. Für jeden Eintrag drei Fragen beantworten: Kenne ich die Anwendung? Wann wurde der Eintrag zuletzt benutzt? Passt die letzte IP-Adresse zu dieser Anwendung?

Bei 3 Konten ist das machbar. Bei 15 Konten auf 20 Kunden-Sites nicht mehr. Unser kostenloses Plugin Security Check Report nimmt Ihnen das Durchklicken ab: Es listet in einem Report alle Application Passwords aller Konten auf, mit Erstellungsdatum, letzter Nutzung und letzter IP. Das Plugin liest nur, es ändert nichts, und es ist keine Firewall und kein Malware-Scanner. Widerrufen müssen Sie selbst, aber Sie sehen auf einen Blick, wo Sie ansetzen müssen.

Worauf es bei der Bewertung ankommt: Ein Application Password, das ein Admin-Konto vor 2 Jahren angelegt hat und das seitdem nie benutzt wurde, ist der eigentliche Befund. Entweder ist es ein vergessener Rest, dann gehört es gelöscht. Oder niemand im Team kennt es, dann ist es ein Fall für die Vorfallsanalyse. Harmlos ist es in keinem der beiden Fälle.

Handlungsanleitung: aufräumen und absichern

Schritt 1: Inventur. Alle Application Passwords aller Konten erfassen, manuell oder per Report.

Schritt 2: Ungenutzte widerrufen. Jeder Eintrag ohne bekannten Zweck und jeder Eintrag ohne Nutzung in den letzten 90 Tagen wird gelöscht. Der Button Widerrufen steht direkt neben jedem Eintrag im Profil. Bricht danach eine Integration, war der Eintrag doch in Gebrauch, dann legen Sie ihn bewusst neu an und dokumentieren den Zweck.

Schritt 3: Funktion deaktivieren, wenn Sie sie nicht brauchen. Nutzt keine Ihrer Integrationen Application Passwords, schalten Sie die Funktion komplett ab. Eine Zeile im Child-Theme (functions.php) oder in einem kleinen Plugin genügt:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Danach verschwindet der Abschnitt aus allen Benutzerprofilen und WordPress akzeptiert keine Application Passwords mehr, auch keine bereits bestehenden. Wer es feiner steuern will, nutzt den Filter wp_is_application_passwords_available_for_user und erlaubt die Funktion nur für ein einzelnes technisches Konto. Beide Filter sind in der offiziellen WordPress-Entwicklerdokumentation beschrieben.

Schritt 4: Wiedervorlage. Die Prüfung gehört in jeden Wartungsrhythmus, mindestens quartalsweise. Application Passwords entstehen laufend neu, jede Plugin-Integration kann eines anlegen lassen. Wie Sie den Rest Ihrer Konfiguration systematisch prüfen, steht auf unserer Übersichtsseite WordPress-Sicherheit.

Häufige Fragen

Sind Application Passwords grundsätzlich unsicher?

Nein. Sie sind mit 24 Zeichen kryptografisch stark und lassen sich einzeln widerrufen, was besser ist, als das Hauptpasswort in ein Skript zu schreiben. Das Risiko entsteht durch fehlende Übersicht: Einträge, die niemand kennt, niemand nutzt und niemand je prüft. Genau deshalb ist das Inventar wichtiger als die Frage, ob die Funktion an oder aus ist.

Reicht es nach einem Hack, alle Passwörter zu ändern?

Nein. Application Passwords sind eigene Geheimnisse und bleiben beim Passwort-Reset gültig. Zusätzlich müssen Sie alle Application Passwords aller Konten widerrufen, aktive Sitzungen beenden und unbekannte Benutzerkonten entfernen. Sonst behält der Angreifer einen API-Zugang, den Ihr 2FA-Plugin nicht sieht.

Kann ich Application Passwords komplett abschalten?

Ja, mit einer Zeile Code: add_filter( 'wp_is_application_passwords_available', '__return_false' ); in der functions.php Ihres Child-Themes. Danach funktionieren auch bestehende Einträge nicht mehr. Prüfen Sie vorher, ob Backup-Dienste, Apps oder Deployment-Skripte diese Anmeldung nutzen, sonst brechen diese Integrationen.

Woran erkenne ich ein verdächtiges Application Password?

An drei Merkmalen: Es wurde nie oder seit Monaten nicht benutzt, niemand im Team kann den Zweck benennen, oder die letzte Zugriffs-IP passt nicht zur angeblichen Anwendung. Ein Eintrag namens „Backup“ mit letzter Nutzung von einer unbekannten Auslands-IP ist ein Alarmsignal, kein Schönheitsfehler.

Prüft das Security Check Report Plugin das automatisch?

Das kostenlose Plugin Security Check Report listet alle Application Passwords aller Konten mit Erstellungsdatum, letzter Nutzung und letzter IP in einem Report auf. Es bewertet nicht, ob ein einzelner Eintrag legitim ist, das können nur Sie. Es macht die Einträge sichtbar, die sonst in 15 einzelnen Benutzerprofilen versteckt wären.

Wenn Sie die Prüfung nicht selbst übernehmen wollen: In unserer WordPress-Wartung gehört das Konten- und Zugangs-Audit zum festen Ablauf.