Entdeckt wurde das Sicherheitsproblem vom Team des WordPress Security-Anbieters Wordfence, die WPBakery bereits Ende Juli über ihre instabile Plugin-Version informierten. Erst zwei (!) Monate später veröffentlichten die Seitenbäcker mit der 6.4.1 einen Sicherheitspatch. Zu diesem Zeitpunkt dürften bereits einige Websites infiziert gewesen sein, es sei denn, und das ist nun der angenehme Werbepart für Wordfence, die Webmaster hatten auch Wordfence am Start…
Nutzer der Premium-Version wurden unmittelbar nach Entdecken der Sicherheitslücke am 27.7.2020 vor Attacken geschützt, der nicht zahlende Anwender kam erst einen Monat später in diesen Genuss.
Wer ist betroffen?
Betroffen sind alle Seiten, die WPBakery einsetzen und die User-seitige Registrierung von neuen Benutzern erlauben. Anwender, die also per se keine Nutzer-Registrierung in WordPress erlauben, können erst einmal aufatmen.
Zudem gibt es auch Themes, die mit WPBakery erstellt wurden, aber aus Kombabilitätsgründen auf älteren Versionen laufen. Hier wird es vertrackt mit den Theme-Updates und es wäre an der Zeit, über ein neues WordPress-Theme nachzudenken.
Die Schwachstellen
Welche Bugs behoben die Entwickler von WPBakery im Detail? Zuvor existierte eine Schwachstelle, die es Nutzern mit Contributor/Autoren-Rechten erlaubte Schadcode auf Seiten oder in Beiträgen zu platzieren.
Die Schwachstelle ermöglicht das Einfügen von HTML und JavaScript in Beiträge anderer Autoren.
Möglich wurde dieser kriminelle Akt durch die von WPBakery deaktivierten HTML-Filterchecks in der saveAjaxFe in Verbindung mit kses_remove_filters();. Dadurch konnten nicht nur die gebackenen Seiten infiltriert werden, sondern auch Beiträge, die mit dem Classic Editor erstellt wurden.
Über Button-Shortcodes ließ sich ebenfalls schadhaftes Javascript unterjubeln. Ein Klick und der Albtraum beginnt…
Fazit
Also, liebe Unternehmer und privaten Homepagebauer, die ihr auf WPBakery setzt, bitte loggt euch umgehend ein, macht ein Backup vom alten Stand und bringt dann den Website-Builder auf den neuesten Stand. Schaut euch die User-Accounts an und prüft, dass ihr nicht schon Opfer eines Cross-Site Scripting-Angriffs wurdet.
Falls die Alarmglocken schon läuten, dann wendet euch bitte an die Webagentur eures Vertrauens oder versucht in Eigenregie mit einem Service wie Sucuri euer Glück.
Beitragsbild: Nadya Spetnitskaya
3 Antworten
Vielen Dank für diesen Artikel. Ich liebe das WPBakery-Plugin und ziehe es dem Elementor vor. Generell zeigt sich, wie wichtig die Wartung von CMS-Internetauftritten ist. Viele Webseitenbetreiber vergessen dies schlichtweg. Gerade Unternehmen sollten einen Administrator anstellen, welcher sich auch um die Aktualisierung der Content Management Systeme kümmern kann.
Ehrlich gesagt sehe ich nicht mehr so ganz durch bei WPBakery. Früher war es der Visual Composer, dann der WPBakery Page Builder, jetzt wieder der Visual Composer (und doch ganz anders). Mittlerweile nutzen wir bei uns vermehrt den Elementor, damit arbeitet sich es doch etwas angenehmer. Nur in Fällen – wie auch hier im Artikel erwähnt – wenn es im Theme mitgeliefert wird, setzen wir noch WPBakery ein.
Wir setzen ebenfalls auf Elementor und damit auf eine zukunftssichere Lösung, denn die Firma hat bereits eine stabile Basis mit wiederkehrenden Einnahmen. Der richtige Stack für Kundenprojekte und den eigenen Auftritt ist sehr entscheidend was die Wartbarkeit und preiswürdige Weiterentwicklung einer Website angeht. Kunden werden wenig begeistert sein, wenn Sie für einen Theme/Homepage Builder-Wechsel extra bezahlen sollen. Da kann es Unmut geben und man auf einem Teil der Migrationsaufwände sitzen bleiben.