WordPress Application Passwords: Die Schnittstelle, die mit WP 7 immer wichtiger wird aber Wordfence default blockiert

WordPress Application Passwords - Schnittstelle für Automatisierungs-Plattformen

Systeme werden heute immer stärker vernetzt. Das ist kein kurzzeitiger Trend, sondern ein ständig voranschreitender Prozess in einer digitalen Welt, in der einzelne Werkzeuge zunehmend Teil größerer Workflows werden. Wenn ich von Vernetzung im WordPress-Kontext spreche, meine ich nicht das Setzen von mehr Links für SEO, sondern die strukturelle Verbindung von WordPress mit anderen Systemen.

Konkrete Beispiele sind Automatisierungs-Plattformen wie n8n, Zapier, Make oder Pipedream, mobile Apps für die Beitrags-Erstellung, CI/CD-Pipelines wie GitHub Actions, GitLab CI oder Vercel, oder eigene Skripte. In all diesen Fällen muss WordPress externen Werkzeugen Zugriff gewähren, ohne dass jedes Mal ein menschlicher Login mit Benutzername und Hauptpasswort stattfindet.

Genau diese Aufgabe übernehmen die Application Passwords. Wer in seinem Unternehmen oder seiner Agentur einen Workflow aufsetzt, der WordPress mit n8n verbindet, nutzt am Punkt der Authentifizierung praktisch immer ein Application Password. Die offizielle n8n-Dokumentation nennt sie als Standardmethode für selbst-gehostete WordPress-Sites; der von n8n eingebaute OAuth-Connector ist auf WordPress.com beschränkt. Für self-hosted WordPress lässt sich OAuth zwar via Plugins nachrüsten, im Standardfall bleibt aber Basic Auth über Application Passwords der Weg.

Mit WordPress 7 und der neuen KI- und MCP-Schicht (siehe meinen separaten Beitrag dazu) wird das Thema noch wichtiger. KI-Werkzeuge wie Claude Desktop oder ChatGPT mit MCP-Anbindung nutzen dieselbe Authentifizierungs-Methode, um sich an WordPress-Sites anzudocken. Dieselbe Schnittstelle, die bisher schon von externen Tools und Apps genutzt wurde, ist jetzt auch der Andockpunkt für KI-Agenten.

Dieser Beitrag erklärt im Detail, was Application Passwords sind, wo man sie findet, was technisch dahintersteckt und welche Sicherheits-Vorfälle es über die WordPress-Versionen hinweg gab.

Was sind Application Passwords?

Application Passwords sind seit WordPress 5.6 vom 8. Dezember 2020 Teil des Cores. Im deutschen WordPress-Backend heißen sie „Anwendungs-Passwörter". Es sind eigenständige Passwörter, die ein eingeloggter Benutzer für externe Werkzeuge erzeugt, damit diese in seinem Namen mit der WordPress-REST-API kommunizieren können, ohne dass das normale Login-Passwort weitergegeben werden muss.

Beispiel: Du betreibst eine n8n-Instanz, die automatisch Beiträge in deinem WordPress veröffentlichen soll. Statt n8n dein Login-Passwort zu geben (was wäre, als würdest du n8n den Generalschlüssel deiner Website aushändigen), erzeugst du im Profil ein extra Passwort speziell für n8n. Wenn n8n eines Tages kompromittiert wird oder nicht mehr genutzt wird, widerrufst du genau dieses eine Passwort, ohne dass dein Hauptlogin betroffen ist.

Wichtige Eigenschaften:

