+41 41 589 67 78Antwort innert 1 Werktag

Kostenlos anfragen

StartseiteBlog

Lesezeit: 15 Minuten

The Events Calendar: Zwei kritische Lücken über die Kommentarfunktion — erst 6.17.4.1 schliesst beide

Zwei kritische Lücken im Plugin The Events Calendar erlauben die Übernahme einer WordPress-Website über einen einzigen Kommentar — ohne Konto und ohne Freigabe. Erst Version 6.17.4.1 vom 10. September 2026 schliesst beide, 6.17.4 genügt nicht.

Daniel Alzer

Daniel Alzer

WP Profis, Stans

Im Veranstaltungs-Plugin The Events Calendar stecken zwei kritische Lücken, über die ein Unbekannter ohne Konto die ganze Website übernehmen kann — mit einem einzigen Kommentar unter einer Veranstaltung. Die Freigabe durch einen Moderator ist dafür nicht nötig. Angreifbar sind Websites, auf denen Veranstaltungen kommentiert werden können; dort ist die Lage ernst, denn seit dem 12. September liegt Angriffscode öffentlich vor. Der Hersteller hat die Lücken in zwei Schritten geschlossen, und daraus entsteht eine Falle: Wer Anfang September auf 6.17.4 aktualisiert hat, ist gegen eine der beiden weiterhin offen.

Das Wichtigste in Kürze

  • Erst Version 6.17.4.1 schliesst beide Lücken. Version 6.17.3.1 vom 26. August behebt CVE-2026-78159. Die zweite Lücke, CVE-2026-78006, bleibt bis einschliesslich 6.17.4 offen und ist erst seit dem 10. September korrigiert.
  • Ein anonymer Kommentar genügt, eine Freigabe ist nicht nötig. WordPress zeigt dem Verfasser seinen noch nicht freigegebenen Kommentar sofort an. Diese Vorschau löst den Angriff aus. Die Kommentarmoderation schützt deshalb nicht.
  • Angreifbar sind Websites mit kommentierbaren Veranstaltungen. Die dafür nötige Plugin-Einstellung «Kommentare anzeigen» ist ab Werk ausgeschaltet. Wer sie nie eingeschaltet hat, ist über diesen Weg nicht angreifbar — das Update gehört trotzdem eingespielt.
  • Angriffscode ist öffentlich, Angriffe sind gemeldet, aber nicht belegt. Patchstack führt beide Lücken als ausgenutzt, eine Fachseite nennt 1113 abgewehrte Angriffe an einem Tag. Beide Angaben kommen ohne überprüfbare Einzelheiten, und im Bericht von Wordfence, das die Lücken gefunden hat, steht davon nichts.
  • Die Zahl 600’000 beschreibt Installationen, nicht Opfer. Laut Versionsstatistik von wordpress.org laufen mindestens 44 Prozent davon auf einem Versionszweig vor 6.17 — rechnerisch rund 266’000 Installationen mit verwundbarer Version. Wie viele davon Kommentare erlauben, ist nirgends erhoben.

Was veröffentlicht wurde

The Events Calendar des Herstellers StellarWP ist eines der verbreitetsten Kalender-Plugins für WordPress. Das offizielle Verzeichnis auf wordpress.org weist am 15. September 2026 mehr als 600’000 aktive Installationen aus. Das Plugin ist zugleich das Grundmodul für die kostenpflichtige Erweiterung Events Calendar Pro, die ohne die Gratisversion nicht läuft.

Am 14. September 2026 veröffentlichte der Sicherheitsanbieter Wordfence die technischen Einzelheiten zu zwei Lücken. Gefunden hat sie Argus, ein automatisiertes Analysesystem von Wordfence; das Forschungsteam des Anbieters hat die Funde bestätigt, bevor sie an den Hersteller gingen. Beide Lücken tragen den Schweregrad 9,8 von 10, die Stufe «kritisch». Ihre Kennungen sind seit dem 12. September öffentlich.

