Auch meine Webseite wurde gehackt

Zitat von GMBauer

Backup und Restore erfolgen sehr zuverlässig mit Updraft Plus.

Sind deine Backup's eventuell schon verseucht?

Siehe auch https://wordpress.org/documentation/…ite-was-hacked/

Wenn das bei dir regelmäßig passiert das deine Webseite immer wieder kompromittiert wird, existiert die Lücke weiterhin. Da musst du genauer nachsehen woher das kommt und nicht nur die DB und die Dateien "plattmachen". (Was grundsätzlich eher suboptimal ist. Vorher via FTP deine komplette WP-Installation sowie die Datenbank runterladen und dort genauer nachsehen.)

Du sprichst irgendwie nur von den Plugins - wie sieht es mit dem eingesetzten Theme und WordPress selbst aus? Sind die aktuell? Insbesondere WordPress hatte mit wp2shell eine Sicherheitslücke am 17. Juli geschlossen, die seither extrem ausgenutzt wird.

Zitat

Wäre die automatische Aktualisierung aller Plugins besser?

Muss man immer individuell entscheiden. In deinem Fall, wo es reine Inhaltswebs sind und keine Shops, könnte ich mir automatische Aktualisierungen durchaus vorstellen. Da ist ja nichts geschäftskritischen drauf - das kritische ist eher, wenn sie gehackt werden.

Zitat

Welche Plugins gibt es, die mir hier helfen könnten? (Zugang "verriegeln" um BruteForce abzublocken?)

Sicherheitsplugins. Siehe: https://de.wordpress.org/plugins/tags/security/ - und nein, ich empfehlen von denen keines, da alles inzwischen ihre Arbeit gleichermaßen gut machen. Der Unterschied ist eher in der Bedienung zu sehen und ob man selbst damit klar kommt.

Zitat

Was ist die maximale Länge für Passwörter? (Alle Passwörter liegen bei mir in einzelnen Textdateien, die widerum in einer VeraCrypt-Datei liegen. Die mache ich nur bei Bedarf auf.)

Darüber würde ich mir ehrlich gesagt weniger Gedanken machen. Eines der o.g. Sicherheitsplugins kann dir das Handling der Passwörter in WordPress abnehmen.

Was ich auch noch empfehlen würde: ändere alle Passwörter im Hosting selbst. Nicht nur vom FTP sondern auch vom Hostingzugang. Ändere auch alle sonstigen Passwörter die du selbst in der Hand hast.

Zitat von GMBauer

Gibts denn irgendeine Lücke, die macht, dass ein externer sich anmelden kann?

sql injection über eine Kontaktform deren Eingabefelder nicht validiert werden.

Zitat von GMBauer

Gibts denn irgendeine Lücke, die macht, dass ein externer sich anmelden kann?

Wenn es sie gäbe und jedem bekannt wäre, würde die Software gar nicht mehr genutzt werden.

Wenn du eine Lücke irgendwo vermutest, dann muss diese in von dir verwendeten Plugins oder Themes bestehen. Leider wissen wir hier nicht, welche Plugins und Themes du verwendest. Eine Empfehlung wäre jedes Plugin wie auch das Theme einzeln zu prüfen

a) ob du dessen aktuellste Version ist und wenn nicht, diese zu aktualisieren
b) ob das Plugin ggfs. gar nicht mehr vom Entwickler gepflegt wird. Ein lange Zeit nicht aktualisiertes Plugin oder Theme kann (muss aber nicht) Probleme verursachen.

Schau dir auch an, ob es in den Projekten individuelle Programmierungen gibt. Die o.g. SQL-Injektion wäre bei so etwas oft (nicht immer) sehr einfach möglich. Auch hier müsstest du schauen, ob das auf alle Projekte zutrifft. Achtung: solche individuellen Programmierungen können an verschiedenen Stellen zu finden sein: als individuelles Plugin, in der functions.php eines Child-Themes oder in einem Code-Snippet Plugin. Auch ein Must-Use-Plugin wäre dafür nutzbar.

Möglicherweise kannst du die Liste, die es zu Prüfen gilt, etwas einschränken, wenn du Gemeinsamkeiten zwischen den 15 Projekten herausfindest. Aber Vorsicht: das kann auch trügen. Denn es könnten auch mehrere unterschiedliche Plugins sein, die bei den Projekten für die Probleme zuständig sind.

Abseits von WordPress und auch wenn es Projekte in verschiedenen Hostings betrifft, würde ich auch schauen, ob ggfs. jeweils die Datenbank des Hosters öffentlich erreichbar ist. Das dürfte sie heute niemals sein, aber eine Prüfung ist es Wert.

Dass bei dir alle paar Wochen neue Admins auftauchen und du ausgesperrt wirst, liegt schlicht daran, dass du die Ursache nicht beseitigst. Du spielst per Updraft das Backup ein, aber der Schadcode war zum Zeitpunkt der Sicherung wahrscheinlich längst auf dem Server. Du spielst dir die Hintertür also immer wieder selbst ein. Dazu kommt, dass ein paar Tage Wartezeit bei Plugin Updates den Bots völlig ausreichen, da bekannte Lücken binnen Stunden automatisiert abgeklopft werden.