• Sie sind an einen konkreten Benutzer gebunden und erben dessen volle Berechtigungs-Klasse. Ein Application Password eines Administrators erlaubt alles, was ein Administrator über die REST-API tun kann.
• Sie sind einzeln widerrufbar, ohne dass das Login-Passwort oder andere Application Passwords betroffen sind.
• Sie sind nicht für interaktive Browser-Logins gedacht, sondern funktionieren ausschließlich an der REST-API.
• Sie umgehen 2FA-Plugins in der Regel, weil 2FA am interaktiven Login hängt, nicht an der REST-API-Authentifizierung.
• Sie werden als Hash gespeichert und nach dem einmaligen Anzeigen bei der Erstellung nicht mehr abrufbar.
• Es gibt keine technische Bindung zwischen einem Application Password und einer bestimmten Anwendung. Der Name („n8n", „Mobile App") dient nur der Wiedererkennung im Backend. Technisch lässt sich derselbe Passwort-String beliebig vielen Werkzeugen weitergeben. Die offizielle Empfehlung ist daher klar: ein Application Password pro externer Anwendung, nie eines wiederverwenden.

Wo findet man Application Passwords und wie stellt man sie ein?

Application Passwords sind tief im Admin-Bereich versteckt und für viele Site-Betreiber nicht offensichtlich:

1. Im WordPress-Admin links auf „Benutzer > Profil" klicken
2. Auf der Profil-Seite ganz nach unten scrollen, bis zum Abschnitt „Anwendungs-Passwörter"
3. In das Feld einen sprechenden Namen eintragen, etwa „n8n Blog-Automation" oder „Mobile App iOS Editor"
4. Auf „Neues Anwendungs-Passwort hinzufügen" klicken
5. WordPress generiert ein 24-stelliges Passwort in vier-Zeichen-Blöcken: ABCD 1234 EFGH 5678 IJKL 9012 (die Leerzeichen sind optisch, WordPress entfernt sie bei der Verifikation)
6. Das Passwort wird nur einmal angezeigt. Wer es nicht sofort kopiert, muss ein neues erzeugen
7. Im externen Werkzeug das Passwort zusammen mit dem WordPress-Benutzernamen als API-Credential eintragen

Voraussetzungen, ohne die der Abschnitt nicht erscheint oder nicht funktioniert: WordPress 5.6+, HTTPS auf der Site (außer auf localhost), aktive REST-API (Standard), und keine Sicherheits-Plugins, die das Feature deaktiviert haben.

Wer den Abschnitt vermisst, hat in den allermeisten Fällen ein Sicherheits-Plugin im Einsatz, das Application Passwords standardmäßig deaktiviert. Wordfence schaltet Application Passwords seit Version 7.4.14 vom Dezember 2020 standardmäßig aus, ebenso WebARX/Patchstack, Astra Security und andere. Wer das Feature trotzdem nutzen will, kann es im jeweiligen Sicherheits-Plugin manuell wieder freischalten. Mehr dazu im Kapitel „Sicherheits-Plugins und Application Passwords" weiter unten.

Der Authorize Application Flow

Ein alternativer Vergabe-Weg ist der „Authorize Application"-Flow. Hier leitet eine externe Anwendung den User direkt zu einer URL der Form

https://deine-site.de/wp-admin/authorize-application.php?app_name=n8n&success_url=https://n8n.example.com/callback&reject_url=https://n8n.example.com/reject

weiter. Der User sieht einen Bestätigungs-Dialog mit App-Namen und zwei Buttons. Mit einem Klick auf „Yes, I approve of this connection" wird ein Application Password erzeugt und an die success_url zurückgegeben, in der URL angehängt als Parameter. Dieser Flow ist OAuth-ähnlich gedacht, aber strukturell einfacher. Mehr zu den Sicherheits-Implikationen im Sicherheits-Kapitel.

Was technisch dahintersteckt

Auf der technischen Seite sind Application Passwords schlichter aufgebaut, als viele erwarten.

Speicherung in der Datenbank

Application Passwords werden in der Tabelle wp_usermeta unter dem Meta-Key _application_passwords gespeichert. Pro User existiert dort ein serialisiertes Array mit allen Application Passwords, je Eintrag mit: UUID zur Identifikation, optionaler app_id (vom Authorize-Flow als UUID, sonst leer), Name (Label), gehashtes Passwort, created, last_used (Timestamp letzter Zugriff), last_ip (IP letzter Zugriff).