KennungArt der LückeBetroffen bisBehoben in
CVE-2026-78159Einschleusung von Programmcode über die Darstellungsklassen eines Widgets6.17.36.17.3.1 (26. August)
CVE-2026-78006PHP Object Injection über eingeschleuste Widget-Daten6.17.46.17.4.1 (10. September)
Betroffene Versionen laut Wordfence und den CVE-Einträgen, Erscheinungsdaten laut Änderungsprotokoll im Plugin-Verzeichnis. Beide Lücken sind ohne Anmeldung ausnutzbar.
Datum 2026Ereignis
20. AugustVersion 6.17.3 schliesst eine ältere Lücke an derselben Stelle (CVE-2026-78265)
21. AugustWordfence meldet die erste Lücke (CVE-2026-78006) an StellarWP
22. AugustFirewall-Regel für zahlende Wordfence-Kunden
23. AugustWordfence meldet die zweite Lücke (CVE-2026-78159)
24. AugustStellarWP bestätigt beide Meldungen
26. AugustVersion 6.17.3.1 — schliesst CVE-2026-78159
3. SeptemberVersion 6.17.4 — Fehlerkorrekturen, laut Änderungsprotokoll ohne Sicherheitsbezug
10. SeptemberVersion 6.17.4.1 — schliesst CVE-2026-78006
12. SeptemberCVE-Einträge öffentlich, Angriffsprogramm auf GitHub
14. SeptemberWordfence veröffentlicht die technischen Einzelheiten
21. SeptemberFirewall-Regel auch für Nutzer der Gratisversion von Wordfence
Die Zeitleiste im Bericht von Wordfence nennt für die Korrekturen den 25. August und den 1. September. Das passt weder zur Versionstabelle desselben Berichts noch zum Änderungsprotokoll des Herstellers; massgeblich sind hier die Daten des Herstellers.

Warum 6.17.4 nicht reicht

Zwischen dem 20. August und dem 10. September sind drei Versionen mit Sicherheitskorrekturen erschienen, und ihre Nummern lassen sich leicht verwechseln. Wer am 3. September auf 6.17.4 aktualisiert hat, durfte das als erledigt betrachten. Gegen CVE-2026-78006 ist diese Website trotzdem offen, bis 6.17.4.1 eingespielt ist.

Installierte VersionCVE-2026-78159CVE-2026-78006
6.17.3 und älteroffenoffen
6.17.3.1geschlossenoffen
6.17.4geschlossenoffen
6.17.4.1 und neuergeschlossengeschlossen
Die vierte Stelle der Versionsnummer entscheidet. Wer Plugin-Stände nur nach den ersten drei Stellen erfasst, übersieht die massgebliche Korrektur.

Wie der Angriff abläuft

Beide Lücken nutzen denselben Einlieferungsweg und trennen sich erst im letzten Schritt. Vereinfacht:

  1. Kommentar schreiben. Der Angreifer öffnet eine Veranstaltung, unter der kommentiert werden kann, und schickt einen Kommentar ab. Darin steht kein gewöhnlicher Text, sondern die Auszeichnung eines Blocks aus dem Block-Editor, genauer eines älteren Widgets des Plugins. Der Filter, mit dem WordPress Kommentare anonymer Besucher bereinigt, lässt diese Auszeichnung stehen, weil sie formal ein HTML-Kommentar ist.
  2. Die eigene Vorschau aufrufen. Nach dem Absenden leitet WordPress den Verfasser auf eine Adresse weiter, unter der er seinen noch nicht freigegebenen Kommentar sehen kann. Ein Moderator muss dafür nichts tun.
  3. Das Plugin liest den Kommentar als Block. The Events Calendar schickt die gesamte Veranstaltungsseite samt Kommentarbereich durch den Block-Parser. WordPress selbst tut das mit Kommentaren nicht. Aus dem Text im Kommentar wird so ein Widget, das tatsächlich ausgeführt und dargestellt wird.
  4. Das Plugin beglaubigt die fremden Daten. WordPress sichert gespeicherte Widget-Daten mit einer Prüfsumme ab, bevor es sie entpackt. Das Plugin ersetzt die Prüfsumme aus dem Kommentar durch eine frisch berechnete, gültige. Die einzige Sicherung des WordPress-Kerns an dieser Stelle läuft damit ins Leere.
  5. Ausführen. Hier trennen sich die Wege. Bei CVE-2026-78006 schmuggelt der Angreifer ein präpariertes PHP-Objekt an einer fehlerhaften Prüfung vorbei und lässt beliebige Befehle auf dem Server ausführen. Bei CVE-2026-78159 genügt ein gewöhnliches Datenfeld: Darüber ruft das Plugin eine WordPress-Funktion auf, die das Passwort des ersten Benutzerkontos auf einen bekannten Wert setzt. Danach meldet sich der Angreifer als Administrator an und lädt ein eigenes Plugin hoch.