Um die Kiste jetzt nachhaltig sauber zu bekommen, musst du als Erstes per FTP in den Ordner /wp-content/uploads/ schauen und dort rigoros jede php Datei löschen, denn dort gehören absolut keine Skripte rein. Danach solltest du nicht einfach nur Dateien überschreiben, sondern die Ordner wp-admin, wp-includes sowie deine Plugins komplett löschen und jungfräulich von WordPress neu hochladen. Hol dir anschließend neue Sicherheitsschlüssel für deine Config, um alle möglicherweise gekaperten Session Cookies zu killen. Solltest du Plugins von einem kleineren Entwickler verwenden, wo der Code vor php8 existiert hat bzw. wo 1 - 4x im Jahr Updates angeboten werden, geh den gesamten Code vor der Installation durch. Die sind inhaltlich häufig nicht auf maximale Sicherheit getrimmt.

Ein Kunde von uns hat exakt dasselbe Verhalten gemeldet. Es scheint aktuell eine ungepatchte Sicherheitslücke in einem bestimmten Plugin oder Theme zu geben, die gezielt ausgenutzt wird.

Prüfe am besten mal, welche Plugins und Themes auf allen betroffenen Installationen gemeinsam im Einsatz sind.

Wenn du die Liste hier postest, können wir gemeinsam einen Blick darauf werfen und Muster erkennen.

One thing that stands out to me is that the problem affects installations on different hosting providers, with different FTP credentials and different databases. That seems to make a compromise of a single hosting account less likely.

If all affected sites share the same theme (Impreza) or a common set of plugins, I would start there. A comparison of all 15 installations might reveal the common denominator much faster than analyzing each site individually.

It would also be interesting to know whether the unauthorized administrator account always has the same username pattern and whether the creation time matches any requests in the web server access logs.

Edit Peter

"Was mir besonders auffällt, ist, dass das Problem Installationen bei verschiedenen Hosting-Anbietern mit unterschiedlichen FTP-Zugangsdaten und verschiedenen Datenbanken betrifft. Das scheint einen Kompromiss mit einem einzigen Hosting-Konto unwahrscheinlicher zu machen.
Wenn alle betroffenen Seiten dasselbe Theme (Impreza) oder einen gemeinsamen Plugin-Satz teilen, würde ich dort anfangen. Ein Vergleich aller 15 Installationen könnte den gemeinsamen Nenner viel schneller aufzeigen, als jede einzelne Stätte einzeln zu analysieren.
Es wäre auch interessant zu wissen, ob das unautorisierte Administratorkonto immer dasselbe Benutzernamensmuster hat und ob die Erstellungszeit mit Anfragen in den Webserver-Zugriffsprotokollen übereinstimmt."

Also wenn es 15 Seiten auf mehreren Hostings mit verschiedenem FTP und individuellen PW sind, könnten auch noch folgende Möglichkeiten des Zugriffs bestehen. Ich habe mal KI gebeten, die möglichen Zugriffsmöglichkeiten für diese sehr spezielle Form des Hackings zu listen. (s. u.)

Was das Reparieren betrifft: Wie bereits erwähnt, ist das ein ziemlich lästiger Prozess. Du hast vermutlich irgendwo (auch in den Backups) ein Script sitzen, das immer wieder startet, auch wenn du es kurz mal deaktivieren kannst. Daher musst du wirklich einen sehr genauen Prozess durchführen, Grob gesagt: Alles ausser den Ordener Uploads komplett ersetzen und aus verlässlichen Quellen neu installieren. (WP-Core, Plugins, Themes...) Den Uploadordner nach Dateien untersuchen, die dort nicht sein dürfen, die Datenbank nach Malcode durchsuchen. Alle Passwörter ändern. (FTP, DB, Login etc.) Das wird bei 15 Seiten wahrscheinlich ziemlich aufwändig.

Hier potentielle Orte, über die die infektion auch passieren könnte (laut Perplexity):
1. Dein Rechner oder Browser ist der gemeinsame Faktor. Es wird über deinen Rechner Folgendes abgegriffen:
- WordPress-Sitzungscookies und gespeicherte Browserpasswörter.
- Passwörter aus FTP-/SFTP-Programmen, SSH-Clients oder Passwortmanagern.
- Zugangsdaten zum Hosting-Panel, zu E-Mail, DNS, Cloudflare oder Backup-Systemen.
- API- und Application-Passwords.
- Browser-Erweiterungsdaten und möglicherweise SSH-Schlüssel.

2. Gemeinsamer Dienst oder gemeinsames Plugin
Prüfe, ob auf allen Websites dieselben Komponenten installiert sind:
- Theme
- Page Builder, Backup-, Migration-, SEO- oder Security-Plugin.
- Management-System wie MainWP, ManageWP, InfiniteWP oder ein Hosting-Tool.
- Gemeinsame externe API, automatische Deployment- oder Backup-Verbindung.

3. Gemeinsames Hosting-Konto oder Serverzugriff
„Mehrere Hoster“ heißt nicht unbedingt „vollständig getrennte Zugänge“. Prüfe, ob mehrere Installationen über Folgendes verbunden sind:
- Derselbe Hoster-Account oder dieselbe zentrale E-Mail-Adresse.
- Derselbe Reseller- oder Agenturzugang.
- Gemeinsames cPanel-, Plesk-, SSH- oder API-Konto.
- Gemeinsame Backup-Ziele.
- Gleiche DNS-/Cloudflare-Zugangsdaten.
- Mehrere Websites im selben Webspace oder Dateisystem.

Zitat von Raphael

Dein Rechner oder Browser ist der gemeinsame Faktor.

nicht nur, das gleiche Thema, ein gleiches Plugin, so zum Beispiel die Contactform 7 hat einen Vorfall: https://www.sentinelone.com/vulnerability-…/cve-2025-3247/