Wichtig: WordPress trackt nur einen einzigen letzten Zugriff, keine Historie. Wenn ein Passwort durch fünf verschiedene Anwendungen genutzt wird, sieht der Admin nur die zuletzt zugreifende IP.

Hash-Verfahren und der Wechsel mit WordPress 6.8

Bis WordPress 6.7.x wurden Application Passwords mit phpass Portable Hashing gespeichert, dem von Solar Designer (Openwall) entwickelten und seit WordPress 2.5 (März 2008) im Core integrierten Verfahren, das auf MD5 mit Stretching basiert und nach heutigen Maßstäben kryptografisch schwach ist.

Mit WordPress 6.8 „Cecil" vom April 2025 wurde das Hash-Verfahren für Application Passwords (und andere Sicherheits-Tokens) auf BLAKE2b via Sodium (sodium_crypto_generichash()) umgestellt. Neue Hashes beginnen mit dem Präfix $generic$, alte phpass-Hashes mit $P$. Die Umstellung ist nicht retroaktiv: Application Passwords aus der Zeit vor WordPress 6.8 behalten ihren alten phpass-Hash, bis sie widerrufen und neu vergeben werden. Sites mit Application Passwords aus 2020 oder 2021 haben diese also noch im älteren Hashing.

Warum nicht bcrypt wie bei User-Passwörtern? Application Passwords werden mit hoher Entropie durch wp_generate_password() aus einem 62-Zeichen-Alphabet erzeugt, das macht Brute-Force auch ohne den extra langsamen bcrypt-Algorithmus praktisch unmöglich. BLAKE2b ist schneller, was bei vielen API-Anfragen pro Tag wichtig ist.

HTTP Basic Authentication

Die Authentifizierung an der REST-API erfolgt über das simple HTTP Basic Authentication-Verfahren. Das externe Werkzeug sendet:

Authorization: Basic <base64(username:application_password)>

WordPress dekodiert, sucht den User, prüft das Passwort gegen den Hash und gibt bei Erfolg den Zugriff frei. Keine Tokens, keine Sessions, keine Nonces, keine Ablauf-Zeit. Wer das Passwort hat, hat den Zugriff. Daher die strikte HTTPS-Voraussetzung im Core, denn bei unverschlüsselter Übertragung (Man-in-the-Middle) ginge das Passwort direkt mit.

Programmatische Erstellung durch Plugins

Application Passwords lassen sich nicht nur durch User-Interaktion erzeugen. Plugins können sie programmatisch erstellen über:

WP_Application_Passwords::create_new_application_password( $user_id, $args );

Die Methode unterliegt dem Capability-Check current_user_can('create_app_password', $user_id), den ein Plugin mit Admin-Rechten praktisch immer erfüllt. Praktisch heißt das: Jedes Plugin mit Admin-Rechten kann im Namen des eingeloggten Users neue Application Passwords erzeugen, ohne dass der Admin in der Standard-Oberfläche eine Benachrichtigung erhält. Es gibt den Action-Hook wp_create_application_password für Audit-Plugins, aber im Standard-Backend gibt es keine eingebaute Sichtbarkeit.

Der wp_is_application_passwords_available-Filter

Application Passwords lassen sich vollständig abschalten, allerdings nur per Code, nicht per UI-Schalter:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

In einer functions.php oder einem MU-Plugin gesetzt, blendet das den Abschnitt aus und lehnt Auth-Versuche über Application Passwords ab. Genau diesen Filter setzen Wordfence und vergleichbare Lösungen standardmäßig.

Sicherheits-Vorfälle und Geschichte der Application Passwords

Die Geschichte der Application Passwords ist eine Geschichte des kontinuierlichen Nachjustierens. Die wichtigsten Stationen in zeitlicher Reihenfolge:

5. November 2020: Offizieller Integration Guide

