Es gibt eine Zahl im aktuellen State of WordPress Security-Bericht von Patchstack, die man einfach einmal sacken lassenmuss: Bei den am intensivsten ausgenutzten Schwachstellen lag der gewichtete Median von der öffentlichen Bekanntmachung bis zur ersten beobachteten Massenausnutzung 2025 bei fünf Stunden. Nicht Tagen. Stunden (Patchstack, State of WordPress Security in 2026, Februar 2026).

Wer als Geschäftsführer eines mittelständischen Unternehmens nicht binnen eines halben Arbeitstages reagiert, ist statistisch betroffen. Die meisten Unternehmen können das nicht - nicht aus Nachlässigkeit, sondern weil sie weder eine eigene IT-Abteilung haben noch die Werkzeuge, eine solche Reaktion überhaupt zu organisieren.

... oder: was nicht lebt, kann nicht getötet werden.

— Steven Broschart

Und es geht hier nicht um Einzelfälle: Allein 2025 wurden im WordPress-Ökosystem 11.334 neue Schwachstellen registriert, ein Plus von 42 Prozent gegenüber dem Vorjahr (Patchstack, Februar 2026). Besonders alarmierend ist die Verschiebung in der Gefährlichkeit dieser Lücken: Die Zahl der als hochgradig ausnutzbar eingestuften Schwachstellen stieg gegenüber dem Vorjahr um 113 Prozent - mehr hochkritische Lücken als in den beiden Vorjahren zusammen (The Repository / Patchstack, März 2026). Über 90 Prozent dieser Lücken sitzen nicht im WordPress-Kern, der gut gepflegt ist, sondern in den Plugins, mit denen sich praktisch jede Live-Website schmückt.

Das ist die Lage, in der wir uns befinden. Die Reaktion darauf ist seit Jahren dieselbe: schneller patchen, besser monitoren, mehr Sicherheits-Plugins, professionelleres Hosting.

Das sind alles legitime Maßnahmen. Sie haben nur einen Nachteil:

Sie verwalten das Problem, anstatt es zu reduzieren.

Und sie kosten Geld und Aufmerksamkeit, die in vielen Unternehmen schlicht nicht vorhanden sind.

Es gibt aber auch eine andere Frage, die selten gestellt wird: Warum eigentlich muss die Website eines Bäckers, einer Anwaltskanzlei oder eines mittelständischen Industriezulieferers technisch genau so funktioniert wie eine komplexe Webanwendung? Warum braucht eine Seite, die im Wesentlichen Texte, Bilder und Kontaktdaten anzeigt, eine Datenbank, eine Skriptsprache und ein Plugin-Ökosystem mit Dutzenden Erweiterungen?

Was sich gerade verschärft

Im April 2026 hat Anthropic mit Claude Mythos ein KI-Modell vorgestellt, das in der Lage ist, Schwachstellen in Software vollautomatisch zu finden und funktionierende Angriffe dafür zu entwickeln. In den eigenen Tests des Anbieters wurden auf diese Weise nicht nur tausende bisher unbekannter Lücken in jedem großen Betriebssystem und jedem großen Webbrowser entdeckt - das System fand auch eine 27 Jahre alte Schwachstelle in OpenBSD, einem als sehr sicher geltenden Betriebssystem. Auch andere Forschungsteams beobachten den Trend: Kritische Sicherheitslücken werden zunehmend von KI gefunden - nicht von Menschen (Help Net Security, April 2026).

Daraus ergeben sich zwei wesentliche Verschiebungen:

  • Erstens: Die Menge gefundener Schwachstellen wird nicht mehr linear ansteigen, sondern in gewaltigen Schüben. Code, der seit Jahrzehnten eigentlich als geprüft und sicher galt, muss erneut auf Schwachstellen überprüft werden.
  • Zweitens: Auch Angreifer verfügen über vergleichbare Werkzeuge, wenn diese verfügbar sind. Anthropic hat bereits im November 2025 berichtet, dass eine staatlich geförderte Gruppe Claude Code für reale Angriffe gegen rund dreißig Ziele eingesetzt hat (Anthropic, Threat Intelligence Report, November 2025).

