CVE-2026-78006 und CVE-2026-78159: The Events Calendar erlaubt Codeausführung ohne Login, so prüfen und patchen Sie Ihre WordPress-Seite

Veröffentlicht: 14.09.2026 · Letzte Aktualisierung: 14.09.2026

Was ist passiert

In dem WordPress-Plugin The Events Calendar sind zwei kritische Schwachstellen bekannt geworden, die es Angreifern ohne Anmeldung erlauben, beliebigen PHP-Code auf dem Server auszuführen. Betroffen sind mehr als 600.000 aktive Installationen, denn verwundbar ist jede Version bis einschließlich 6.17.4.

Beide Lücken tragen einen CVSS-Basiswert von 9.8 und damit die Einstufung kritisch. Gemeldet wurden sie von Chloe Chamberland und dem Team Wordfence Argus, das auch als CVE-Nummernvergabestelle für beide Einträge fungiert. Laut offiziellem CVE-Datensatz wurde der Hersteller am 21.08.2026 beziehungsweise am 23.08.2026 informiert, die Offenlegung erfolgte am 11.09.2026, die Veröffentlichung der CVE-Einträge am 12.09.2026.

Bemerkenswert ist die Kette der Security-Releases, die der Changelog auf WordPress.org dokumentiert. Am 20.08.2026 erschien Version 6.17.3 mit dem Eintrag „Hardened validation of copied legacy widget instances“. Am 26.08.2026 folgte 6.17.3.1 mit „Harden validation of copied widget instance data“. Am 03.09.2026 kam 6.17.4 ganz ohne Security-Eintrag. Erst 6.17.4.1 vom 10.09.2026 mit dem Vermerk „Strengthened validation of copied widget instances“ schließt beide Lücken.

Der Ablauf zeigt einen klassischen Patch-Bypass. Die erste Härtung in 6.17.3 griff zu kurz, die zweite in 6.17.3.1 schloss CVE-2026-78159, ließ aber den Weg für CVE-2026-78006 offen. Wer heute auf 6.17.3.1 oder 6.17.4 steht und sich in Sicherheit wiegt, weil in der Update-Historie bereits zwei Security-Releases stehen, ist weiterhin angreifbar.

Technische Details

CVE-2026-78159: Code Injection über Element_Classes::parse_array()

CVE-2026-78159 entsteht durch eine unzureichende Validierung der Widget-Map „classes“ und betrifft alle Versionen bis einschließlich 6.17.3. Ein Angreifer kann mit einem einfachen Array als Payload die Objektprüfung in is_safe_widget_instance() umgehen und erreicht damit eine Stelle im Code, an der ein übergebener Wert als aufrufbare Funktion behandelt wird, nämlich Element_Classes::parse_array().

Der Auslöser ist ein Kommentar, der einen präparierten Block vom Typ wp:legacy-widget enthält. Das Single-Event-Template der V2-Ansicht schickt das gepufferte HTML der Kommentarspalte durch do_blocks(). Damit wird der eingeschleuste Block beim Rendern der Event-Seite verarbeitet, und der Angriffspfad ist geschlossen. Voraussetzung ist, dass Kommentare auf Beiträgen des Typs tribe_events aktiv sind und mindestens ein solcher Kommentar existiert. Geschlossen wurde die Lücke in 6.17.3.1. Die Einstufung nach CWE lautet Improper Control of Generation of Code, also Code Injection.

CVE-2026-78006: PHP Object Injection trotz Fix

CVE-2026-78006 umgeht den Schutz, den der erste Patch aufgebaut hatte, und betrifft alle Versionen bis einschließlich 6.17.4. Die Prüfung in is_safe_widget_instance lässt sich aushebeln, weil PHP magische Methoden bereits während des Vorabparsens auslöst, und weil die Funktion enable_rendering_widget_copied() ein gültiges Integritätsattribut vom Typ wp_hash erzeugt, bevor unserialize() überhaupt erreicht wird. Die Sicherheitsprüfung läuft damit ins Leere, obwohl sie formal besteht.

Der Einstieg ist derselbe wie bei der ersten Lücke: ein Kommentar auf einem Event-Beitrag. Entscheidend ist ein Detail des WordPress-Kernverhaltens. Nach dem Absenden liefert WordPress dem Kommentierenden eine URL mit Moderations-Hash, über die er seinen eigenen, noch nicht freigegebenen Kommentar sofort sehen kann. Der Aufruf dieser Seite genügt, um das eingeschleuste Block-Markup in den verwundbaren Codepfad zu tragen. Die Ausführung passiert also vor jeder Moderation. Eine Kommentarfreigabe durch die Redaktion ist keine Schutzmaßnahme. Geschlossen ist die Lücke in 6.17.4.1. Einzelne Datenbanken nennen als sichere Version „6.18 oder höher“, was dieselbe Aussage in gröberer Auflösung ist. Maßgeblich ist 6.17.4.1.

