GiveWP-Schwachstelle ermöglicht Angreifern Codeausführung auf WordPress-Seiten

GiveWP, ein WordPress-Plugin für Spenden und Fundraising, enthält eine Schwachstelle, die es einem Angreifer ohne Konto auf der Seite ermöglicht, Befehle auf dem Server auszuführen, so ein von Patchstack am 28. August 2026 veröffentlichter Advisory-Artikel. Betroffen sind GiveWP-Versionen 4.16.7.1 und älter. Der Hersteller veröffentlichte am 27. August 2026 die Version 4.16.7.2, um das Problem zu beheben, und der Meldung wurde die Kennung CVE-2026-82222 zugewiesen. Patchstack listet das Plugin mit 100.000 Installationen und bewertet die Schwachstelle mit CVSS 10.0, dem oberen Ende dieser Schweregradskala.

Der Forscher Udin Chan entdeckte die Schwachstelle und meldete sie, so Patchstack, das angibt, das Problem bestätigt und den Hersteller kontaktiert zu haben. Patchstack gibt außerdem an, Mitigationsregeln zum Schutz vor der Ausnutzung dieser Schwachstelle herausgegeben zu haben. GiveWP wird von gemeinnützigen Organisationen und anderen Einrichtungen genutzt, um Spendenformulare zu betreiben, Zahlungs-Gateways anzubinden, Spender zu verwalten und Berichte zu erstellen.

Was das so ernst macht, ist, wie wenig ein Angreifer benötigt. In den Versionen 4.16.5.1 und älter genügt eine Standardinstallation, denn GiveWP wird mit einem aktiven manuellen Gateway (Test Donation) und einem aktiven Offline-Gateway ausgeliefert, und es ist nur ein veröffentlichtes Spendenformular erforderlich. Kein Testmodus, keine offene Benutzerregistrierung, kein Debug-Modus und keine Administratoraktion sind nötig. Sobald die Kette läuft, kann ein Angreifer einen beliebigen Betriebssystembefehl als der Benutzer ausführen, unter dem der Webserver läuft, und die Ausgabe dieses Befehls kann über HTTP zurückgelesen werden.

In den Versionen 4.16.6 bis 4.16.7.1 reichte eine Standardinstallation nicht mehr aus, aber nur im Sinne der Erreichbarkeit, nicht weil das zugrunde liegende Problem behoben wurde. Diese Releases lassen den alten Spendenprozessor stoppen, wenn das übermittelte Formular ein Visual Form Builder (v3)-Formular ist. Patchstack merkt an, dass ein einzelner Formulareintrag ohne seine Form-Builder-Einstellungen die gesamte Kette wieder scharf macht, und dass dieser in jedem Beitragsstatus stehen kann, einschließlich Entwurf und Papierkorb. Das betrifft jede Seite, die von einer älteren Version aktualisiert wurde, jeden Formularimport oder jede Wiederherstellung und jede Seite, auf der ein Administrator unter Einstellungen, Erweitert den Option-Based Form Editor aktiviert hat.

Die Schwachstelle setzt sich aus drei Teilen zusammen. Der erste ist ein Helfer, den GiveWP als sicheren Weg zur Nutzung von unserialize gedacht hatte, der PHP-Funktion, die einen gespeicherten Textblock wieder in lebende Programmierobjekte verwandelt. Wenn ein Angreifer diesen Text kontrolliert, kann er ein Objekt einer von ihm gewählten Klasse einschleusen. Der Helfer in der Datei src/Helpers/Utils.php ruft unserialize mit der Einstellung allowed_classes auf false gesetzt auf, was so aussieht, als seien Objekte blockiert. In der Praxis erstellt PHP das Objekt dennoch, aber als Platzhaltertyp namens __PHP_Incomplete_Class, der den ursprünglichen Klassennamen und jede Eigenschaft behält. Wenn dieser Platzhalter zurück in den Speicher geschrieben wird, gibt PHP dieselben ursprünglichen Bytes wieder aus, sodass die Nutzlast nicht neutralisiert, sondern nur während dieses einen Lesevorgangs verborgen wird. Der Angriff wird einfach auf einen späteren Lesevorgang verschoben, der ohne den Schutz stattfindet.

Der zweite Teil ist ein Spendenablauf, der dem Helfer angreiferkontrollierte Daten übergibt. Ein angemeldeter Spender kann ein serialisiertes Objekt im Nachnamensfeld seines eigenen Benutzerprofils speichern. Wenn er eine Spende übermittelt, baut der Spendenverarbeitungscode in includes/process-donation.php die Spenderinformationen aus diesen Kontodaten auf und leitet jedes Feld durch den sicheren unserialize-Helfer, bevor das Ergebnis in die Tabelle wp_give_sessions gespeichert wird. Weil die bösartigen Daten aus der Datenbank zurückkommen und nicht direkt in der Anfrage eintreffen, sieht sie die gewöhnliche Eingabevalidierung nie, und der Platzhalter mit den ursprünglichen Bytes landet unversehrt in der Datenbank.

