Es ist nicht so, dass Websites früher generell nicht angegriffen worden wären. Automatisierte Scans, Brute-Force-Versuche, Bots und das Ausnutzen bekannter Sicherheitslücken gehören seit vielen Jahren zum Grundrauschen des Internets. Content-Management-Systeme (CMS) sind dabei besonders attraktive Ziele, und WordPress ist als mit Abstand am weitesten verbreitetes CMS naturgemäss besonders exponiert — ein klassischer «Windows-Effekt». Trotzdem war IT-Sicherheit für uns lange kein eigenständiges Arbeitsgebiet.
Wenn wir technische Wartungsarbeiten ausführten, hielten wir WordPress, Themes und Plugins aktuell, allerdings in grösseren Intervallen als heute — auch weil jede Aktualisierung ihrerseits Risiken birgt —, verwendeten sichere Passwörter, arbeiteten mit etablierten Hosting-Anbietern und entfernten Test- und Entwicklungssysteme, die nicht mehr benötigt wurden. Zusätzliche Sicherheitslösungen wie Wordfence waren auf einem Teil der Websites installiert, damals aber noch nicht Bestandteil unserer grundsätzlichen Basiskonfiguration. Besondere Vorkommnisse gab es schlicht nicht. Vor allem aber: Seit unserer ersten WordPress-Website im Jahr 2010 war uns kein Fall bekannt, in dem eine von uns entwickelte Website erfolgreich kompromittiert worden war.
Bis 2026.
Dann wurden innerhalb kurzer Zeit gleich mehrere unserer Websites gehackt — nicht durch spektakuläre Angriffe, die eine Website sichtbar zerstörten, sondern teilweise auf eine Art, die wesentlich gefährlicher ist: still, unauffällig und darauf ausgelegt, möglichst lange unentdeckt zu bleiben.
Eine Website kann funktionieren und trotzdem gehackt sein
Die Vorstellung eines «gehackten Computers» stammt noch immer stark aus einer Zeit, in der Schadsoftware sichtbar wurde: Der Bildschirm verhielt sich seltsam, Dateien verschwanden oder ein System funktionierte nicht mehr. Bei modernen Websites kann das Gegenteil sinnvoller sein. Eine kompromittierte Website soll möglichst normal aussehen — für Besucher, Betreiber und mitunter selbst für Administratoren.
In unseren Fällen fanden sich unter anderem manipulierte PHP-Dateien, eingeschleuster Code, versteckte administrative Benutzer, kompromittierte Plugins und Themes sowie Mechanismen, die abhängig vom jeweiligen Besucher unterschiedliche Inhalte auslieferten. Teilweise wurden Websites dazu verwendet, für Suchmaschinen vollständig andere Inhalte bereitzustellen als für normale Besucher. Glücksspiel- und Spam-Inhalte gelangten dadurch in Suchindizes wie Google, obwohl auf der eigentlichen Website davon nichts zu sehen war.
Andere Dateien dienten als Hintertüren, über die Angreifer auch nach einer vermeintlichen Bereinigung wieder Zugang hätten erhalten können. Genau darin liegt der entscheidende Unterschied: Eine Website lässt sich nicht allein dadurch als «sauber» betrachten, dass sie wieder normal aussieht. Entscheidend ist vielmehr die Frage, weshalb der Angriff stattfinden konnte, welche Bereiche betroffen waren und ob noch weitere Zugänge oder veränderte Dateien existieren, die bislang nicht entdeckt wurden.
Aus einem technischen Problem wird damit eine forensische Aufgabe.
Vom Website-Support zur IT-Forensik
Noch wenige Monate zuvor hätten wir viele der Arbeiten, die daraus entstanden, selbst kaum unserem klassischen Tätigkeitsgebiet im Bereich Kommunikation und Werbung zugerechnet. Plötzlich analysierten wir Dutzende Megabytes an Serverlogs, suchten über SSH komplette Hosting-Umgebungen nach verdächtigen Dateien, Zeichenfolgen und Änderungen ab, verglichen Zeitstempel, rekonstruierten mögliche Infektionswege, überprüften Benutzerkonten und Berechtigungen, analysierten PHP-Code und untersuchten, welche Systeme über gemeinsame Zugangsdaten oder Installationen miteinander verbunden sein könnten.
Aus einzelnen Prüfungen entwickelte sich schliesslich ein eigenes Security-Script, mit dem sich WordPress-Installationen systematisch auf verdächtige Veränderungen untersuchen lassen. Die Lernkurve war aussergewöhnlich steil — nicht, weil plötzlich ausreichend Zeit für Weiterbildung vorhanden gewesen wäre, sondern weil konkrete Probleme gelöst werden mussten. Und zwar schnell.
Dabei steht uns heute ein Werkzeug zur Verfügung, das diesen Lernprozess fundamental verändert: künstliche Intelligenz. Allerdings nicht nur uns.
KI senkt die Schwelle für Angriffe
Es wäre zu einfach, die zunehmenden Angriffe auf Websites allein auf künstliche Intelligenz zurückzuführen. Automatisierte Angriffe gab es lange vor KI. Schwachstellen werden seit Jahrzehnten systematisch gesucht, Botnetze scannen Millionen von Servern und Exploits für bekannte Sicherheitslücken werden automatisiert eingesetzt.
KI verändert jedoch die ökonomischen Bedingungen solcher Angriffe. Sie kann Code erklären und verändern, bekannte Angriffstechniken kombinieren, Varianten erzeugen, Fehler finden, Skripte anpassen und technische Dokumentationen auswerten. Aufgaben, für die früher relativ spezialisiertes Wissen erforderlich war, werden dadurch einfacher zugänglich. Die Eintrittsschwelle sinkt und gleichzeitig lässt sich bereits vorhandenes Wissen wesentlich effizienter skalieren.
Dass diese Entwicklung mehr als eine theoretische Möglichkeit ist, lässt sich inzwischen beobachten. Wordfence erfasst seit Ende November 2025, ob gemeldete WordPress-Schwachstellen mit KI-Unterstützung gefunden wurden. In der ersten vollständigen Messwoche waren es 16 Prozent; im April 2026 bereits rund 66 Prozent. Der Verizon Data Breach Investigations Report 2026 dokumentiert gleichzeitig den Einsatz generativer KI in unterschiedlichen Phasen realer Angriffe — von der Suche nach Schwachstellen bis zur Entwicklung von Malware. 31 Prozent der im Bericht untersuchten Datenverletzungen begannen mit der Ausnutzung von Software-Schwachstellen.
Diese Zahlen beweisen keine einfache Kausalität nach dem Muster «mehr KI gleich mehr Angriffe». Sie stützen aber den entscheidenden Punkt: KI senkt Zeitaufwand, Kosten und Wissenshürden in genau jenem technischen Feld, das für Angreifer und Verteidiger gleichermassen relevant ist. Akteure, die ohnehin Angriffe durchführen wollen, können dadurch schneller experimentieren, automatisieren und bestehende Werkzeuge weiterentwickeln.
Ein Angriff muss sich dabei nicht einmal gegen ein bestimmtes Unternehmen richten. Wenn sich hunderttausende WordPress-Installationen automatisiert prüfen lassen, genügt bereits eine kleine Erfolgsquote. Die einzelne Website ist dann nicht das Ziel eines persönlichen Angriffs. Sie ist eine Gelegenheit.
KI demokratisiert auch die Verteidigung
Bemerkenswert ist allerdings, dass auf der anderen Seite exakt dasselbe geschieht. Auch die Verteidigung profitiert davon, dass technisches Spezialwissen plötzlich wesentlich unmittelbarer verfügbar wird.
Wer eine verdächtige PHP-Datei findet, musste früher zunächst erkennen, was der Code überhaupt tut. Anschliessend musste beurteilt werden, ob das Verhalten legitim ist, ob es zu WordPress oder einem Plugin gehört und ob daraus weitere Untersuchungen notwendig werden. Heute lässt sich ein solcher Code gemeinsam mit einer KI analysieren — nicht im Sinn eines automatischen Urteils, sondern als enorm leistungsfähiges Werkzeug für die Untersuchung. Das gilt besonders im Bereich von Open-Source-Software, zu der riesige Mengen öffentlich zugänglichen Codes, technischer Dokumentationen und Diskussionen existieren.
Dasselbe gilt aber auch für Serverlogs, reguläre Ausdrücke, Shell-Befehle, Dateiberechtigungen, Webserver-Konfigurationen, Firewall-Regeln oder komplexe Zusammenhänge zwischen verschiedenen Systemkomponenten. Innerhalb weniger Wochen konnten wir dadurch Aufgaben übernehmen, für die wir früher vermutlich spezialisierte externe Unterstützung beigezogen hätten.
Wir konnten nicht deshalb plötzlich IT-Forensik betreiben, weil künstliche Intelligenz uns automatisiert alle Entscheidungen abnahm, sondern weil sie die Distanz zwischen einer Frage und dem dafür notwendigen Spezialwissen drastisch verkürzte. Hätten wir solche Fälle vor wenigen Jahren bearbeiten müssen, hätten wir mit grosser Wahrscheinlichkeit spezialisierte Forensik-Dienstleister beigezogen. Heute konnten wir die entscheidenden Analysen und Bereinigungsschritte selbst durchführen. Die Zeit zwischen Entdeckung und handlungsfähiger Analyse sank für uns damit von potenziell Tagen oder Wochen auf wenige Stunden. Das ist bemerkenswert.
Dazwischen steht der Mensch
Die Vorstellung, KI könne solche Aufgaben selbständig lösen, greift trotzdem zu kurz. Ein Sprachmodell kann erklären, weshalb eine Datei verdächtig aussieht. Es kann Befehle formulieren, Logs interpretieren und Hypothesen über einen möglichen Angriff entwickeln. Es weiss aber nicht automatisch, welche Hypothese in einem konkreten System tatsächlich zutrifft. Das gilt für Verteidiger ebenso wie für Angreifer.
Ein Modell kennt nicht sämtliche Zusammenhänge zwischen Websites, Hosting-Accounts, Entwicklungsumgebungen, alten Installationen und organisatorischen Abläufen. Und vor allem trägt KI keine Verantwortung für die Entscheidung, was als sicher gelten darf. Der Mensch bleibt deshalb die entscheidende Instanz: Er muss erkennen, wann eine Information relevant ist, Zusammenhänge herstellen, zwischen einer technischen Möglichkeit und einer plausiblen Ursache unterscheiden und entscheiden, wann eine Untersuchung weit genug gegangen ist.
In diesem Sinn wirkt künstliche Intelligenz derzeit paradox:
Sie ist Brandbeschleuniger und Feuerlöscher zugleich. Dazwischen steht der Mensch.
Sicherheit ist kein Zustand mehr
Aus den Vorfällen des Jahres 2026 entstand zwangsläufig die nächste Frage: Was lässt sich präventiv tun?
Die Antwort ist zugleich einfach und unbefriedigend. Es gibt keine einzelne Massnahme, die eine WordPress-Website sicher macht. Sicherheit entsteht aus vielen vergleichsweise unspektakulären Einzelmassnahmen.
WordPress, Themes und Plugins müssen aktuell gehalten werden — in kürzeren Intervallen als früher. Nicht mehr verwendete Entwicklungs- und Staging-Systeme müssen konsequent entfernt werden. Administratoren benötigen sichere Zugangsdaten und möglichst eine Zwei-Faktor-Authentifizierung. Sicherheitslösungen wie Wordfence gehören für uns inzwischen zum Pflichtprogramm; sie können verdächtige Zugriffe erkennen und blockieren. Firewalls auf Server- oder Anwendungsebene können typische Angriffsmuster bereits abfangen, bevor sie WordPress überhaupt erreichen — sie können aber auch legitime redaktionelle Arbeiten erschweren und müssen entsprechend abgestimmt werden.
Auch die Basiskonfiguration verdient mehr Aufmerksamkeit als früher. Dateien wie .htaccess und wp-config.php lassen sich härten. Kritische Systemdateien können mit restriktiveren Berechtigungen versehen werden. Die Ausführung von PHP lässt sich durch systemspezifische Regeln dort unterbinden, wo sie nicht benötigt wird. Sicherheits-Keys können erneuert, unnötige Schnittstellen geschlossen und administrative Funktionen eingeschränkt werden.
Keine dieser Massnahmen garantiert Sicherheit. Gemeinsam erhöhen sie jedoch die Hürde. Und Hürden sind relevant, wenn Angriffe automatisiert stattfinden. Ein Bot sucht nicht zwingend nach der wichtigsten Website. Er sucht nach der einfachsten.
Wartung wird aufwendiger
Damit verändert sich auch die Bedeutung von Website-Wartung. Dabei ist eine Unterscheidung wichtig, die im Alltag leicht verloren geht: Die Entwicklung einer Website und ihr laufender Betrieb sind zwei unterschiedliche Leistungen. Wer eine Website entwickelt, übernimmt damit nicht automatisch deren dauerhafte Überwachung, Aktualisierung und Absicherung. Ohne ein entsprechendes Mandat bleibt der laufende Betrieb Sache des Website-Betreibers.
Für die meisten von uns realisierten Websites besteht kein laufendes Wartungsmandat. Wir kümmern uns dennoch von Zeit zu Zeit um Aktualisierungen und Sicherheitsmassnahmen, wenn es aus unserer Sicht sinnvoll oder nötig ist. Das ist Teil unseres Dienstleistungsverständnisses und auch in unserem eigenen Interesse an stabilen Systemen — aber keine Zusage einer laufenden Überwachung oder bestimmter Wartungsintervalle.
Wenn solche Wartungsarbeiten anstanden, bestand die Aufgabe lange vor allem darin, Systeme wieder aktuell und funktionsfähig zu machen. Updates wurden kontrolliert eingespielt, das Frontend geprüft, veraltete Komponenten ersetzt und technische Probleme behoben. Gerade bei älteren Systemen war und ist das kein trivialer Vorgang. Dieser Aufwand bleibt für Website-Betreiber häufig unsichtbar. Dabei wird leicht unterschätzt, wie schnell technische Systeme altern: Kaum etwas ist älter als eine fünf Jahre alte Website.
Diese Aufgaben bleiben. Hinzu kommt jedoch zunehmend eine zweite Ebene: Welche Sicherheitslücken wurden bekannt? Ist ein Plugin weiterhin vertrauenswürdig? Sind ungewöhnlich viele Angriffe festzustellen? Muss eine Firewall anders konfiguriert werden, um False Positives zu reduzieren oder Angriffe konsequenter zu blockieren? Hat sich an den empfohlenen Sicherheitseinstellungen etwas verändert? Gibt es alte Installationen oder Entwicklungsumgebungen, die ein unnötiges Risiko darstellen? Sind neue Mechanismen notwendig, die vor einem Jahr noch keine Rolle spielten? Hinzu kommt: WordPress-Websites gleichen sich nur im Kern; darüber hinaus besteht jede Installation aus einer eigenen Kombination von Themes, Plugins und systemspezifischen Lösungen.
Der Aufwand verschiebt sich dadurch von einer rein technischen Pflege hin zu einer kontinuierlichen Risikoabwägung. Das ist weniger sichtbar als ein neues Design oder eine neue Funktion — aber nicht weniger real.
Die Halbwertszeit des Wissens sinkt
Vielleicht war dies die wichtigste Erkenntnis aus den vergangenen Monaten. Wir haben in kurzer Zeit ausserordentlich viel über Webserver-Sicherheit, WordPress-Härtung, Firewalls, Logs und IT-Forensik gelernt. Vor wenigen Jahren hätte dieses Wissen vermutlich relativ lange Bestand gehabt. Heute ist davon nicht mehr auszugehen.
Neue Sicherheitslücken entstehen. Angriffsmethoden verändern sich. Plugins verschwinden oder werden von neuen Anbietern übernommen. Schutzmechanismen werden erweitert. Hosting-Infrastrukturen entwickeln sich weiter. Und künstliche Intelligenz beschleunigt diese Prozesse zusätzlich.
Das Wissen von heute bleibt wertvoll, aber seine Halbwertszeit sinkt. Deshalb wird es zunehmend schwierig, Sicherheit als einmal abgeschlossene technische Aufgabe zu verstehen. Eine Website ist nicht sicher, weil sie irgendwann einmal richtig konfiguriert wurde. Sie ist sicherer, wenn sie beobachtet, gepflegt und laufend neu beurteilt wird. Wer diese Aufgabe übernimmt, muss deshalb ebenso bewusst geklärt sein wie die technischen Massnahmen selbst.
Vielleicht ist Lernfähigkeit die wichtigste Sicherheitsmassnahme
2026 war für uns das Jahr, in dem die Hacker kamen. Es war gleichzeitig das Jahr, in dem sich unser Verständnis von Website-Sicherheit grundlegend verändert hat.
Wir mussten lernen, dass funktionierende Systeme kompromittiert sein können, dass eine Bereinigung mehr bedeutet, als Schadcode zu löschen, dass Prävention aus vielen kleinen technischen und organisatorischen Entscheidungen besteht und dass künstliche Intelligenz die Bedrohung ebenso verändert wie unsere Möglichkeiten, darauf zu reagieren.
Vielleicht liegt darin die eigentliche Pointe.
Die wichtigste Sicherheitsmassnahme der kommenden Jahre ist möglicherweise weder ein bestimmtes Plugin noch eine bestimmte Firewall oder Serverkonfiguration, sondern die Fähigkeit, neue Situationen schnell zu verstehen, Wissen einzuordnen und Systeme immer wieder neu zu beurteilen.
Kurz gesagt: lernfähig zu bleiben.