Warum der erste Patch nicht reichte

Der erste Patch prüfte, ob eine übergebene Widget-Instanz vertrauenswürdig aussieht, statt das Deserialisieren nicht vertrauenswürdiger Daten grundsätzlich zu unterbinden. Genau daran scheitern Schutzmaßnahmen gegen Deserialisierungsangriffe regelmäßig, denn sie versuchen, gefährliche Eingaben zu erkennen, anstatt den gefährlichen Mechanismus zu vermeiden.

Bei einer PHP Object Injection schleust der Angreifer keinen Code ein, sondern eine serialisierte Objektstruktur. Sobald PHP diese Struktur in Objekte zurückverwandelt, feuern automatisch magische Methoden wie __wakeup oder __destruct. In einer WordPress-Installation mit Core, Theme und dreißig Plugins existiert eine sehr große Menge an Klassen, deren magische Methoden Dateien schreiben, löschen oder Funktionen aufrufen. Angreifer verketten diese Bausteine zu einer sogenannten Gadget Chain. Der verwundbare Aufruf steckt dann nicht zwingend im Plugin selbst, sondern irgendwo im geladenen Klassenbestand. Deshalb reicht es nicht, einen einzelnen Einstiegspunkt zu härten. Exploit-Details nennen wir hier bewusst nicht.

Wer ist betroffen

Betroffen ist jede WordPress-Installation mit The Events Calendar in Version 6.17.4 oder älter, bei der Kommentare auf Event-Beiträgen aktiv und öffentlich sichtbar sind. Ohne aktive Kommentare auf dem Beitragstyp tribe_events fehlt der beschriebene Einstiegspunkt, der Handlungsdruck zum Update bleibt trotzdem bestehen.

Ob Kommentare auf Events aktiv sind, prüfen Sie an drei Stellen. Erstens unter Einstellungen, Diskussion, ob Kommentare bei neuen Beiträgen global erlaubt sind. Zweitens an einem konkreten Event im Backend im Bereich Diskussion, ob Kommentare dort erlaubt sind, denn diese Einstellung wird pro Beitrag gespeichert und bleibt auch dann bestehen, wenn die globale Option später geändert wurde. Drittens im Frontend: Rufen Sie eine einzelne Event-Seite auf und sehen Sie nach, ob ein Kommentarformular oder eine Kommentarliste ausgegeben wird. Ausschlaggebend ist, was das Theme tatsächlich rendert, nicht was in den Einstellungen steht.

Wer die kostenpflichtigen Erweiterungen Events Calendar Pro oder Event Tickets einsetzt, ist ebenfalls betroffen, denn beide setzen das Basis-Plugin The Events Calendar voraus und dort steckt der verwundbare Code. Die Erweiterungen benötigen keinen eigenen Patch, das Basis-Plugin muss aktualisiert werden.

Im DACH-Raum trifft das eine sehr typische Nutzergruppe: Unternehmen mit Veranstaltungs- und Messekalendern, Bildungsanbieter mit Seminarterminen, Verbände und Vereine, Kommunen mit Veranstaltungskalendern sowie Agenturen, die dasselbe Plugin über viele Kundenprojekte hinweg ausrollen. Gerade im letzten Fall multipliziert sich das Risiko: Eine einzige nicht gepatchte Instanz genügt, und sie liegt erfahrungsgemäß in dem Projekt, das seit zwei Jahren niemand mehr angefasst hat.

Timeline

• 20.08.2026 Release 6.17.3 mit der ersten Härtung kopierter Legacy-Widget-Instanzen
• 21.08.2026 Hersteller zu CVE-2026-78006 informiert (Angabe aus dem CVE-Datensatz)
• 23.08.2026 Hersteller zu CVE-2026-78159 informiert (Angabe aus dem CVE-Datensatz)
• 26.08.2026 Release 6.17.3.1, schließt CVE-2026-78159
• 03.09.2026 Release 6.17.4 ohne Security-Eintrag im Changelog
• 10.09.2026 Release 6.17.4.1, schließt CVE-2026-78006
• 11.09.2026 Offenlegung beider Schwachstellen
• 12.09.2026 Veröffentlichung der CVE-Einträge CVE-2026-78006 und CVE-2026-78159 in der NVD
• 14.09.2026 Stand dieses Artikels: keine bestätigte Massenausnutzung, EPSS 0,78 Prozent, kein Eintrag im CISA-KEV-Katalog

