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.
| Kennung | Art der Lücke | Betroffen bis | Behoben in |
|---|---|---|---|
| CVE-2026-78159 | Einschleusung von Programmcode über die Darstellungsklassen eines Widgets | 6.17.3 | 6.17.3.1 (26. August) |
| CVE-2026-78006 | PHP Object Injection über eingeschleuste Widget-Daten | 6.17.4 | 6.17.4.1 (10. September) |
| Datum 2026 | Ereignis |
|---|---|
| 20. August | Version 6.17.3 schliesst eine ältere Lücke an derselben Stelle (CVE-2026-78265) |
| 21. August | Wordfence meldet die erste Lücke (CVE-2026-78006) an StellarWP |
| 22. August | Firewall-Regel für zahlende Wordfence-Kunden |
| 23. August | Wordfence meldet die zweite Lücke (CVE-2026-78159) |
| 24. August | StellarWP bestätigt beide Meldungen |
| 26. August | Version 6.17.3.1 — schliesst CVE-2026-78159 |
| 3. September | Version 6.17.4 — Fehlerkorrekturen, laut Änderungsprotokoll ohne Sicherheitsbezug |
| 10. September | Version 6.17.4.1 — schliesst CVE-2026-78006 |
| 12. September | CVE-Einträge öffentlich, Angriffsprogramm auf GitHub |
| 14. September | Wordfence veröffentlicht die technischen Einzelheiten |
| 21. September | Firewall-Regel auch für Nutzer der Gratisversion von Wordfence |
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 Version | CVE-2026-78159 | CVE-2026-78006 |
|---|---|---|
| 6.17.3 und älter | offen | offen |
| 6.17.3.1 | geschlossen | offen |
| 6.17.4 | geschlossen | offen |
| 6.17.4.1 und neuer | geschlossen | geschlossen |
Wie der Angriff abläuft
Beide Lücken nutzen denselben Einlieferungsweg und trennen sich erst im letzten Schritt. Vereinfacht:
- 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.
- 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.
- 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.
- 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.
- 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:
| Bedingung | Bedeutung für Ihre Website |
|---|---|
| Plugin-Version bis 6.17.4 | Notwendig. Ab 6.17.4.1 sind beide Wege geschlossen. |
| Einstellung «Kommentare anzeigen» eingeschaltet | Zu finden unter Veranstaltungen → Einstellungen → Darstellung, ab Werk ausgeschaltet. Ohne sie haben Veranstaltungen keinen Kommentarbereich. |
| Kommentare an der Veranstaltung offen | Kommentare lassen sich je Veranstaltung schliessen. Wo sie geschlossen sind, fehlt der Einlieferungsweg. |
| Kommentieren ohne Anmeldung möglich | Verlangt die Website für Kommentare eine Anmeldung und können sich Fremde nicht selbst registrieren, fehlt einem anonymen Angreifer der Zugang. |
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:
| Versionszweig | Anteil am 15. September 2026 |
|---|---|
| 6.17 (alle Versionen von 6.17.0 bis 6.17.4.1) | 55,54 Prozent |
| 6.15 | 12,89 Prozent |
| alle übrigen, zusammengefasst | 31,57 Prozent |
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
- 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.
- 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.
- 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.
- Kommentare durchsuchen. Geben Sie unter Kommentare im Suchfeld
legacy-widgetein, 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. - 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
showCommentsin der Optiontribe_events_calendar_options, abzufragen mitwp 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_Classesnur noch echte Closures auf, beschränkt die Rückruffunktionen vonLazy_Post_Collectionauf drei feste Namen und akzeptiert als Widget-Daten nur noch ein einfaches Array. 6.17.4.1 entfernt den Aufruf vondo_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
- Wordfence: Wordfence Argus Identifies Two Critical Unauthenticated Vulnerability Chains Leading to Remote Code Execution in The Events Calendar Plugin ↗ — Bericht vom 14. September 2026; Quelle für den Ablauf beider Ketten, die Voraussetzungen, die Meldedaten und die Termine der Firewall-Regel
- CVE.org: CVE-2026-78006 ↗ — betroffene Versionen bis 6.17.4, Schweregrad 9,8, Vorschau ausstehender Kommentare als Auslöser ohne Freigabe
- CVE.org: CVE-2026-78159 ↗ — betroffene Versionen bis 6.17.3, Schweregrad 9,8, Kommentare an Veranstaltungen als Voraussetzung
- Patchstack: The Events Calendar <= 6.17.4 — PHP Object Injection ↗ und <= 6.17.3 — Code Injection ↗ — Korrekturversionen 6.17.4.1 und 6.17.3.1, Vermerk «Known to be exploited»
- Patchstack: The Events Calendar <= 6.17.2 — PHP Object Injection ↗ — die ältere Lücke CVE-2026-78265, veröffentlicht am 24. August 2026, behoben in 6.17.3
- wordpress.org: The Events Calendar ↗ — offizielles Verzeichnis; Quelle für mehr als 600’000 aktive Installationen und die Erscheinungsdaten der Versionen im Änderungsprotokoll
- api.wordpress.org: Versionsstatistik des Plugins ↗ — die offene Schnittstelle, aus der die Werte der Tabelle stammen; eigener Abruf am 15. September 2026
- SecurityOnline: The Events Calendar Vulnerability Exploited in the Wild ↗ — Bericht vom 15. September 2026; Quelle der Angabe «1113 Angriffe in 24 Stunden»
- CISA: Known Exploited Vulnerabilities Catalog ↗ — Katalogstand vom 14. September 2026, keine der drei Kennungen enthalten
- Wordfence: Wordfence Argus — Moving Beyond Human Research Capability ↗ — Vorstellung des Analysesystems Argus vom 27. August 2026
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.