Vor dem 5.6-Release wurde am 5. November 2020 der „Application Passwords: Integration Guide" auf Make WordPress Core von George Stephanis veröffentlicht. Er dokumentiert den vollen Authorize-Application-Flow und ist bis heute die maßgebliche Quelle für externe Entwickler.

8. Dezember 2020: Einführung mit WordPress 5.6 und sofortige Wordfence-Warnung

Application Passwords wurden mit WordPress 5.6 am 8. Dezember 2020 eingeführt. Noch am Tag der Veröffentlichung publizierte Wordfence einen Warn-Beitrag mit dem Titel „WordPress 5.6 Introduces a New Risk to Your Site": Der Authorize-Application-Flow sei trivial Social-Engineering-anfällig, ein Angreifer könne den Site-Betreiber zu einem reflexhaften Klick auf „Yes, I approve" verleiten und damit ein Application Password mit voller Berechtigungs-Klasse abgreifen.

In direkter Reaktion deaktivierte Wordfence ab Version 7.4.14 Application Passwords standardmäßig, eine Konfiguration, die bis heute gilt. WebARX und Astra Security folgten. In der offiziellen Wordfence-Dokumentation steht bis heute: „Wordfence recommends keeping this feature disabled unless you have a specific need for it."

Oktober 2023: CVE für Reflected XSS in WP 5.6 bis 6.3.1

Drei Jahre nach der Einführung kam der erste größere Sicherheits-Vorfall im Core selbst. Am 12. Oktober 2023 veröffentlichte WordPress die Maintenance- und Security-Release 6.3.2, mit einem Patch für eine Reflected Cross-Site Scripting (XSS)-Lücke im Authorize-Application-Flow. Die Schwachstelle betraf alle Versionen von 5.6 bis 6.3.1, also fast drei Jahre lang war jede WordPress-Installation potenziell anfällig.

Technisch: Der Flow akzeptiert über GET-Parameter die URLs success_url und reject_url. WordPress sanitisierte diese bis 6.3.1 nicht ausreichend, wodurch Angreifer javascript:-Pseudo-URIs einschleusen konnten. Ein präparierter Link konnte beim Klick auf „Approve" oder „Reject" beliebigen JavaScript-Code im Browser-Kontext des hochprivilegierten WordPress-Users ausführen. CVSS 6.1 (Medium). Entdeckt von Jorge Costa vom WordPress Core Team selbst. Der Patch in 6.3.2 lässt nur noch http: und https: als Schemas zu.

April 2025: Hash-Verfahren-Upgrade in WordPress 6.8 „Cecil"

Mit WordPress 6.8 „Cecil" im April 2025 wurde das Hash-Verfahren für Application Passwords (und andere Sicherheits-Tokens) von dem seit 2008 in WordPress integrierten phpass auf BLAKE2b via Sodium umgestellt. Technische Hintergründe im Kapitel 3 weiter oben. Die initiale Proposal zur Ablösung von phpass war bereits 2012 im Trac-Ticket #50027 erfolgt, John Blackbourn beschrieb den Schritt im Make-WordPress-Core-Beitrag entsprechend als längst überfällig.

Dezember 2025: Separater Vorfall im Original-Plugin (CVE-2025-13308)

Vor der Core-Integration in 5.6 existierte Application Passwords als separates Plugin, das bis heute weiter verfügbar ist (vermutlich für Sites auf älteren WordPress-Versionen). Unter CVE-2025-13308, am 6. Dezember 2025 von Wordfence über das NVD veröffentlicht, wurde im Original-Plugin eine analoge Reflected XSS-Lücke über den reject_url-Parameter dokumentiert, in allen Versionen bis 0.1.3.

Mai 2026: CVE-2026-8181 im Burst Statistics Plugin (CVSS 9.8)

Der bislang schwerwiegendste Application-Password-bezogene Vorfall: Im Burst Statistics Plugin (über 200.000 aktive Installationen) wurde unter CVE-2026-8181 eine Authentication-Bypass-Lücke mit CVSS 9.8 (kritisch) entdeckt. Plugin-Versionen 3.4.0 bis 3.4.1.1 betroffen, öffentlich gemacht am 14. Mai 2026. Wordfence blockierte in den ersten 24 Stunden über 7.400 Exploit-Versuche.