Sofortmaßnahmen

1. Plugin-Version prüfen. Alles unterhalb von 6.17.4.1 ist verwundbar. Im Dashboard unter Plugins oder per WP-CLI mit wp plugin get the-events-calendar --field=version. Bei mehreren Projekten lohnt der Durchlauf als Schleife über alle Installationen.
2. Sofort auf 6.17.4.1 aktualisieren. Per WP-CLI mit wp plugin update the-events-calendar, in einem Multisite-Netzwerk netzwerkweit für alle Seiten. Testen Sie das Update vorher auf Staging, wenn Events Calendar Pro, Event Tickets oder eigene Template-Overrides im Einsatz sind.
3. Falls ein Update nicht sofort möglich ist, Kommentare auf Event-Beiträgen deaktivieren. Global unter Einstellungen, Diskussion und zusätzlich an den bestehenden Event-Beiträgen, da die Einstellung pro Beitrag gespeichert ist. Prüfen Sie anschließend vorhandene Kommentare auf Blöcke vom Typ wp:legacy-widget sowie auf serialisierte Zeichenketten mit Mustern wie O: oder a: und löschen Sie verdächtige Einträge, auch unmoderierte und als Spam markierte.
4. Logs und WAF auswerten. Suchen Sie in den Access-Logs nach POST-Anfragen auf wp-comments-post.php im Zusammenhang mit Event-URLs sowie nach Aufrufen mit Moderations-Hash-Parametern. Prüfen Sie, ob Ihre Web Application Firewall Regeln für diese CVEs ausliefert. Anbieter wie Wordfence und Patchstack haben virtuelle Patches bereitgestellt, das ersetzt jedoch das Update nicht.
5. Auf Kompromittierung prüfen. Neue oder unbekannte Administratorkonten, PHP-Dateien in wp-content/uploads, veränderte Core-Dateien im Abgleich mit wp core verify-checksums, unbekannte geplante Aufgaben über wp cron event list, unerwartete ausgehende Verbindungen und kürzlich geänderte Dateien im Theme-Verzeichnis.
6. Bei Verdacht: Seite isolieren und Incident Response starten. Seite in den Wartungsmodus, alle Sitzungen und Passwörter invalidieren, Backup vom Zeitpunkt vor dem ersten Verdacht sichern, dann sauber analysieren statt hektisch aufräumen. Wenn Sie das nicht selbst abdecken wollen, übernehmen wir das: WordPress gehackt, Notfall-Bereinigung durch CMS ADMINS.

Einschätzung von CMS ADMINS

Diese beiden Lücken sind aus unserer Sicht gefährlicher als ihr CVSS-Wert vermuten lässt, weil sie zwei Dinge verbinden, die in der Praxis selten zusammen betrachtet werden: eine Deserialisierungsschwachstelle und ein öffentliches Eingabefeld, das jeder Besucher ohne Konto bedienen darf. Kommentare gelten in vielen Projekten als Redaktionsthema, nicht als Angriffsfläche. Hier sind sie genau das, und die Moderation greift zu spät, weil der Kommentar bereits vor der Freigabe gerendert wird.

Drei Security-Releases in drei Wochen sind ein Warnsignal, und zwar nicht gegen den Hersteller, sondern für die eigene Update-Disziplin. Wer monatlich patcht, stand in diesem Zeitraum rechnerisch zu jedem Zeitpunkt auf einer verwundbaren Version. Wer nur auf „es gibt ein Update“ reagiert, ohne den Changelog auf Security-Einträge zu lesen, hat 6.17.4 vom 03.09.2026 für einen Fortschritt gehalten, obwohl darin kein Sicherheitsfix enthalten war. Genau deshalb gehört zu ordentlicher WordPress-Wartung mehr als ein Klick auf „Alle aktualisieren“: eine Bewertung, welche Aktualisierung sicherheitsrelevant ist und wie schnell sie eingespielt werden muss.