Wordfence hat beide Ketten ausführlich beschrieben, für den zweiten Weg einschliesslich der Datenstruktur, die den Passwortwechsel auslöst. Die Hürde für einen Nachbau ist damit niedrig.

Wer betroffen ist — und wer nicht

Die Lücken sind kritisch, aber an Bedingungen geknüpft. Für einen erfolgreichen Angriff müssen alle vier zutreffen:

BedingungBedeutung für Ihre Website
Plugin-Version bis 6.17.4Notwendig. Ab 6.17.4.1 sind beide Wege geschlossen.
Einstellung «Kommentare anzeigen» eingeschaltetZu finden unter Veranstaltungen → Einstellungen → Darstellung, ab Werk ausgeschaltet. Ohne sie haben Veranstaltungen keinen Kommentarbereich.
Kommentare an der Veranstaltung offenKommentare lassen sich je Veranstaltung schliessen. Wo sie geschlossen sind, fehlt der Einlieferungsweg.
Kommentieren ohne Anmeldung möglichVerlangt die Website für Kommentare eine Anmeldung und können sich Fremde nicht selbst registrieren, fehlt einem anonymen Angreifer der Zugang.
Die Kommentarmoderation fehlt in dieser Liste mit Absicht: Sie hält den Angriff nicht auf, weil die Vorschau des eigenen Kommentars vor jeder Freigabe greift.

Wie viele Websites Kommentare unter Veranstaltungen zulassen, erhebt keine öffentliche Quelle. Ob eine bestimmte Website dazugehört, sieht dagegen jeder Besucher: Das Kommentarformular steht sichtbar unter der Veranstaltung. Die Suche nach angreifbaren Zielen ist damit einfach, und wer betroffen ist, ist ohne jede weitere Hürde angreifbar.

Auch ohne Kommentarfunktion bleibt das Update nötig. Die Einstellung lässt sich jederzeit einschalten, von jemandem, der an die Lücke nicht denkt — und der fehlerhafte Code steckt unabhängig davon im Plugin.

Woher die Zahl «600’000» kommt

Die Zahl stammt aus dem Plugin-Verzeichnis von wordpress.org und bezeichnet aktive Installationen, abgerundet auf eine Stufe. Wie viele davon verwundbar sind, sagt sie nicht. Dafür gibt es eine zweite öffentliche Angabe, die Verteilung der Versionen. Unser Abruf vom 15. September 2026 über api.wordpress.org/stats/plugin/1.0/the-events-calendar ergab:

VersionszweigAnteil am 15. September 2026
6.17 (alle Versionen von 6.17.0 bis 6.17.4.1)55,54 Prozent
6.1512,89 Prozent
alle übrigen, zusammengefasst31,57 Prozent
Versionsverteilung laut der offiziellen Statistik-Schnittstelle von wordpress.org. Sie unterscheidet nur Versionszweige, nicht einzelne Korrekturversionen.

Ablesen lässt sich daraus eine Untergrenze. Alles ausserhalb des Zweigs 6.17 ist älter und damit verwundbar: zusammen 44,46 Prozent. Auf 600’000 Installationen gerechnet sind das rund 266’000 Websites — da das Verzeichnis abrundet, eher mehr. Wie viele der übrigen 55,54 Prozent schon auf 6.17.4.1 laufen, zeigt die Statistik nicht. Die tatsächliche Zahl verwundbarer Installationen liegt also höher. Wie viele davon tatsächlich angreifbar sind, lässt sich aus keiner öffentlichen Quelle ablesen.

Was über Angriffe bekannt ist

