Im Jahr 2025 wurden im WordPress-Umfeld über elftausend Schwachstellen gemeldet — und für fast die Hälfte davon existierte im Moment der Veröffentlichung keine Korrektur. Beide Zahlen stimmen, beide werden regelmässig zitiert, und beide führen in die Irre, wenn man sie ohne die dritte Zahl liest: Nach der Auswertung von Wordfence für den Jahrgang 2024 gelten 7,4 Prozent der gemeldeten Schwachstellen als tatsächlich gefährlich. Dieser Beitrag ordnet die Zahlen ein, benennt die Interessenlage der Quellen und beantwortet die Frage, die der übliche Rat «halten Sie alles aktuell» offenlässt: Was tun Sie, wenn es nichts zu aktualisieren gibt?
Das Wichtigste in Kürze
- Die grosse Zahl ist die unwichtigste. Wordfence stuft 7,4 Prozent der Meldungen des Jahrgangs 2024 als hochgefährlich ein und über 68 Prozent als für die meisten Betreiber risikoarm. Der Anbieter schreibt selbst, die gestiegene Zahl der Meldungen sei kein Grund zur Beunruhigung.
- Fast alles sitzt in Erweiterungen. 96 Prozent nach der Zählung von Wordfence, 91 Prozent nach jener von Patchstack. Im WordPress-Kern waren es fünf beziehungsweise sechs Meldungen im ganzen Jahr.
- Die Lücken ohne Patch stecken überwiegend in kleinen Erweiterungen. 58 Prozent der Meldungen betrafen Software mit weniger als 10’000 Installationen. Der wirksamste Einzelschritt ist deshalb kein Werkzeug, sondern das Entfernen nicht mehr gepflegter Plugins.
- Bei den wenigen gefährlichen Fällen zählt der Tag, nicht der Monat. Patchstack misst für stark ausgenutzte Schwachstellen einen gewichteten Median von fünf Stunden bis zum ersten Angriff. Der Wert gilt für diese Auswahl, nicht für Schwachstellen allgemein.
- Beide Quellen verkaufen die Lösung, die ihre Zahlen nahelegen. Wir auch. Der Abschnitt zur Interessenlage sagt, was daraus folgt und welche Angaben deshalb mit Vorbehalt zu lesen sind.
Zwei Zählungen, zwei Ergebnisse
Zwei Unternehmen führen im WordPress-Umfeld eine eigene Schwachstellen-Datenbank und veröffentlichen jährliche Auswertungen: Patchstack und Wordfence. Ihre Zahlen weichen voneinander ab, und die Abweichung hat einen benennbaren Grund.
| Quelle | Berichtsjahr | Gemeldete Schwachstellen | Veränderung zum Vorjahr |
|---|---|---|---|
| Patchstack | 2025 | 11’334 | +42 % |
| Wordfence | 2024 | 8’223 | +68 % |
Wordfence erläutert den Unterschied in eigener Sache: Man zähle die Schwachstellen üblicherweise nach eigenständigen Datensätzen beziehungsweise nach CVE-Kennung, während andere Anbieter nach der Zahl der betroffenen Softwarepakete zählten. Eine einzige Schwachstelle, die in sieben Erweiterungen desselben Herstellers steckt, ergibt bei der einen Methode einen Eintrag und bei der anderen sieben.
Für die Praxis folgt daraus eine Regel, die über dieses Thema hinausreicht: Eine Schwachstellenzahl ohne die zugehörige Zählweise ist keine Kennzahl. Wer zwei solche Zahlen aus verschiedenen Quellen nebeneinanderstellt und daraus einen Trend ableitet, vergleicht zwei Messverfahren und nicht zwei Jahre.
Die Interessenlage der Quellen — und unsere eigene
Beide Auswertungen stammen von Unternehmen, die genau das verkaufen, was ihre Zahlen nahelegen. Patchstack bietet ein Verfahren an, das Angriffe auf bekannte Schwachstellen abwehrt, bevor ein Update vorliegt; die Kennzahl «Anteil der Schwachstellen ohne Patch» beschreibt unmittelbar den Markt dafür. Wordfence verkauft eine Web Application Firewall und beziffert im selben Bericht über 54 Milliarden blockierte Anfragen.
Das entwertet die Daten nicht. Beide Unternehmen sind offizielle Vergabestellen für CVE-Kennungen im WordPress-Umfeld und arbeiten mit den Herstellern zusammen; ihre Grundgesamtheit ist keine Schätzung, sondern die eigene Datenbank. Es verlangt aber eine Unterscheidung: Die Zähldaten sind belastbar, die Auswahl der hervorgehobenen Kennzahlen ist es nicht in gleichem Mass. Bemerkenswert ist deshalb, welche Aussagen die Anbieter treffen, obwohl sie dem eigenen Verkaufsargument entgegenstehen — der Satz von Wordfence, die gestiegene Zahl der Meldungen solle in der WordPress-Gemeinschaft kein Anlass zur Beunruhigung sein, gehört dazu.
Dieselbe Offenlegung schulden wir in eigener Sache: Wir verkaufen Wartung. Ein Beitrag, der zum Schluss kommt, dass laufende Betreuung nötig sei, argumentiert für das eigene Angebot. Der Abschnitt weiter unten benennt deshalb ausdrücklich, was ein KMU nicht braucht.
Die Zahl, auf die es ankommt: 7,4 Prozent
Eine gemeldete Schwachstelle ist kein Angriff und oft nicht einmal ein realistischer Angriffsweg. Entscheidend ist, was ein Angreifer mitbringen muss, um sie auszunutzen. Wordfence schlüsselt genau das auf.
| Merkmal | Anteil | Was das bedeutet |
|---|---|---|
| Als hochgefährlich eingestuft | 7,4 % | Ausnutzung wahrscheinlich, Schaden erheblich. Häufigste Art in dieser Gruppe: das Hochladen beliebiger Dateien. |
| Für die meisten Betreiber risikoarm | über 68 % | Ausnutzung setzt ein Benutzerkonto oder eine Handlung eines Angemeldeten voraus. |
| Schweregrad «mittel» | 81 % | Der Normalfall einer Meldung ist ein mittlerer Befund, nicht ein kritischer. |
| Erfordert mindestens Autoren-Rechte | 34 % | Nur relevant, wenn Fremde auf Ihrer Website ein Konto haben. |
Die Zeile mit den 34 Prozent wird am häufigsten falsch gelesen. Eine Schwachstelle, die ein Konto mit Autoren-Rechten voraussetzt, ist auf einer typischen KMU-Website ohne Fremdregistrierung praktisch nicht ausnutzbar — dort hat niemand ein Konto ausser dem Betrieb selbst. Auf einer Website mit Mitgliederbereich, Kundenkonten oder mehreren Redaktionen sieht dieselbe Meldung völlig anders aus. Dieselbe Zahl bedeutet für zwei Websites zwei verschiedene Dinge.
Ein Nebenbefund gehört dazu, weil er in die Gegenrichtung zeigt: Der Anteil der hochgefährlichen Meldungen ist gegenüber dem Vorjahr um 149 Prozent gestiegen. Die Gesamtzahl sagt wenig; die Zusammensetzung verschiebt sich.
Wo die Lücken sitzen
Bei der Verteilung sind sich beide Quellen einig, und das Ergebnis ist eindeutig genug, um daraus eine Handlungsregel abzuleiten.
| Ort | Wordfence, 2024 | Patchstack, 2025 |
|---|---|---|
| Plugins | 96 % | 91 % |
| Themes | der verbleibende Anteil | 9 % |
| WordPress-Kern | 5 Meldungen im ganzen Jahr | 6 Meldungen, sämtlich niedrige Priorität |
Der WordPress-Kern ist nicht das Problem. Diese Feststellung ist wichtig, weil die verbreitete Sorge dem Kern gilt — er trägt den Namen, also scheint er die Verantwortung zu tragen. Tatsächlich verteilt sich das Risiko fast vollständig auf Software, die jemand einmal zusätzlich installiert hat.
Ebenso deutlich ist die Verteilung nach Verbreitung: 58 Prozent der 2024 gemeldeten Schwachstellen betrafen Software mit weniger als 10’000 aktiven Installationen; 19 Prozent betrafen Software mit 50’000 Installationen oder mehr. Das Risiko konzentriert sich also dort, wo wenige Websites betroffen sind — und wo die Wahrscheinlichkeit am grössten ist, dass niemand mehr eine Korrektur liefert.
Der Fall, für den es kein Update gibt
Der Rat «halten Sie alles aktuell» deckt einen Fall nicht ab: den ohne verfügbare Korrektur. Beide Quellen messen ihn, mit unterschiedlicher Fragestellung und übereinstimmender Richtung:
- Patchstack zählt, wie viele Schwachstellen zum Zeitpunkt ihrer Veröffentlichung noch keine Korrektur hatten: 46 Prozent im Jahr 2025.
- Wordfence zählt, wie viele Schwachstellen eines Jahrgangs ein Jahr später immer noch offen waren: rund 35 Prozent der Meldungen aus 2024, gemessen im Frühjahr 2025.
Die beiden Werte messen nicht dasselbe und dürfen nicht gegeneinander verrechnet werden. Gemeinsam ergeben sie dennoch ein Bild: Ein erheblicher Teil der offengelegten Schwachstellen bleibt über längere Zeit ohne Korrektur. Wer nur aktualisiert, hat für diese Fälle kein Verfahren.
Zugleich relativiert die Verteilung nach Verbreitung das Ausmass, und zwar messbar. Wordfence schlüsselt die als hochgefährlich eingestuften Lücken nach Installationszahl auf: Über 66 Prozent von ihnen steckten in Software mit 10’000 oder weniger Installationen, 25 Prozent sogar in Software mit höchstens 100 Installationen. Ein Plugin ohne Korrektur ist in aller Regel ein Plugin, das nicht mehr gepflegt wird — und nicht gepflegte Erweiterungen haben typischerweise wenige Nutzer. Für eine Website, die auf gängigen und aktiv betreuten Erweiterungen aufbaut, tritt der Fall daher seltener ein, als die Prozentzahl vermuten lässt. Er trifft vor allem dort, wo vor Jahren eine Speziallösung eingebaut wurde, deren Entwickler das Projekt inzwischen eingestellt hat.
Der Umkehrschluss wäre allerdings falsch. Verbreitet heisst nicht sicher: 12 Prozent der gemeldeten Schwachstellen betrafen Software mit 50’000 Installationen oder mehr — und genau diese werden massenhaft angegriffen, weil sich der Aufwand für den Angreifer dort lohnt. Die Verteilung sagt also nicht, dass verbreitete Erweiterungen unbedenklich sind. Sie sagt, dass die Fälle ohne verfügbare Korrektur überwiegend am anderen Ende sitzen.
Wie viel Zeit tatsächlich bleibt
Die meistzitierte Zahl aus dem Patchstack-Bericht lautet: fünf Stunden bis zum ersten Angriff. Sie wird regelmässig verkürzt wiedergegeben, und die Verkürzung macht sie falsch. Der Wortlaut ist präziser: Rund die Hälfte der Schwachstellen mit hoher Auswirkung werde innerhalb von 24 Stunden ausgenutzt; gewichtet man nach der beobachteten Angriffsintensität, liege der Median der Zeit bis zum ersten Angriff bei fünf Stunden.
Zulässig ist daraus folgende Aussage: Bei den wenigen Schwachstellen, die tatsächlich in grossem Stil ausgenutzt werden, beginnen die Angriffe innerhalb von Stunden nach der Offenlegung. Unzulässig ist die Verallgemeinerung, nach fünf Stunden werde jede Schwachstelle angegriffen. Für die grosse Mehrheit der Meldungen gilt das erkennbar nicht — sonst wären die 68 Prozent risikoarmen Fälle keine risikoarmen Fälle.
Für den Betrieb ergibt sich daraus eine Zweiteilung. Der übliche Wartungsrhythmus — einmal im Monat alle Aktualisierungen einspielen — ist für über neunzig Prozent der Meldungen völlig ausreichend. Für die wenigen hochgefährlichen Fälle ist er wirkungslos, weil er um Grössenordnungen zu langsam ist. Ein Betrieb braucht deshalb nicht einen schnelleren Rhythmus, sondern zwei verschiedene Verfahren: einen ruhigen Regelbetrieb und einen Ausnahmeweg für die wenigen Fälle im Jahr, bei denen Stunden zählen.
Was in der Lücke zwischen Offenlegung und Korrektur wirkt
Die folgenden Massnahmen greifen unabhängig davon, ob eine Korrektur vorliegt. Die Spalte rechts ist die wichtigere: Keine dieser Massnahmen wirkt gegen alles, und wer sie als Rundumschutz verkauft, verkauft eine falsche Zusage.
| Massnahme | Wogegen sie wirkt | Wogegen sie nicht wirkt |
|---|---|---|
| Nicht mehr gepflegte Erweiterungen entfernen | Die gesamte Klasse der Lücken ohne Korrektur. Die einzige Massnahme, die das Problem beseitigt statt es abzuschirmen. | Nichts — wo die Funktion gebraucht wird, ist ein Ersatz nötig, und der kostet Zeit. |
| PHP-Ausführung im Upload-Verzeichnis unterbinden | Die häufigste Art in der Gruppe der hochgefährlichen Meldungen: das Hochladen ausführbarer Dateien. | Alles, was ohne Dateiablage auskommt — Rechteausweitung, Datenbankangriffe, Rechteumgehung. |
| Schutzfilter mit Regeln für einzelne bekannte Lücken | Massenhafte, automatisierte Angriffe auf eine Schwachstelle, für die der Anbieter bereits eine Regel geschrieben hat. | Alles, wofür keine Regel existiert. Und die Wirkung allgemeiner Abwehr ist geringer, als der Begriff «Firewall» nahelegt — dazu der Absatz nach der Tabelle. |
| Zahl der Konten und Rechte begrenzen (die unterschätzte Massnahme) | Die 34 Prozent, die mindestens Autoren-Rechte voraussetzen, und die über 68 Prozent, die überhaupt eine Anmeldung erfordern. Eine Firmenwebsite mit zwei Konten und ohne offene Registrierung ist gegen ein Drittel aller Meldungen strukturell unempfindlich — ohne Software und ohne laufende Kosten. | Alles, was ohne Anmeldung funktioniert — also gerade die gefährlichsten Fälle. |
| Überwachung auf veränderte Dateien | Die Entdeckung. Verkürzt die Zeit zwischen Zugriff und Bemerken von Monaten auf Stunden. | Den Zugriff selbst — sie verhindert nichts, sie meldet. Und sie hat einen blinden Fleck: Beim Supply-Chain-Angriff auf mehrere Elementor-Erweiterungen im August lief der Schadcode im Browser der Besucher, ohne dass sich auf dem Server eine Datei änderte. |
| Geprüfte Sicherung mit Rückspielprobe | Den Schadensfall. Entscheidet darüber, ob eine Kompromittierung einen Tag oder drei Wochen kostet. | Den Angriff. Und eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung, sondern eine Annahme. |
Zur Zeile mit dem Schutzfilter gehört eine Zahl, die selten genannt wird. Patchstack hat 2025 fünf Hosting-Anbieter gegen elf reale Plugin-Schwachstellen antreten lassen. Ergebnis: 87,8 Prozent der Angriffe kamen an der Abwehr des Hosters vorbei. Der beste Anbieter im Test blockte mit vorgeschaltetem Dienst vier der elf Angriffe, ein anderer mit zwei Schutzsystemen genau einen. Zwei Einschränkungen sind dabei so wichtig wie das Ergebnis: Der Test stammt vom Anbieter eines Konkurrenzprodukts, und elf Schwachstellen sind eine sehr kleine Grundlage. Als Rangliste ist das nicht belastbar. Als Richtungsangabe schon — und die lautet, dass eine allgemeine Abwehr WordPress-spezifische Angriffe grossenteils durchlässt. Wirksam ist ein Regelsatz, der die einzelne Schwachstelle kennt, und der ist ein kostenpflichtiges Abonnement. Eine unabhängige Messung, ob solche Regelsätze halten, was sie versprechen, haben wir nicht gefunden; die verfügbaren Zahlen stammen jeweils vom Verkäufer.
Zwei verbreitete Empfehlungen fehlen in der Tabelle mit Absicht. «Die betroffene Funktion abschalten» steht in fast jeder Anleitung, lässt sich aber bei den wenigsten Erweiterungen umsetzen — ein einzelner verwundbarer Endpunkt ist selten separat abschaltbar. Real ist die Wahl zwischen Erweiterung aktiv und Erweiterung deaktiviert. Und der Schutz des Anmeldebereichs — eigene Adresse für die Anmeldung, Passwortschutz auf wp-admin — wirkt nur gegen Angriffe, die den Adminbereich brauchen. Die massenhaft ausgenutzten Lücken kommen ohne ihn aus; sie sprechen Schnittstellen an, die eine Website öffentlich anbietet.
Wenig bis nichts bewirken gegen eine Lücke in einer Erweiterung ausserdem: die WordPress-Versionsnummer verbergen, die Anmeldeadresse umbenennen, die alte Schnittstelle XML-RPC abschalten, ganze Länder sperren. Diese Massnahmen stehen auf vielen Checklisten und verringern das Grundrauschen an Anfragen; auf den Programmfehler in einem Plugin haben sie keinen Einfluss. Wer sie einsetzt, sollte sie nicht als Schutz verbuchen.
Die wirksamste Massnahme in dieser Aufstellung ist keine Software. Ein Plugin, das nicht installiert ist, hat keine Schwachstellen. Wie ein Rückbau ohne Ausfall abläuft, beschreibt unser Beitrag zu sicher durchgeführten WordPress-Updates. Der Rückbau einer über Jahre gewachsenen Installation auf das, was tatsächlich gebraucht wird, senkt die Angriffsfläche stärker als jedes Schutzwerkzeug — und er ist die einzige Massnahme in dieser Tabelle, die anschliessend keine laufenden Kosten verursacht.
Was ein KMU getrost lassen kann
Ebenso wichtig ist die Gegenrichtung. Für eine gewöhnliche Firmenwebsite ohne Kundenkonten, ohne Shop und ohne Fremdredaktion ist folgendes nicht nötig:
- Das Verfolgen von Schwachstellenmeldungen. Bei über elftausend Meldungen im Jahr ist eine manuelle Beobachtung weder leistbar noch sinnvoll. Wer sie trotzdem betreibt, liest überwiegend über Erweiterungen, die er nicht einsetzt.
- Eine Reaktion auf jede Meldung zu einem eingesetzten Plugin. Vier von fünf Meldungen haben mittleren Schweregrad und setzen ein Konto voraus. Ohne Fremdkonten sind sie auf Ihrer Website nicht ausnutzbar. Das normale Update im nächsten Wartungsfenster genügt.
- Mehrere Sicherheits-Plugins nebeneinander. Sie überschneiden sich in der Funktion, verlangsamen die Website und erzeugen widersprüchliche Meldungen. Eines, richtig eingestellt, leistet mehr als drei.
- Ein Wechsel weg von WordPress aus Sicherheitsgründen. Fünf Meldungen im Kern eines ganzen Jahres sind eine sehr gute Bilanz. Wer WordPress wegen der Schwachstellenzahlen verlässt, verlässt es wegen der Erweiterungen, die er selbst installiert hat.
Was bleibt, ist eine kurze Liste: aktuelle Software, keine unbenutzten Erweiterungen, wenige Konten mit starker Anmeldung, eine geprüfte Sicherung und jemand, der bei den wenigen dringenden Fällen im Jahr innerhalb von Stunden erreichbar ist. Mehr braucht eine gewöhnliche Firmenwebsite nicht.
Für Agenturen: die Ausnahme organisieren
Wer einen Bestand betreut, hat den Regelbetrieb meist im Griff. Was fehlt, ist der Ausnahmeweg. Drei Punkte entscheiden darüber, ob er im Ernstfall funktioniert:
- Ein Verzeichnis, das die Frage «wer ist betroffen» in Minuten beantwortet. Welche Installation setzt welche Erweiterung in welcher Version ein? Ohne diese Liste beginnt jede Meldung mit einer Bestandsaufnahme, und genau die kostet die Stunden, auf die es ankommt.
- Eine Vorabklärung, wer im Ernstfall entscheiden darf. Die Abwägung zwischen «Funktion sofort abschalten» und «auf die Korrektur warten» ist eine Kundenentscheidung. Wird sie erst im Ereignisfall geklärt, vergeht der Vorsprung in der Abstimmung.
- Eine Regel, die den Ausnahmeweg auslöst. Sinnvoll ist ein enger Zuschnitt: ohne Anmeldung ausnutzbar, in einer eingesetzten Erweiterung, mit öffentlich verfügbarer Beschreibung. Alles andere läuft im Regelbetrieb. Ein Ausnahmeweg, der zu oft ausgelöst wird, wird nach kurzer Zeit ignoriert.
Wir übernehmen diesen Betrieb auch unter fremder Marke für Agenturen, die ihn nicht selbst aufbauen wollen. Der Umfang steht unter Support und Wartung.
Häufige Fragen
Woher weiss ich, ob mich eine Meldung überhaupt betrifft?
Nur über ein Verzeichnis Ihrer Erweiterungen samt Versionsnummern. Ohne diese Liste ist jede Schwachstellenmeldung wertlos, weil die erste Frage — «setzen wir das ein, und in welcher Fassung?» — nicht beantwortbar ist. Für eine einzelne Website genügt die Plugin-Übersicht im Adminbereich, einmal im Quartal als Bildschirmfoto oder Ausdruck. Wer mehrere Websites betreut, braucht eine gemeinsame Liste; genau daran entscheidet sich später, ob eine dringende Meldung in Minuten oder in Tagen abgearbeitet ist.
Ist WordPress unsicherer als andere Systeme?
Die Zahlen sagen dazu nichts. Sie messen, wie viele Schwachstellen gefunden und veröffentlicht werden — und das hängt davon ab, wie viele Menschen suchen und wie gut die Meldewege sind. WordPress hat beides in ungewöhnlichem Ausmass: ein grosses Ökosystem, zwei Vergabestellen für CVE-Kennungen und mehrere Programme, die das Melden belohnen. Eine hohe Fundzahl ist zunächst ein Zeichen für Aufmerksamkeit, nicht für schlechte Software.
Woran erkenne ich ein nicht mehr gepflegtes Plugin?
Im WordPress-Verzeichnis stehen bei jedem Plugin das Datum der letzten Aktualisierung und die WordPress-Version, mit der es zuletzt getestet wurde. Liegt die letzte Aktualisierung mehr als ein Jahr zurück oder ist die getestete Version zwei Hauptversionen alt, sollten Sie die Erweiterung ersetzen. Ein deutlicheres Zeichen ist der Hinweis, das Plugin sei für Installationen geschlossen — dann sollten Sie es umgehend entfernen.
Automatische Updates einschalten oder nicht?
Für Sicherheitsaktualisierungen des WordPress-Kerns: ja, sie sind ab Werk aktiv und sollten es bleiben. Für Plugins ist die Antwort abhängig von der Website. Automatische Plugin-Updates verkürzen das Zeitfenster erheblich, können aber eine Funktion brechen, ohne dass es jemand bemerkt. Sinnvoll ist die Kombination aus automatischen Updates und einer Überwachung, die meldet, wenn die Website danach nicht mehr richtig antwortet. Ohne diese Überwachung tauschen Sie ein Sicherheitsrisiko gegen ein Ausfallrisiko.
Ersetzt eine Firewall die Updates?
Nein. Sie überbrückt die Zeit, bis eine Korrektur vorliegt und eingespielt ist, und sie hilft dort, wo es nie eine Korrektur geben wird. Ihre Regeln entstehen jedoch erst, nachdem eine Schwachstelle bekannt geworden ist; gegen das Unbekannte wirkt sie nicht. Eine Firewall ist eine Ergänzung des Update-Betriebs, kein Ersatz.
Was mache ich mit einem Plugin, das eine offene Lücke hat und für das es keinen Ersatz gibt?
Es gibt drei Wege, und keiner davon ist ohne Aufwand. Erstens: die betroffene Funktion abschalten, sofern sich die Lücke auf einen abgrenzbaren Teil bezieht. Zweitens: den Zugriff einschränken, etwa indem die betroffene Adresse nur noch aus dem Firmennetz erreichbar ist. Drittens: die Funktion neu bauen lassen. Der vierte Weg — abwarten und hoffen — ist bei einer ohne Anmeldung ausnutzbaren Lücke keiner.
Sind die Zahlen auf die Schweiz übertragbar?
Ja, ohne Einschränkung. Schwachstellen in Software kennen keine Landesgrenzen, und die automatisierten Angriffe, um die es hier geht, wählen ihre Ziele nach technischen Merkmalen aus, nicht nach Standort. Unterschiedlich ist allein die Rechtslage im Schadensfall — insbesondere die Frage, wann eine Kompromittierung nach dem revidierten Datenschutzgesetz gemeldet werden muss.
Fazit
Elftausend Schwachstellen im Jahr sind keine Aussage über Ihre Website. Die Zahl, die etwas aussagt, ist klein: ein einstelliger Prozentsatz gilt als hochgefährlich, fast alles davon sitzt in Erweiterungen, und der grösste Teil betrifft Software, die kaum jemand einsetzt. Für eine gepflegte KMU-Website mit wenigen, aktiv betreuten Erweiterungen ist die Lage deutlich ruhiger, als die Berichterstattung nahelegt.
Was bleibt, ist eine kleine Zahl von Fällen im Jahr, in denen Stunden über den Ausgang entscheiden — und in denen ein monatlicher Wartungstermin nichts ausrichtet. Diese Fälle brauchen kein grösseres Wartungspaket, sondern eine andere Organisation: die Frage «betrifft uns das?» muss in Minuten beantwortbar sein, und es muss vorher feststehen, wer entscheidet. Wer beides hat, ist besser aufgestellt als jemand, der wöchentlich aktualisiert und im Ernstfall zwei Tage mit der Bestandsaufnahme verbringt.
Sollte es Sie doch einmal treffen, steht das Vorgehen für die ersten Stunden in einem eigenen Beitrag: WordPress gehackt — so bereinigen Sie richtig. Wenn Sie dagegen nicht wissen, welche Erweiterungen auf Ihrer Website laufen, welche davon noch gepflegt werden und welche Sie ohne Verlust entfernen könnten: Schicken Sie uns die Adresse. Sie erhalten innert einem Werktag eine Einschätzung — auch dann, wenn sie lautet, dass wir nichts zu tun finden. Was laufender Betrieb bei uns umfasst, steht unter Support und Wartung; der direkte Weg führt über das Kontaktformular.
Quellen
- Patchstack: State of WordPress Security in 2026 ↗ — Berichtsjahr 2025; Quelle für 11’334 Meldungen, die Verteilung 91 zu 9 Prozent, die 46 Prozent ohne Korrektur bei Offenlegung und den gewichteten Median von fünf Stunden
- Wordfence: 2024 Annual WordPress Vulnerability and Threat Report ↗ — Berichtsjahr 2024, erschienen im April 2025; Quelle für 8’223 Meldungen, 7,4 Prozent hochgefährlich, über 68 Prozent risikoarm, 81 Prozent mittlerer Schweregrad, 96 Prozent in Plugins, fünf Meldungen im Kern und die Verteilung nach Installationszahl
- Patchstack: Hosting security tested ↗ — Test von fünf Hosting-Anbietern gegen elf Plugin-Schwachstellen, veröffentlicht am 21. August 2025; Quelle für die 87,8 Prozent. Vom Anbieter eines Konkurrenzprodukts durchgeführt, kleine Grundgesamtheit — im Beitrag entsprechend eingeordnet
- Wordfence: Ankündigung des Jahresberichts 2024 ↗ — Einordnung des Berichts durch den Herausgeber
Stand: 28. August 2026. Die beiden Auswertungen decken unterschiedliche Berichtsjahre ab und zählen nach unterschiedlichen Verfahren; ihre Werte sind nebeneinandergestellt, aber nicht miteinander verrechnet. Erscheint ein Wordfence-Jahresbericht für 2025, gleichen wir die Zahlen ab und halten Abweichungen hier fest.