Kommentare abzuschalten ist eine gute Notbremse und eine schlechte Dauerlösung. Sie behebt nicht die Schwachstelle, sondern nur eine bekannte Zugangsmöglichkeit dorthin. Sobald ein weiterer Codepfad gefunden wird, der dieselbe verwundbare Funktion erreicht, steht die Seite wieder offen. Nachhaltig wirkt nur die Kombination aus aktuellem Code, sauber konfigurierter WordPress-Sicherheit und serverseitigem Schutz. Auf unseren Systemen filtert die Web Application Firewall bekannte Angriffsmuster bereits vor dem PHP-Prozess, und Ausführungsrechte im Upload-Verzeichnis sind grundsätzlich gesperrt, was aus einem erfolgreichen Dateiupload noch lange keine ausführbare Backdoor macht. Wie wir das umsetzen, beschreibt unsere Seite zum nginx-Hosting in Deutschland.

Für Agenturen mit vielen Kundenprojekten ist der entscheidende Punkt nicht das einzelne Update, sondern der Überblick. Wer nicht binnen Minuten beantworten kann, auf welchen der eigenen Seiten The Events Calendar in welcher Version läuft, hat kein Update-Problem, sondern ein Inventarproblem. Für genau diesen Fall arbeiten wir im White-Label-Modell für Digital- und Marketingagenturen: zentrale Übersicht über alle Installationen, definierte Update-Fenster, dokumentierte Patches.

Bleibt der rechtliche Teil, der gern vergessen wird. Führt ein erfolgreicher Angriff zum Zugriff auf personenbezogene Daten, etwa auf Teilnehmerlisten, Ticketkäufe oder Kommentardaten mit E-Mail-Adresse und IP, liegt eine Verletzung des Schutzes personenbezogener Daten nach Artikel 33 DSGVO vor. Diese ist der zuständigen Aufsichtsbehörde grundsätzlich binnen 72 Stunden zu melden, sofern nicht voraussichtlich kein Risiko besteht. Sie brauchen dafür belastbare Logs und eine nachvollziehbare Analyse, und beides entsteht nicht rückwirkend. Wo Ihre Daten liegen und wer technisch Zugriff hat, ist damit keine Glaubensfrage, sondern eine Betriebsvoraussetzung. Warum wir Serverstandort und Betreiberstruktur in Deutschland für mehr als ein Verkaufsargument halten, erläutern wir unter digitale Souveränität.

Häufige Fragen

Welche Version von The Events Calendar ist sicher?

Sicher ist Version 6.17.4.1 vom 10.09.2026 und jede spätere Version. Alle Versionen bis einschließlich 6.17.4 sind von CVE-2026-78006 betroffen, alle Versionen bis einschließlich 6.17.3 zusätzlich von CVE-2026-78159. Die Zwischenversionen 6.17.3.1 und 6.17.4 reichen nicht aus, auch wenn 6.17.3.1 einen Security-Eintrag im Changelog trägt: Dieser Eintrag bezieht sich nur auf die erste der beiden Lücken. Manche Datenbanken führen „6.18 oder höher“ als sichere Version, gemeint ist derselbe Sachverhalt. Orientieren Sie sich an 6.17.4.1 als Mindestversion.

Muss ich auch updaten, wenn Kommentare auf meinen Events deaktiviert sind?

Ja, unbedingt. Deaktivierte Kommentare entfernen den derzeit bekannten Einstiegspunkt, nicht die Schwachstelle im Code. Die verwundbaren Funktionen bleiben im Plugin enthalten und können über andere Wege erreichbar sein, etwa durch ein Theme, ein weiteres Plugin oder einen Angriffspfad, der bisher nicht öffentlich beschrieben ist. Hinzu kommt, dass die Kommentarfunktion in WordPress pro Beitrag gespeichert wird. Eine global gesetzte Einstellung heißt nicht, dass ältere Event-Beiträge tatsächlich geschlossen sind. Behandeln Sie das Abschalten als Überbrückung bis zum Update, nicht als Ersatz.

Wie erkenne ich, ob meine WordPress-Seite über The Events Calendar gehackt wurde?

Achten Sie auf typische Spuren einer Codeausführung. Dazu gehören neue Administratorkonten, PHP-Dateien in wp-content/uploads, veränderte Core-Dateien im Abgleich über wp core verify-checksums, unbekannte geplante Aufgaben, plötzlich eingefügte Weiterleitungen oder Spam-Inhalte sowie ungewöhnliche ausgehende Verbindungen des Servers. Prüfen Sie zusätzlich die Kommentartabelle auf Einträge mit wp:legacy-widget oder serialisierten Daten sowie die Access-Logs auf POST-Anfragen an wp-comments-post.php im Umfeld von Event-URLs. Bei Verdacht die Seite isolieren, bevor Sie aufräumen: Vorschnelles Löschen vernichtet die Beweise.

Reicht es, das Plugin zu deaktivieren, statt es zu aktualisieren?