Technische Wurzel: Falscher Umgang mit dem Rückgabewert von wp_authenticate_application_password(). Das Plugin prüfte nur auf WP_Error, ignorierte aber, dass die Funktion unter bestimmten Bedingungen auch null zurückgeben kann (etwa wenn der Aufruf außerhalb des normalen REST-API-Flows erfolgt). Im null-Fall behandelte das Plugin den Request fälschlicherweise als authentifiziert.

Praktisch: Ein unauthentifizierter Angreifer mit Kenntnis eines gültigen Admin-Benutzernamens konnte sich über einen einzigen HTTP-Request mit beliebigem Passwort als dieser Administrator ausgeben und Admin-Funktionen ausführen, einschließlich Erstellung neuer Admin-Accounts. Plugin-Version 3.4.2 vom 12. Mai 2026 fixte den Fehler. Zwei Wochen später waren laut WordPress.org noch etwa 115.000 Sites mit den anfälligen Versionen aktiv.

Der Fall ist instruktiv: Die Schwachstelle lag nicht in WordPress selbst, sondern in der falschen Verwendung der Application-Password-API durch einen Plugin-Entwickler. Wenn die zentrale Authentifizierungs-Funktion von vielen Plugins eingebunden wird, multipliziert sich jede Subtilität in ihrem Verhalten in die Plugin-Welt hinein.

Sicherheits-Plugins und Application Passwords

Eine separate Betrachtung verdient die Rolle der Sicherheits-Plugins, weil sie in der Praxis für viele WordPress-Sites die eigentliche Default-Politik diktieren, nicht der Core. Wer Wordfence, Patchstack oder einen vergleichbaren Anbieter im Einsatz hat, läuft mit hoher Wahrscheinlichkeit auf einer Site, deren Application-Password-Funktion bereits deaktiviert ist, ohne dass der Site-Betreiber das bewusst entschieden hätte.

Die Default-Position der bekanntesten Sicherheits-Plugins

• Wordfence: Standardmäßig deaktiviert seit Version 7.4.14 vom Dezember 2020. Offizielle Empfehlung: „Wordfence recommends keeping this feature disabled unless you have a specific need for it."
• Patchstack (früher WebARX): Option „Block WordPress application password feature" im Hardening-Bereich der Paid-Pläne standardmäßig aktiviert.
• WP Cerber: Eigene UI-Sektion „Application Passwords" unter „User Policies", global oder pro User-Rolle steuerbar. Die Pro-Variante unterscheidet sogar zwischen „nur API-Zugriff" und „komplett deaktiviert".
• WP Security Ninja: Eigener Button „Disable Application Passwords" im Bereich „Security Fixes".
• Advanced Access Manager (AAM): Eigene Custom Capability aam_manage_application_passwords seit Version 7, die auch die programmatische Erstellung blockiert, nicht nur UI- und REST-API-Pfade.
• Astra Security: Standard-Deaktivierung im Standardprofil.
• Disable Application Passwords (Jeff Starr): Standalone-Plugin auf WordPress.org für die schnelle Deaktivierung ohne Code.

Die wichtigsten WordPress-Sicherheits-Lösungen sind sich seit fünf Jahren einig: Application Passwords gehören im Default-Zustand abgeschaltet.

Zwei Ebenen der Absicherung: Filter und WAF

Sicherheits-Plugins arbeiten in der Regel auf zwei Ebenen parallel. Die erste ist der Core-Filter wp_is_application_passwords_available: Auf false gesetzt, blendet WordPress den Profil-Abschnitt aus und lehnt REST-API-Auth-Versuche ab. Die zweite ist die Web Application Firewall (WAF). Auch wenn die Setting-Ebene irgendwann doch aktiviert wird (etwa für n8n), kann die WAF die konkreten HTTP-Requests an der API-Schicht selbst blockieren.

