WordPress: Die häufigsten Einfallstore

Veröffentlicht am 28.07.2026 · Sicherheit

WordPress hat einen schlechten Ruf in Sicherheitsfragen, der dem Kern nur selten gerecht wird. Der Kern wird zügig gepflegt und aktualisiert sich seit Jahren selbst. Die Angriffe zielen fast immer auf etwas anderes: auf die Erweiterungen, auf die Zugänge und auf das, was im Dateisystem liegen bleibt.

Nicht der Kern — die Erweiterungen

Eine typische Installation trägt ein Theme und ein bis zwei Dutzend Plugins. Jedes davon ist fremder Code mit vollem Zugriff auf die Datenbank und das Dateisystem. Wird in einem Plugin eine Schwachstelle veröffentlicht, ist sie ab diesem Moment öffentlich bekannt — samt Angriffsweg und der Möglichkeit, verwundbare Installationen automatisiert im Netz zu suchen. Zwischen Veröffentlichung und den ersten breit gestreuten Angriffsversuchen liegen häufig nur Tage.

Das erklärt, warum Aktualisierungen der entscheidende Punkt sind — und warum ein Plugin, das nur „irgendwann" aktualisiert wird, das Risiko trägt, nicht der Kern.

Verwaiste Plugins: der stille Fall

Gefährlicher als ein veraltetes Plugin ist ein aufgegebenes. Wird ein Plugin nicht mehr gepflegt, bekommt es auch dann kein Update, wenn eine Lücke bekannt wird. Im WordPress-Verzeichnis erkennen Sie solche Kandidaten an mehreren Hinweisen: Das letzte Update liegt lange zurück, die Angabe zur getesteten WordPress-Version hinkt mehrere Hauptversionen hinterher, Support-Anfragen bleiben unbeantwortet. Manche Plugins werden auch aus dem Verzeichnis entfernt — auf Ihrer Installation bleiben sie dann einfach liegen und melden nichts.

Ein zweiter Fall ist der Eigentümerwechsel: Ein gepflegtes Plugin mit großer Verbreitung wird verkauft, und die neuen Betreiber ergänzen Werbeeinblendungen, Nachverfolgung oder Schlimmeres. Von außen ist das zunächst nicht zu sehen.

Ebenfalls unterschätzt: deaktivierte Plugins. Ihr Code liegt weiterhin im Dateisystem und ist unter bestimmten Umständen direkt aufrufbar. Deaktivieren ist kein Entfernen — löschen Sie, was Sie nicht brauchen.

PHP-Dateien im Uploads-Ordner

Wenn ein Angriff erfolgreich war, hinterlässt er in aller Regel eine Hintertür, damit der Zugang auch nach einem Update erhalten bleibt. Der klassische Ablageort dafür ist wp-content/uploads/. Das hat einen einfachen Grund: Dieses Verzeichnis muss beschreibbar sein, es wird selten angesehen, und seine Inhalte sind öffentlich abrufbar.

Dort gehören Bilder, PDFs und Dokumente hin — keine PHP-Dateien. Eine einzige .php-Datei in einem Unterordner von uploads/ ist ein ernstzunehmender Befund, unabhängig davon, wie unauffällig sie heißt. Zwei Maßnahmen helfen: die Ausführung von PHP in diesem Verzeichnis auf Serverebene unterbinden und den Bestand regelmäßig darauf prüfen.

Wer bei Ihnen mitschreiben darf

Anmeldedaten sind der zweite große Weg hinein. WordPress erleichtert es Angreifern an einer Stelle unnötig: Über die Autorenarchive und über die REST-Schnittstelle lassen sich häufig die vorhandenen Benutzernamen auslesen. Damit ist die Hälfte der Zugangsdaten bereits bekannt, und der Rest wird durchprobiert — auch mit Kennwörtern aus früheren Datenlecks.

Das Standard-Tabellenpräfix wp_ gehört in dieselbe Kategorie: Es ist keine Sicherheitslücke, aber es macht Angriffe über SQL-Einschleusung einfacher, weil die Tabellennamen dann nicht erraten werden müssen. Bei einer neuen Installation kostet ein eigenes Präfix nichts; bei einer bestehenden ist die nachträgliche Änderung heikel und selten die lohnendste Maßnahme.

Was tatsächlich hilft

1. Aktualisieren, zeitnah und nachweislich. Automatische Updates für den Kern und für Plugins, denen Sie vertrauen; für die übrigen ein fester Termin. Entscheidend ist, dass jemand zuständig ist.
2. Weniger Plugins. Jede Erweiterung, die Sie nicht installieren, muss nicht gepflegt werden. Prüfen Sie vor der Installation: letztes Update, Zahl der aktiven Installationen, Umgang des Herstellers mit gemeldeten Lücken.
3. Zwei-Faktor-Anmeldung für alle Redaktionskonten. Sie entwertet gestohlene und erratene Kennwörter in einem Schritt und ist die wirksamste Einzelmaßnahme.
4. Rechte sparsam vergeben. Nicht jeder braucht Administratorrechte. Der eingebaute Dateieditor sollte abgeschaltet sein — er verwandelt ein übernommenes Konto sonst unmittelbar in Codeausführung auf dem Server.
5. Dateiintegrität prüfen. Die Kerndateien lassen sich gegen die offiziellen Prüfsummen von WordPress.org abgleichen. Jede Abweichung und jede PHP-Datei in uploads/ ist ein Anhaltspunkt, dem Sie nachgehen sollten.
6. Fehlersuchmodus aus, Versionsangaben sparsam. Debug-Ausgaben im Produktivbetrieb verraten Pfade und Konfiguration.
7. Getestete Backups. Eine Sicherung, aus der noch nie jemand zurückgesichert hat, ist eine Annahme, keine Sicherung.

Von außen sieht man das nicht

Der entscheidende Punkt zum Schluss: Welche Erweiterung in welcher Version bei Ihnen liegt, verrät eine Website nach außen meist nicht. Eine reine Außenprüfung kann deshalb nicht sagen, ob Sie eine bekannte Schwachstelle mitführen. Genau dafür gibt es den Tutador-Konnektor — ein Plugin, das die installierten Versionen meldet, damit wir sie täglich gegen veröffentlichte Schwachstellen abgleichen und die Kerndateien vergleichen können. Der Abgleich der Dateien läuft dabei auf Ihrem Server; Dateiinhalte verlassen ihn nicht.

Von den 22 Kriterien unseres Katalogs kommen 18 ohne diesen Blick nach innen aus. Für die Erweiterungen selbst gilt das nicht.