Ein deaktiviertes Plugin wird von WordPress nicht geladen, der verwundbare Code läuft dann nicht mehr. Als Notmaßnahme ist das wirksam, hat aber zwei Haken. Erstens verlieren Sie sämtliche Event-Ansichten im Frontend, inklusive verlinkter und in Suchmaschinen indexierter Terminseiten, was sich unmittelbar auf Sichtbarkeit und Anfragen auswirkt. Zweitens bleiben die Plugin-Dateien auf dem Server liegen und werden beim nächsten Aktivieren wieder scharf geschaltet. Deinstallieren oder aktualisieren ist die saubere Lösung, das Update auf 6.17.4.1 die deutlich einfachere.

Sind Events Calendar Pro und Event Tickets ebenfalls betroffen?

Ja, indirekt, denn beide Erweiterungen setzen das Basis-Plugin The Events Calendar voraus, und dort liegt der verwundbare Code. Wenn Sie Events Calendar Pro oder Event Tickets einsetzen, ist The Events Calendar zwangsläufig installiert und muss auf 6.17.4.1 oder höher aktualisiert werden. Für die Erweiterungen selbst ist nach aktuellem Stand kein separater Sicherheitspatch erforderlich. Prüfen Sie nach dem Update dennoch die Kompatibilität der Zusatzprodukte, besonders bei eigenen Template-Overrides, und testen Sie den Ticketverkauf sowie die Event-Übersichten einmal vollständig durch.

Was ist eine PHP Object Injection und warum ist sie so gefährlich?

Bei einer PHP Object Injection schleust ein Angreifer keine fertigen Befehle ein, sondern eine serialisierte Objektstruktur, die die Anwendung anschließend wieder in echte Objekte umwandelt. Genau dabei ruft PHP automatisch sogenannte magische Methoden auf, die bereits Dateien schreiben, löschen oder Funktionen ausführen können. Der Angreifer schreibt also keinen eigenen Code, sondern kombiniert vorhandene Klassen aus Core, Theme und Plugins zu einer Kette mit der gewünschten Wirkung. Gefährlich ist das, weil die Angriffsfläche mit jedem installierten Plugin wächst und weil klassische Filter für Schadcode nicht greifen: Übertragen wird gültig aussehender, strukturierter Text.

Fazit

Die Aufgabe für heute ist klein und duldet trotzdem keinen Aufschub: Prüfen Sie jede WordPress-Installation, auf der The Events Calendar läuft, und heben Sie sie auf mindestens 6.17.4.1. Alles darunter ist angreifbar, und der Angriff braucht weder Zugangsdaten noch Mithilfe eines Redakteurs.

Dass bislang keine Massenausnutzung bestätigt ist, sollten Sie als Zeitfenster lesen und nicht als Entwarnung. Für kritische WordPress-Schwachstellen mit öffentlich beschriebenem Angriffsweg vergehen zwischen Veröffentlichung und breiten automatisierten Scans typischerweise Tage, nicht Wochen. Wer jetzt patcht, entscheidet selbst über den Zeitpunkt. Wer wartet, überlässt die Entscheidung einem Bot.

Der größere Lerneffekt liegt jenseits dieser beiden CVEs. Drei Security-Releases in drei Wochen, ein umgangener Patch und ein Release ohne Sicherheitsvermerk dazwischen: Das ist Normalbetrieb in einem Ökosystem mit über 60.000 Plugins. Verlässlich wird der Betrieb nicht durch schnelleres Klicken, sondern durch einen Prozess, der Versionen inventarisiert, Changelogs bewertet, auf Staging testet und dokumentiert, wann was eingespielt wurde.

Wenn Sie diesen Prozess nicht selbst betreiben möchten, übernehmen wir ihn. Wir prüfen Ihre Installationen, spielen kritische Sicherheitsupdates zeitnah ein, überwachen Ihre Seiten laufend und greifen im Ernstfall ein. Mehr dazu auf unseren Seiten zu WordPress-Sicherheit und WordPress-Wartung. Bei einem konkreten Verdacht auf eine Kompromittierung gehen Sie direkt zur Notfall-Hilfe für gehackte WordPress-Seiten.

Quellen

• Wordfence Threat Intelligence, The Events Calendar
• Patchstack Vulnerability Database, The Events Calendar
• NVD, CVE-2026-78006
• NVD, CVE-2026-78159
• OpenCVE, CVE-2026-78006
• OpenCVE, CVE-2026-78159
• WordPress.org, The Events Calendar, Changelog und Installationszahlen
• FIRST EPSS, Exploit-Prediction-Werte