Hier gehen die Quellen auseinander. Einzeln betrachtet ergibt sich folgendes Bild:

  • Angriffscode ist öffentlich. Seit dem 12. September 2026 liegt auf GitHub ein Python-Skript von gut 20 Kilobyte, das nach eigener Beschreibung die Lücke CVE-2026-78006 ausnutzt. Wir haben es nicht ausgeführt und verlinken es nicht.
  • Patchstack führt beide Lücken als ausgenutzt. Die Einträge in der Schwachstellen-Datenbank des Anbieters tragen den Vermerk «Known to be exploited». Worauf sich das stützt, steht dort nicht. Beim Eintrag zur älteren Lücke CVE-2026-78265 fehlt der Vermerk; er ist also kein Textbaustein, der auf jeder Seite steht.
  • Eine Fachseite nennt eine Zahl. SecurityOnline schreibt am 15. September, Wordfence habe in 24 Stunden 1113 Angriffe auf die Lücke abgewehrt. Einen Beleg verlinkt der Artikel nicht, und im Bericht von Wordfence vom Vortag steht davon nichts.
  • Die US-Behörde CISA führt die Lücken nicht. Ihr Katalog ausgenutzter Schwachstellen enthält am 14. September 2026 keine der drei Kennungen. Aussagekräftig ist das wenig: Von 1710 Einträgen betreffen sechs WordPress.

Unsere Einordnung: Aktive Angriffe sind gemeldet, aber nicht überprüfbar belegt. Für die Entscheidung spielt das keine Rolle. Öffentlicher Angriffscode, keine Anmeldung, kein Freigabeschritt und ein von aussen erkennbares Ziel — unter diesen Umständen ist eine betroffene Website so zu behandeln, als würde sie bereits angegriffen.

Drei Korrekturen an derselben Stelle

Die beiden Lücken haben eine Vorgeschichte, die im Bericht von Wordfence nicht vorkommt. Am 20. August erschien Version 6.17.3 mit dem knappen Vermerk, die Prüfung kopierter Widget-Daten sei verschärft worden. Damit schloss der Hersteller eine Lücke, die ein Forscher über das Bug-Bounty-Programm von Patchstack gemeldet hatte: CVE-2026-78265, ebenfalls eine PHP Object Injection ohne Anmeldung, öffentlich seit dem 24. August.

Genau diese neue Prüfung ist die Stelle, an der beide Wordfence-Ketten ansetzen. Die eine täuscht sie; die andere muss sie nicht einmal täuschen, weil die Prüfung nur nach Objekten sucht und gewöhnliche Daten durchlässt. Wordfence meldete die erste Umgehung einen Tag nach dem Erscheinen von 6.17.3. Der Hersteller korrigierte danach in zwei Schritten, und erst der zweite setzt an der Ursache an: Seit 6.17.4.1 schickt das Plugin die Veranstaltungsseite nicht mehr als Ganzes durch den Block-Parser, und es beglaubigt nur noch Widget-Daten, die es selbst neu aufgebaut hat.

Dem Hersteller ist dabei wenig vorzuwerfen. Er hat beide Meldungen innert drei Tagen bestätigt, und die erste Korrektur lag fünf Tage nach der ersten Meldung vor. Zwei Beobachtungen bleiben trotzdem. Erstens: Eine frische Korrektur zeigt, wo weitere Fehler zu suchen sind — für Angreifer ebenso wie für Forscher. Zweitens: Das Tempo steigt. Argus hat im selben Sommer auch die Lücke im Verwaltungs-Plugin von WPMU DEV gefunden, die wir in Der Generalschlüssel: Wenn das Verwaltungswerkzeug der Agentur zum Einfallstor wird beschrieben haben. Wer Updates einmal im Monat einspielt, wäre hier zwischen dem 20. August und dem 10. September jedes Mal eine Version im Rückstand gewesen.