Für die Praxis bedeutet das: Das Patch-Fenster wird nicht nur enger, es wird strukturell unhaltbar.

Wenn KI-gestützte Discovery in den Werkzeugkasten der Angreifer wandert, was binnen Monaten geschehen wird, müssen Verteidiger nicht mehr mit Dutzenden, sondern mit Tausenden neuen Schwachstellen pro Plugin-Generation rechnen - und mit einer Massenausnutzung, die nicht mehr in Stunden, sondern in Minuten gemessen wird. Wer dieser Entwicklung mit "wir patchen schneller" begegnet, hat das Wettrennen bereits verloren. Es bleibt nur, das Spielfeld zu wechseln.

Wie sind wir hierher gekommen?

Anfang der 2000er Jahre bestanden Websites aus statischen HTML-Dateien. Wer etwas änderte, lud per FTP eine neue Datei hoch. Das war umständlich, vor allem für weniger technisch affine Anwender. Ein Umstand, der die CMS-Welle erst möglich machte.

Mit WordPress, TYPO3, Drupal und Joomla standen nun Systeme zur Verfügung, mit denen Inhalte über eine Benutzeroberfläche im Browser bearbeitet werden konnten. Das war ein echter Fortschritt, weil es Redakteure von Entwicklern entkoppelte.

Was dabei kaum jemand thematisierte: Diese Bequemlichkeit hatte einen Preis. Aus statischen Dateien wurde eine Architektur, die bei jedem Seitenaufruf einige Ressourcen erforderte:

  • Datenbank abfragen,
  • Templates rendern,
  • Plugins laden,
  • Inhalte zusammensetzen,
  • ausliefern.

Und mit jedem Plugin, das diese Architektur erweiterte, wuchs nicht nur die Funktionalität, sondern auch die Angriffsfläche. Aus einer einfachen Datei, die nur Inhalte auslieferte, wurde eine permanent laufende Anwendung, die bei jedem Seitenaufruf Daten verarbeitet, Code ausführt und externe Erweiterungen lädt - und damit grundsätzlich angreifbar wird.

Diese Verschiebung hat eine Folge, die in der Debatte oft untergeht:

Sicherheit wurde von einer architektonischen Frage zu einer operativen.

Sie hängt seither nicht mehr davon ab, was die Website grundsätzlich kann, sondern davon, wie gut sie täglich gepflegt wird. Wer die Pflege leistet, ist halbwegs sicher. Wer sie nicht leistet, ist in fünf Stunden Teil einer Statistik.

Zwei Sicherheitsmodi

Es lohnt sich, an dieser Stelle einen Unterschied zu benennen, der in der öffentlichen Diskussion fast nie gemacht wird.

Der operative Sicherheitsmodus: Eine Anwendung ist potenziell anfällig, deshalb wird sie permanent überwacht, regelmäßig aktualisiert, hinter Firewalls gestellt und durch zusätzliche Sicherheits-Tools abgeschirmt. Das funktioniert, solange Disziplin, Personal und Budget vorhanden sind. Es ist der Modus, in dem große Unternehmen mit eigener IT-Abteilung dauerhaft leben können.

Für kleine und mittlere Unternehmen ist es ein Modus, in dem sie eigentlich nicht leben können - und in den sie trotzdem gedrängt werden, weil sie eine WordPress-Site betreiben, die diesen Aufwand strukturell verlangt.

Der strukturelle Sicherheitsmodus: Statt eine Anwendung zu härten, wird die Angriffsfläche so weit reduziert, dass weniger zu härten ist. Das ist nicht neu - Sicherheitsfachleute sprechen seit Jahrzehnten von attack surface reduction. Was lange fehlte, war eine praktische Möglichkeit, dieses Prinzip auf die typische Unternehmenswebsite anzuwenden, ohne dafür ein Team aus Entwicklern zu beschäftigen.

Genau hier hat sich in den letzten Jahren etwas verschoben.

Was 'statisch' ändert