Das führt in der Praxis manchmal dazu, dass User auch nach offiziellem Freischalten der Setting noch die Meldung „Application passwords have been disabled" sehen, weil die WAF einen zusätzlichen Schutz-Layer bildet. Wer Application Passwords aktiv nutzen will, muss unter Umständen zusätzlich Whitelist-Regeln in der WAF setzen oder die Firewall temporär in einen Lern-Modus versetzen.

Sperren auch ohne Sicherheits-Plugin

Wer kein vollständiges Sicherheits-Plugin nutzen will und nur Application Passwords loswerden möchte:

• Den wp_is_application_passwords_available-Filter in einem MU-Plugin oder in der functions.php setzen (eine Code-Zeile).
• Das standalone Plugin „Disable Application Passwords" von Jeff Starr installieren (aktivieren reicht, keine Einstellungen nötig).

Eine offiziell von WordPress Core bereitgestellte Konstante wie WP_DISABLE_APPLICATION_PASSWORDS in der wp-config.php existiert nicht. Die AAM-Entwickler fassten das ehrlich zusammen: „Surprisingly, WordPress core doesn't offer a straightforward way to disable application passwords." Der Filter ist der einzige offizielle Weg.

Wo der Schutz anfängt und wo er aufhört

Die Standard-Deaktivierung durch Sicherheits-Plugins schützt vor:

• versehentlicher Vergabe eines Application Passwords durch nicht-technische User
• Social-Engineering über den Authorize-Application-Flow (durch den Filter mit deaktiviert)
• Brute-Force-Angriffen auf den REST-API-Auth-Endpunkt mit geratenen Application Passwords
• der Nutzung von Application Passwords als Auth-Vehikel für externe MCP-Clients oder andere KI-Werkzeuge an der WordPress-7-Inbound-Schicht

Was der Schutz nicht abdeckt:

• Andere REST-API-Auth-Methoden wie JWT (via Plugins wie „JWT Authentication for WP REST APIs") oder OAuth. Diese laufen über eigene Auth-Pfade und sind vom Filter strukturell nicht erfasst.
• Cookie-basierte Authentifizierung für same-origin-Anfragen aus dem eingeloggten Browser-Kontext.
• Authentifizierungs-Bypass-Lücken in Plugins, wie der Burst-Statistics-Fall vom Mai 2026 gezeigt hat. Wenn ein Plugin die Auth-API falsch verwendet, hilft die Default-Deaktivierung nicht weiter, weil die Auth gar nicht stattfindet, nur fälschlich als erfolgreich gewertet wird.
• Programmatische Erstellung durch Plugins mit Admin-Rechten. WP_Application_Passwords::create_new_application_password() prüft den Filter nicht direkt im Quellcode. Hier setzt AAM mit der aam_manage_application_passwords-Capability einen zusätzlichen Schutz.

Der Standard-Schutz ist also eine wirksame, aber nicht vollständige Absicherung gegen die häufigsten Angriffs-Szenarien. Für tiefergehende Anforderungen reicht ggf. eine Default-Deaktivierung nicht aus.

Fazit

Application Passwords sind eine unterschätzte WordPress-Funktion. Viele Site-Betreiber kennen den Begriff nicht. Das wird sich aus zwei Gründen ändern.

Erstens, mit WordPress 7 und der neuen KI- und MCP-Schicht wird die Funktion von einer Nische zur Standard-Schnittstelle, die jeder Site-Betreiber irgendwann anfasst. KI-Werkzeuge wie Claude Desktop oder ChatGPT mit MCP-Anbindung nutzen Application Passwords als Auth-Weg.

Zweitens, durch den wachsenden Druck auf Agenturen und Plattformen, mehr Automation und KI-Anbindung anzubieten, werden Application Passwords zunehmend von Workflow-Tools eingesetzt. Was bisher als Spezial-Workflow galt, wird zur Standard-Erwartung.

Aber: Man sollte sich immer fragen, ob man wirklich alles vernetzen muss. Mit jedem zusätzlichen Schnittpunkt vergrößert sich Komplexität und Angriffsfläche. Application Passwords sind technisch solide, aber sie öffnen einen Weg, der vorher nicht existierte. Ist dieser Weg offen, hängt die Sicherheit der Site nicht mehr nur am Login und 2FA, sondern auch an der Sicherheit jedes externen Werkzeugs, das ein Application Password kennt.

Quellen und weiterführende Links

Offizielle WordPress-Dokumentation

• Application Passwords: Integration Guide (Make WordPress Core, 5. November 2020). Offizielle Architektur-Beschreibung und Authorize-Flow-Dokumentation. make.wordpress.org/core/2020/11/05/application-passwords-integration-guide
• Application Passwords (WordPress Advanced Administration Handbook, Januar 2026). Offizielle Admin-Dokumentation mit Übersicht zu Funktionalität, Voraussetzungen und Troubleshooting. developer.wordpress.org/advanced-administration/security/application-passwords
• WP_Application_Passwords::create_new_application_password() (WordPress Developer Reference). Offizielle Core-Methode für die programmatische Erstellung. Enthält den Versions-Hinweis zur Hash-Umstellung in WP 6.8. developer.wordpress.org/reference/classes/wp_application_passwords/create_new_application_password
• WordPress 6.8 will use bcrypt for password hashing (Make WordPress Core, 17. Februar 2025). Offizielle Ankündigung des Hash-Umstiegs von phpass auf bcrypt für User-Passwörter und BLAKE2b für Application Passwords. make.wordpress.org/core/2025/02/17/wordpress-6-8-will-use-bcrypt-for-password-hashing

Sicherheits-Vorfälle und CVEs

• WordPress 5.6 Introduces a New Risk to Your Site: What to Do (Wordfence, 8. Dezember 2020). Warnung zur Social-Engineering-Anfälligkeit des Authorize-Flows direkt am Tag der WP-5.6-Veröffentlichung. Begründung für die Standard-Deaktivierung in Wordfence 7.4.14. wordfence.com/blog/2020/12/wordpress-5-6-introduces-a-new-risk-to-your-site-what-to-do
• WordPress 6.3.2 Security Release: What You Need to Know (Wordfence, Oktober 2023). Beschreibung der Reflected-XSS-Lücke in reject_url der Application-Password-Anfragen. wordfence.com/blog/2023/10/wordpress-6-3-2-security-release-what-you-need-to-know
• WordPress 6.3.2 Security Update Technical Advisory (Patchstack). Technische Details der XSS-Schwachstelle und des Patches. patchstack.com/articles/wordpress-core-6-3-2-security-update-technical-advisory
• CVE-2026-8181: Burst Statistics Auth Bypass to Admin Takeover (Hurayra IT, Mai 2026). Detaillierte technische Analyse der kritischen Authentication-Bypass-Lücke im Burst Statistics Plugin. hurayraiit.com/blog/cve-2026-8181-burst-statistics-auth-bypass-admin-takeover
• Hackers exploit auth bypass flaw in Burst Statistics WordPress plugin (BleepingComputer, Mai 2026). Berichterstattung zum Vorfall mit Wordfence-Statistiken zu blockierten Angriffen. bleepingcomputer.com/news/security/hackers-exploit-auth-bypass-flaw-in-burst-statistics-wordpress-plugin
• CVE-2025-13308: Application Passwords Plugin Reflected XSS (NVD, 6. Dezember 2025). Reflected XSS im Original Application Passwords Plugin via reject_url-Parameter. nvd.nist.gov/vuln/detail/CVE-2025-13308

Tool-Integration mit Application Passwords

• WordPress credentials (n8n Documentation). Offizielle n8n-Doku zur WordPress-Anbindung über Application Passwords. docs.n8n.io/integrations/builtin/credentials/wordpress
• WordPress Application Passwords Complete n8n Setup Guide 2026 (NextGrowth, Mai 2026). Praxis-Guide mit drei Konfigurations-Methoden, Troubleshooting und Security-Hardening. nextgrowth.ai/wordpress-application-passwords-setup-guide
• How to Automate WordPress with n8n Workflows (Contabo Blog, Februar 2026). Schritt-für-Schritt-Anleitung mit Fokus auf Application Passwords als Authentifizierungs-Methode. contabo.com/blog/how-to-automate-wordpress-with-n8n-workflows
• How to Integrate WordPress with n8n (Hostinger Tutorials, Januar 2026). Application-Password-Erstellung mit konkreten n8n-Anwendungsfällen. hostinger.com/tutorials/how-to-integrate-n8n-with-wordpress
• What Are Application Passwords in WordPress? (GreenGeeks Glossary). Übersicht zu typischen Anwendungsfällen mit Zapier, mobile Apps, CRM-Systemen. greengeeks.com/glossary/application-password

Sicherheits-Plugins und Standard-Deaktivierung

• Wordfence Brute Force Protection Documentation. Begründung für die Standard-Deaktivierung von Application Passwords und Anleitung zur Re-Aktivierung. wordfence.com/help/firewall/brute-force
• Patchstack General Hardening Settings. „Block WordPress application password feature" als Default-Hardening-Setting der Paid-Pläne. docs.patchstack.com/patchstack-app/site-dashboard/hardening/app-hardening-general
• WP Cerber: Managing WordPress Application Passwords. Granulare Konfiguration per User-Rolle, „Application Passwords"-Sektion unter „User Policies". wpcerber.com/wordpress-application-passwords-how-to
• AAM Portal: There Is Something Wrong With WordPress Application Passwords. Kritische Einordnung der Core-Position und Vorstellung der aam_manage_application_passwords -Capability für vollständige Sperrung inklusive programmatischer Erstellung. aamportal.com/blog/there-is-something-wrong-about-wordpress-application-password
• Disable Application Passwords Plugin (WordPress.org). Standalone-Plugin zur Deaktivierung des Features. wordpress.org/plugins/disable-application-passwords
• How to Disable Application Passwords Feature in WordPress 5.6 (GretaThemes, Dezember 2020). Code-Snippet mit wp_is_application_passwords_available -Filter. gretathemes.com/wordpress-disable-application-passwords

Hash-Verfahren und WP 6.8

• How WordPress 6.8 Will Strengthen Password Security and Hashing (Pressidium, März 2025). Hintergrund zum Umstieg von phpass auf bcrypt und BLAKE2b. pressidium.com/blog/wordpress-password-security-hashing
• bcrypt and BLAKE2b: A New Password Hashing Algorithm in WordPress 6.8 (wp-kama, Januar 2026). Technische Erklärung der beiden Algorithmen und ihrer Anwendung in WordPress 6.8. wp-kama.com/2907/bcrypt-and-blake2b-a-new-password-hashing-algorithm-in-wordpress-6-8
• Trac-Ticket #50027: Retire Phpass and use PHP native password hashing (eröffnet 20. Juni 2012). Die initiale Proposal zur Ablösung von phpass, die mit WP 6.8 von 2025 nach 13 Jahren umgesetzt wurde. core.trac.wordpress.org/ticket/50027
• Trac-Ticket #63203: Application Passwords BC Break in 6.8's new hashing. Diskussion zur Backward-Compatibility-Frage bei der Hash-Umstellung. core.trac.wordpress.org/ticket/63203

Einordnung im WordPress-Ökosystem

• Andreas Schmidt Arts: WordPress 7 kann nun KI (Mai 2026). Mein vorausgegangener Beitrag zur WordPress-7-KI-Schicht, in dem die Bedeutung von Application Passwords als Authentifizierungs-Schicht für die neue Inbound-MCP-Architektur eingeführt wird. https://www.andreas-schmidt-arts.de/post/wordpress-7-kann-nun-ki-neue-funktionen-und-kritik-zum-groessten-update-seit-jahren/