In fünf Minuten selbst prüfen

  1. Version feststellen. Öffnen Sie Plugins → Installierte Plugins und suchen Sie «The Events Calendar». Steht dort eine Version unter 6.17.4.1 — auch 6.17.4 —, ist Handlung nötig. Ist das Plugin nicht installiert, sind Sie an dieser Stelle fertig.
  2. Aktualisieren. Über Dashboard → Aktualisierungen. Nutzen Sie Events Calendar Pro oder weitere Erweiterungen desselben Herstellers, aktualisieren Sie diese im selben Durchgang; sie setzen eine passende Version des Grundmoduls voraus.
  3. Einstellung prüfen. Unter Veranstaltungen → Einstellungen → Darstellung steht der Schalter «Kommentare anzeigen». Brauchen Sie keine Kommentare unter Veranstaltungen, schalten Sie ihn aus. Das ersetzt das Update nicht, verkleinert aber die Angriffsfläche dauerhaft.
  4. Kommentare durchsuchen. Geben Sie unter Kommentare im Suchfeld legacy-widget ein, zuerst in der Ansicht «Alle», danach unter «Spam». Ein gewöhnlicher Besucherkommentar enthält diese Zeichenfolge nicht. Ein Treffer ist ein deutlicher Hinweis auf einen Angriffsversuch — ob er Erfolg hatte, zeigt er nicht.
  5. Konten und Plugins prüfen. Funktioniert das Passwort des ersten Administratorkontos nicht mehr, oder stehen unter Benutzer und Plugins Einträge, die niemand angelegt hat, gehen Sie von einer Übernahme aus. Wie eine Bereinigung abläuft, steht in WordPress gehackt nach wp2shell: der Bereinigungsablauf.

Für Agenturen und Entwickler

  • Inventar nach der vierten Stelle. Die massgebliche Korrektur ist eine Korrekturversion auf der Linie 6.17.4. Ein Abgleich, der Plugin-Stände nach «6.17.4» gruppiert, meldet eine verwundbare Website als aktuell. Den genauen Stand liefert wp plugin get the-events-calendar --field=version.
  • Kommentareinstellung mit erfassen. Ob eine Website angreifbar war, entscheidet der Schlüssel showComments in der Option tribe_events_calendar_options, abzufragen mit wp option pluck tribe_events_calendar_options showComments. Wer eine Flotte prüft, liest ihn mit aus und weiss danach, welche Websites zusätzlich auf Spuren untersucht werden müssen.
  • Firewall-Regeln überbrücken, sie ersetzen nichts. Wordfence schützt zahlende Kunden seit dem 22. August, die Gratisversion erst ab dem 21. September. Die Regel richtet sich nach Angabe von Wordfence gegen bekannte Angriffsmuster.
  • Was die Korrekturen im Code ändern. Ein eigener Vergleich der Plugin-Pakete zeigt: 6.17.3.1 ruft in der Klasse Element_Classes nur noch echte Closures auf, beschränkt die Rückruffunktionen von Lazy_Post_Collection auf drei feste Namen und akzeptiert als Widget-Daten nur noch ein einfaches Array. 6.17.4.1 entfernt den Aufruf von do_blocks() über den gepufferten Inhalt der Einzelansicht und signiert nur noch Daten, die das Plugin selbst neu serialisiert hat. Eigene Vorlagen, die sich darauf verlassen haben, dass Blöcke im Kommentarbereich der Einzelansicht gerendert werden, verhalten sich danach anders.

Fazit

Prüfen Sie die Version und lassen Sie sich von 6.17.4 nicht täuschen: Erst 6.17.4.1 schliesst beide Lücken. Ist die Kommentarfunktion unter Veranstaltungen eingeschaltet, gehört ein Blick in die Kommentare, die Benutzerliste und die Plugin-Liste dazu.

Über den Einzelfall hinaus zeigt die Lücke, wie wenig eine Moderation schützt, sobald ein Plugin Eingaben anders verarbeitet, als WordPress es vorsieht. Ein Kommentarformular nimmt Inhalte von beliebigen Besuchern entgegen. Jede zusätzliche Verarbeitung dieser Inhalte vergrössert die Angriffsfläche — auch dann, wenn nichts davon je öffentlich erscheint.

Wenn Sie nicht sicher sind, ob Ihre Website betroffen ist: Schicken Sie uns die Adresse. Wir sehen uns an, ob The Events Calendar läuft und ob Veranstaltungen kommentiert werden können, und melden uns innert einem Werktag mit einer Einschätzung — auch dann, wenn sie lautet, dass kein Handlungsbedarf besteht. Was wir laufend übernehmen, steht unter WordPress-Support und Wartung; der direkte Weg führt über das Kontaktformular.