Das Grundprinzip ist überraschend einfach. Statt die Website bei jedem Besucheraufruf neu zusammenzusetzen, wird sie einmal im Voraus erzeugt - als Sammlung fertiger HTML-Dateien, die der Webserver nur noch ausliefert.

  • Keine Datenbank im laufenden Betrieb.
  • Keine Skriptsprache, die ausgeführt werden müsste.
  • Keine Plugins, die in Echtzeit Inhalte einstreuen.

Die Folge ist eine kategoriale Verschiebung des Sicherheitsproblems. Eine angreifbare Komponente kann nur dann angegriffen werden, wenn sie auch tatsächlich erreichbar ist.

  • Wer keine Datenbank betreibt, kann keine SQL-Injection erleiden.
  • Wer kein PHP ausführt, kann keine PHP-Schwachstelle haben.
  • Wer keine Plugins lädt, kann nicht durch ein kompromittiertes Plugin infiziert werden.

Das klingt fast trivial, und technisch ist es das auch - strategisch aber ist es eine völlig andere Denkweise: nicht mehr Schutz durch zusätzliche Kontrolle, sondern durch bewusste Reduktion von Komplexität.

Hier kommt ein Argument hinzu, das in der Diskussion meist übergangen wird: Selbst wenn das Werkzeug, mit dem die Website erstellt wird, technisch unvollkommen ist - etwa weil es in Teilen mit KI-Unterstützung entwickelt wurde und Sicherheitsschwächen enthält -, bleibt es im Hintergrund. Es läuft nur dann, wenn jemand bewusst Inhalte ändert. Es ist nicht öffentlich erreichbar. Und falls es einmal kompromittiert würde, wäre die Folge eine korrupte Build-Umgebung - nicht eine kompromittierte Live-Website mit allem, was an ihr hängt.

Diese Trennung zwischen Bauen und Betreiben ist es, was die statische Architektur so robust macht. Was am Internet erreichbar ist, das ist nicht das Werkzeug, sondern nur sein Ergebnis. Und ein fertiges HTML-Dokument besitzt keine serverseitige Laufzeitumgebung, durch die ein Angreifer dynamisch in das System eindringen könnte.

Bemerkenswert ist übrigens, dass Patchstack in seinem aktuellen Bericht ausdrücklich davor warnt, dass die Verbreitung KI-gestützter Codeerstellung - das, was unter dem Begriff Vibe-Coding firmiert - das Schwachstellenproblem im klassischen Plugin-Ökosystem noch verschärft, weil Entwickler Code veröffentlichen, den sie selbst nicht mehr vollständig prüfen können (Patchstack, State of WordPress Security in 2026).

Im statischen Modell verliert dieses Argument seine Schärfe. Nicht weil der Code besser wäre, sondern weil er nicht im Hot Path steht.

Drei positive Nebeneffekte

Die statische Architektur löst nicht nur das Sicherheitsproblem. Sie bringt drei weitere Effekte mit, die im klassischen CMS-Modell spezielle Features darstellen, die hier aber praktisch geschenkt anfallen.

1. Staging als Defaultzustand

Wer eine klassische CMS-Site betreibt und vor Änderungen eine Testumgebung braucht, muss sie sich einrichten:

  • eine zweite Datenbank,
  • ein zweiter Server,
  • Synchronisierungsroutinen,
  • ein Plugin oder eine Dienstleistung.

Im statischen Modell ist das nicht nötig. Die Build-Umgebung ist die Staging-Umgebung. Was dort erzeugt wird, lässt sich beliebig prüfen, korrigieren und überarbeiten, bevor irgendetwas öffentlich wird. Aus einem operativen Zusatzaufwand wird ein architektonischer Defaultzustand.

2. Performance

Eine statische Datei, die direkt vom Server oder einem Content Delivery Network ausgeliefert wird, ist nicht nur ein wenig schneller als eine dynamisch generierte Seite. Time-to-First-Byte-Werte (also die Zeit, in der ein Server auf eine Anfrage mit dem Senden der ersten Datenpakete beginnt) im niedrigen zweistelligen Millisekundenbereich sind keine Ausnahme, sondern der Normalfall. Klassische CMS erreichen vergleichbare Werte selbst mit aggressiv konfiguriertem Caching kaum - das aber trotzdem Wartung erfordert und in Grenzfällen versagt.