Der dritte Teil ist eine Gadget-Kette, also eine Abfolge von Methoden in bereits geladenen Klassen, die in einem gefährlichen Funktionsaufruf endet. GiveWP liefert sowohl die TCPDF-Bibliothek als auch eigene Testdatenklassen mit, und zusammen bilden sie einen vollständigen Pfad. Das Zerstören des eingeschleusten Objekts betritt den Destruktor von TCPDF, der eine interne destroy-Methode aufruft, die eine Weiterleitungsmethode im Trait ProviderForwarder erreicht, die ihre Argumente direkt in call_user_func_array übergab, mit einem Callable, das aus dem Objekt selbst stammt. Da die Liste der Provider nur eine Array-Eigenschaft ist, die im eingeschleusten Objekt mitgeführt wird, kann der Angreifer sie auf jede Funktion richten, einschließlich einer, die Betriebssystembefehle ausführt.

Die Kette benötigt außerdem einen angemeldeten Benutzer, und GiveWP lieferte einen kostenlos mit. Patchstack berichtet, dass eine nicht authentifizierte Registrierungsaktion, give_action=user_register, niemals die WordPress-Einstellung prüft, die steuert, ob Besucher sich registrieren dürfen. Selbst auf einer Seite mit abgeschalteter Registrierung konnte ein Angreifer ein Konto anlegen, ein Authentifizierungs-Cookie erhalten und sofort weitermachen. Version 4.16.6 fügte dieser Behandlung eine Einmalcode-Anforderung hinzu, was das Fenster verengt statt es zu schließen: Der Code wird nur vom Registrierungs-Shortcode-Template ausgegeben, und WordPress stellt allen abgemeldeten Besuchern einer bestimmten Seite identische Einmalcodes aus, sodass ein Angreifer auf jeder Seite, die diesen Shortcode öffentlich zeigt, einen Code sammeln und wiederverwenden kann.

In der Abfolge hatte der gemeldete Angriff vier Schritte. Erstens ein Konto registrieren, indem man an die Registrierungsaktion sendet, was unabhängig von der Registrierungsrichtlinie der Seite ein Authentifizierungs-Cookie zurückgibt. Zweitens einen Profilcode von der Profilseite lesen und das serialisierte Gadget in das Nachnamensfeld des Kontos senden. Drittens einen Spenden-Code abrufen und eine Spende mit Formular-ID, Gateway und Betrag, aber ohne das Nachnamensfeld übermitteln, wodurch der Server das Objekt in die Sitzungstabelle schreibt, bevor er einen HTTP-500-Fehler zurückgibt. Viertens eine beliebige Frontend-Seite mit demselben Cookie anfordern, woraufhin der Server die vergiftete Sitzung liest, das Objekt neu aufbaut und den Befehl des Angreifers ausführt.

GiveWP behob das Problem in 4.16.7.2, und Patchstack hebt hervor, dass der Fix die Kette an mehreren unabhängigen Stellen unterbricht statt an dem einen gemeldeten Einstiegspunkt. Ein früherer Versuch in 4.16.6 zeigt, warum das wichtig ist: Er erkannte den unvollständigen Platzhalter und gab den rohen serialisierten Text zurück, wodurch die Nutzlast genau wie zuvor erhalten blieb. Version 4.16.7.2 gibt stattdessen einen Fehlerwert zurück. Das Release schließt dann fünf Punkte: Der Spendenverarbeitungscode lehnt eine Spende rundheraus ab, wenn ein Namensfeld serialisierte Daten enthält, und ein Fallback-Pfad für Benutzerdaten wird durch eine Bereinigungsfunktion geleitet, die für serialisierte Eingaben einen leeren String zurückgibt; drei Stellen, die diese Daten zurücklesen, blockieren nun die Objekterstellung, einschließlich der Spenderwand, die für einen anonymen Besucher über einen öffentlichen Shortcode ganz ohne Cookie erreichbar war; das Weiterleitungs-Gadget prüft nun, ob der Provider, den es auflöst, tatsächlich den erwarteten Vertrag implementiert; Spender- und Rechnungsnamensfelder werden vor dem Speichern bereinigt; und eine Migration namens SanitizeSerializedObjectPayloads durchläuft die Tabellen für Benutzer-, Spender-, Spenden- und Sitzungsdaten und ersetzt jedes verschachtelte Objekt durch einen leeren String. Dieser letzte Schritt ist wichtig, weil eine Seite, die vor dem Update vergiftet wurde, sonst eine funktionierende Nutzlast in ihrer Datenbank behalten würde.

Ein Punkt aus dem Bericht bleibt offen. Patchstack stellt fest, dass die Registrierungsaktion weiterhin nicht die eigene Einstellung der Seite zum Erlauben von Registrierungen berücksichtigt, und charakterisiert das nun, da die Objektinjektion geschlossen ist, als Zugriffskontrollproblem statt als Schritt zur Codeausführung. Die von Patchstack festgehaltene Zeitleiste reicht vom 28. Juli 2026, als der Bericht für die Versionen 4.16.5.1 und älter einging und die CVE zugewiesen wurde, über den 27. August 2026, als der Hersteller 4.16.7.2 veröffentlichte, bis zum 28. August 2026, als das Advisory veröffentlicht wurde.

Für Seitenbetreiber ist die praktische Lehre das Timing von Patches. Das Update ist verfügbar, es entfernt den anfälligen Code und bereinigt außerdem Daten, die frühere Versionen möglicherweise bereits gespeichert haben. Für alle, die Patch-Stände nicht Plugin für Plugin verfolgen möchten, übernimmt AEU Hosting, unser Managed-WordPress-Hosting-Dienst, WordPress-Pflege und -Sicherheit als Teil des Pakets – genau die Ebene, auf der ein Fix wie dieser schnell landen muss.