Häufige Fragen

Unter unseren Veranstaltungen gibt es keine Kommentare. Müssen wir trotzdem aktualisieren?

Ja. Über den beschriebenen Weg ist Ihre Website derzeit nicht angreifbar, aber der fehlerhafte Code ist installiert. Die Einstellung «Kommentare anzeigen» kann später jemand einschalten, ohne an die Lücke zu denken. Ein Update auf 6.17.4.1 schliesst diese Möglichkeit, bevor sie entsteht.

Wir geben jeden Kommentar von Hand frei. Schützt uns das?

Nein. WordPress zeigt dem Verfasser seinen eigenen, noch nicht freigegebenen Kommentar über eine Vorschauadresse an. Genau beim Aufruf dieser Vorschau verarbeitet das Plugin den Kommentar und löst den Angriff aus. Die Freigabe kommt zu spät, weil der Schaden vorher entsteht.

Wir nutzen Events Calendar Pro. Sind wir betroffen?

Events Calendar Pro läuft nur zusammen mit dem Gratis-Plugin The Events Calendar, und die Lücken stecken in diesem Grundmodul. Massgeblich ist deshalb dessen Version. Aktualisieren Sie beide Plugins im selben Durchgang.

Auf unserer Website läuft Wordfence. Reicht das?

Als Überbrückung womöglich, als Dauerzustand nicht. Wordfence hat eine Firewall-Regel für beide Lücken ausgeliefert, zahlenden Kunden am 22. August, Nutzern der Gratisversion erst am 21. September. Bis dahin schützt die Gratisversion nicht. Eine Firewall-Regel erkennt bekannte Angriffsmuster; das Update beseitigt den Fehler.

Wir haben einen verdächtigen Kommentar gefunden. Was jetzt?

Geben Sie ihn nicht frei und löschen Sie ihn nicht sofort. Aktualisieren Sie zuerst auf 6.17.4.1 — ab dieser Version verarbeitet das Plugin Kommentare nicht mehr als Blöcke. Halten Sie danach Datum und Absenderadresse des Kommentars fest, wechseln Sie die Passwörter aller Administratoren und prüfen Sie Benutzer- und Plugin-Liste. Finden Sie Hinweise auf eine Übernahme, folgt eine vollständige Bereinigung.

Was bedeutet der Schweregrad 9,8?

Das ist der CVSS-Wert, eine Bewertung von 0 bis 10. Er setzt sich aus Merkmalen wie «über das Internet ausnutzbar», «ohne Anmeldung» und «vollständiger Kontrollverlust» zusammen. Ab 9,0 gilt eine Lücke als kritisch. Der Wert beschreibt das Schadenspotenzial im ungünstigsten Fall, nicht die Wahrscheinlichkeit, dass es Ihre Website trifft. Wie sich solche Zahlen einordnen lassen, steht in Elftausend Schwachstellen im Jahr: warum diese Zahl der falsche Massstab ist.

Quellen

Stand: 15. September 2026. Die Versionsanteile stammen aus einem eigenen Abruf der Statistik-Schnittstelle von wordpress.org am 15. September 2026 und ändern sich täglich. Die Angaben zu den Korrekturen im Code beruhen auf einem eigenen Vergleich der Plugin-Pakete 6.17.2 bis 6.17.4.1. Werden Angriffe belegt oder erscheinen weitere Korrekturen, ergänzen wir den Beitrag.

Daniel Alzer

Über den Autor

Daniel Alzer — Inhaber & Geschäftsführer, WP Profis

Entwickelt und betreut seit über zehn Jahren WordPress-Websites für KMU in der Schweiz, Deutschland und Österreich. Mehr über uns →

Sicherheitsproblem auf Ihrer Website?

In einer Erstdiagnose für CHF 170 (bis zu 60 Minuten, ohne Abo) sichten wir Symptome, vorhandene Sicherungen und Befunde und empfehlen die nächsten Schritte. Eine Bereinigung vereinbaren wir danach separat.