Das ist nicht nur ein technisches Detail. Etablierte Studien von Google und großen Online-Händlern zeigen seit Jahren, dass jede zusätzliche Sekunde Ladezeit messbar Conversions, Verweildauer und Interaktion kostet. Im B2B-Bereich steigen Absprungraten oberhalb von drei Sekunden Ladezeit stark an.

3. Sichtbarkeit

Google bewertet Ladegeschwindigkeit und Stabilität seit Einführung der Core Web Vitals als Ranking-Signale. Weniger thematisiert, aber technisch gut belegbar, ist die Bedeutung dieser Faktoren für KI-Systeme. AI-Crawler wie GPTBot, ClaudeBot oder PerplexityBot arbeiten häufig primär auf Basis des initial ausgelieferten HTML und operieren mit engen Zeitfenstern von wenigen Sekunden, jenseits derer sie eine Seite überspringen.

Eine dynamische Seite mit:

  • langer Ladezeit,
  • client-seitig nachgeladenen Inhalten
  • oder komplexen Rendering-Prozessen

läuft Gefahr, gar nicht oder nur unvollständig erfasst zu werden - unabhängig davon, wie hochwertig ihre Inhalte sind. Statisches HTML erfüllt diese Anforderungen praktisch automatisch. Das ist keine Garantie dafür, in KI-Antworten zitiert zu werden - das hängt weiter von:

  • Inhalt,
  • Autorität
  • und Relevanz

ab. Aber es ist die technische Voraussetzung dafür.

Was nicht erfasst wird, kann auch nicht zitiert werden.

Diese drei Effekte verändern die Kostenrechnung. Ein klassisches CMS verlangt nicht nur:

  • Sicherheits-Pflege,
  • sondern auch Performance-Tuning,
  • separate Staging-Setups
  • und SEO-Aufwand.

Im statischen Modell sind diese Anforderungen in der Architektur bereits eingelöst. Das ist nicht zwingend ein Argument für jede Website - aber es ist ein Argument, das in der Diskussion oft fehlt, weil es nicht in das Schema "Feature gegen Feature" passt, sondern auf einer Ebene tiefer entsteht.

Warum das jetzt umsetzbar wird

Statische Site Generatoren gibt es nicht erst seit gestern. Werkzeuge wie Jekyll oder Eleventy existieren teils seit über einem Jahrzehnt und werden in Tech-affinen Kreisen schon lange genutzt. Was sich verändert hat, ist nicht das Konzept, sondern die Zugänglichkeit.

Bislang verlangten diese Werkzeuge:

  • Kommandozeilenkenntnisse,
  • Vertrautheit mit Versionskontrolle,
  • und oft spezielle Hosting-Setups.

Für Entwickler kein Problem. Für die Marketingleiterin eines mittelständischen Unternehmens aber eine Hürde, die in der Praxis selten überwunden wurde. KI-gestützte Werkzeuge ändern diese Gleichung. Was früher die Einrichtung einer Build-Pipeline und das Schreiben eigener Templates erforderte, lässt sich heute zunehmend per Dialog konfigurieren. Es entstehen Plattformen, die das statische Modell so aufbereiten, dass es ohne Entwickler-Kenntnisse nutzbar ist:

  • mit Migrationsassistenten,
  • übernommenen WordPress-Inhalten,
  • und redaktionellen Oberflächen, die dem Komfort klassischer CMS kaum nachstehen.

Diese Entwicklung steht noch am Anfang. Aber sie verschiebt die Schwelle, ab der die statische Architektur eine realistische Option ist. Die eigentliche Pointe lautet deshalb nicht:

dass plötzlich eine neue technische Innovation das Sicherheitsproblem löst.

Sondern:

dass eine lange bekannte architektonische Antwort erstmals für eine Zielgruppe praktisch zugänglich wird, die sie bisher nicht nutzen konnte.

Wo statische Seiten passen - und wo nicht

Nein, statische Dokumente stellen keine universelle Lösung dar. Sobald eine Website wirklich dynamische Funktionen braucht:

  • Login-Bereiche,
  • Echtzeitdaten,
  • komplexe Suchen,
  • transaktionale Abläufe,
  • individualisierte Inhalte,

stößt die rein statische Architektur an ihre Grenzen.

An dieser Stelle können aber hybride Modelle entstehen: Der statische Kern wird um selektive dynamische Komponenten ergänzt - auch über spezialisierte Drittanbieter:

  • Suche läuft extern,
  • Formularverarbeitung ebenso,
  • Authentifizierung ebenfalls.

Das beseitigt das Sicherheitsproblem nicht. Es verteilt es um. Aber: Spezialisierte Anbieter besitzen meist deutlich mehr Ressourcen und Expertise als ein mittelständisches Unternehmen, das eigentlich Pumpen oder Buchhaltungssoftware verkauft und nicht dauerhaft WordPress-Plugins patchen sollte.

Wann also ist der Einsatz von statischen Seiten sinnvoll? Ganz klar, für:

  • Unternehmens-Websites,
  • Portfolios,
  • Dokumentationen,
  • Blogs
  • oder Produktpräsentationen

ist die statische Architektur in vielen Fällen die strukturell überlegene Wahl. Für vollwertige Webanwendungen mit Benutzerkonten, Transaktionen und komplexer Interaktion ist sie es nicht.

"Aber es ist doch nur unsere Website"

An dieser Stelle wird in Diskussionen mit Entscheidern fast immer derselbe Einwand vorgebracht: Selbst wenn die Sicherheitslage so ist, wie sie ist - wäre es nicht hinnehmbar, wenn die Unternehmenswebsite einmal für ein paar Stunden oder Tage ausfällt? Lohnt sich für ein Risiko dieser Größenordnung wirklich der Aufwand einer Architektur-Entscheidung?

Die Frage klingt vernünftig. Sie beruht aber auf zwei Annahmen, die in der Praxis selten zutreffen - und ihre Beantwortung verschiebt das Bild grundlegend.

Die erste Annahme: Der Schaden eines erfolgreichen Angriffs sei Ausfallzeit. Das ist die Ausnahme, nicht die Regel. Die meisten kompromittierten KMU-Websites bleiben nicht offline - sie bleiben online und funktionieren weiter. Sie zeigen ihren Besuchern nur zusätzlich:

  • Schadcode,
  • leiten Suchanfragen auf Phishing-Seiten weiter,
  • verschicken Spam im Namen des Unternehmens,
  • hosten Inhalte für Kriminelle.

Der Inhaber merkt davon oft monatelang nichts. Auffällig wird der Vorfall meist erst, wenn Google die Domain als gefährlich markiert, wenn der Hoster eine Beschwerde weiterleitet, oder wenn ein Geschäftspartner anruft, weil sein Virenscanner die Website blockiert hat.

Der eigentliche Schaden ist dann nicht zwei Tage Downtime, sondern Wochen bis Monate Vertrauens- und Sichtbarkeitsverlust - und ein SEO-Reset, der sich nicht in derselben Zeit reparieren lässt, in der er entstanden ist. Wer einmal aus Googles Index entfernt wurde, kämpft anschließend nicht um Reichweite, sondern um Wiederzulassung.

Die zweite Annahme ist gravierender: Die Website sei ein isoliertes System. Auch das stimmt selten. WordPress-Installationen sind in der Regel verbunden:

  • mit dem CRM,
  • mit dem Newsletter-System,
  • mit dem Mailserver,
  • manchmal mit der Warenwirtschaft,

oft über geteilte Zugangsdaten und über einen Server, auf dem auch andere Dienste laufen.

Eine kompromittierte Website ist deshalb häufig nicht das Ziel eines Angriffs, sondern dessen Eintrittspunkt. Genau das ist die Anatomie der meisten Ransomware-Vorfälle im Mittelstand: Eintritt über ein vernachlässigtes Web-Plugin, Wochen unbemerkter Aufenthalt im Netzwerk, am Ende verschlüsselte Geschäftsdaten und eine Lösegeldforderung, die das Verhältnis "lohnt sich der Aufwand?" rückwirkend neu sortiert.

Die Zahlen sind eindeutig: Ausgenutzte Software-Schwachstellen sind seit drei Jahren in Folge der häufigste Einfallsvektor für Ransomware-Angriffe - verantwortlich für 32 Prozent aller Vorfälle weltweit (Sophos, State of Ransomware 2025, basierend auf 3.400 betroffenen Organisationen). Und der Verizon Data Breach Investigations Report 2025 zeigt:

88 Prozent aller bei KMU registrierten Datenpannen involvieren Ransomware - gegenüber 39 Prozent bei Großunternehmen.

Mittelständische Unternehmen sind nicht weniger gefährdet als Konzerne, sondern überproportional.

Dazu kommen die rechtlichen Folgen, die ohnehin entstehen, sobald personenbezogene Daten betroffen sind - etwa durch ein Kontaktformular, eine Bewerbermaske oder eine Newsletter-Anmeldung:

  • DSGVO-Meldepflicht innerhalb von 72 Stunden,
  • Informationspflicht gegenüber den Betroffenen,
  • ggf. Bußgeldverfahren,
  • in jedem Fall administrative Last durch Anwälte, Datenschutzbehörde und externe Forensik.

Selbst wenn der finanzielle Schaden im Einzelfall überschaubar bleibt, frisst die organisatorische Belastung Wochen an Arbeitszeit - meist von Personen, die in dieser Zeit ihre eigentliche Aufgabe nicht erfüllen können.

Die Frage ist nicht, ob ein paar Tage Ausfall verkraftbar wären. Sie wären es. Die Frage ist, ob ein monatelang unentdeckt kompromittiertes System, das als Brückenkopf in das eigene Netzwerk dient, ebenfalls verkraftbar wäre.

In den meisten Fällen lautet die Antwort: nein. Und die Wahrscheinlichkeit, dass genau dieses Szenario eintritt, ist nicht gleich null - sie ist gemessen an aktuellen Bedrohungsstatistiken im niedrigen einstelligen Prozentbereich pro Jahr, mit steigender Tendenz. Wer dieses Risiko mit dem vermeintlich gesparten Wartungsaufwand verrechnet, rechnet die falsche Bilanz.

Architektur ist eine strategische Entscheidung

Was bleibt, ist eine simple, aber unbequeme Erkenntnis. Die Sicherheit einer Website wird in der öffentlichen Wahrnehmung meist als operative Frage behandelt:

  • welche Plugins,
  • welche Updates,
  • welche Backups,
  • welches Sicherheits-Tool.

Für viele Unternehmen ist sie damit faktisch unlösbar, weil ihnen die Mittel fehlen, diese operativen Anforderungen dauerhaft zu erfüllen.

Sie ist aber zugleich eine architektonische Frage. Und auf dieser Ebene gibt es eine Antwort, die seit Jahren technisch verfügbar, aber lange nicht zugänglich war - und die in dem Maße praktikabel wird, in dem KI-gestützte Werkzeuge die Hürden absenken.

Eine Website, die im Wesentlichen Inhalte zeigt, muss nicht laufen wie eine Anwendung.

Und was nicht laufen muss, kann auch nicht angegriffen werden.

Das ist keine neue Erfindung. Es ist eine Rückbesinnung auf ein Prinzip, das vor einer Generation Standard war - und das in der CMS-Begeisterung der letzten zwanzig Jahre fast unsichtbar geworden ist.

Für die meisten kleinen und mittleren Unternehmen wäre die Frage, ob eine Website wirklich:

  • eine Datenbank,
  • eine Skriptsprache
  • und ein Plugin-Ökosystem

braucht, vermutlich die wichtigste digitale Entscheidung der nächsten Jahre.

Nicht zuletzt deshalb, weil sie das Sicherheitsproblem nicht löst, indem man besser darauf reagiert - sondern indem man die Voraussetzungen reduziert, unter denen es überhaupt entsteht. Und in einer Bedrohungslage, in der der Median bis zur Massenausnutzung bei fünf Stunden liegt - und KI-gestützte Angreifer diese Lage in den kommenden Monaten weiter verschärfen werden - ist es vielleicht die einzige Entscheidung, die für viele Unternehmen tatsächlich dauerhaft umsetzbar bleibt.