GiveWP-Plugin-Schwachstelle ermöglicht nicht authentifizierte Remote-Codeausführung

Eine Schwachstelle im GiveWP-Plugin für WordPress-Spenden ermöglichte es einem Angreifer ohne Konto, beliebige Befehle auf dem zugrunde liegenden Webserver auszuführen, so ein Sicherheitshinweis von Patchstack. GiveWP ist ein beliebtes Plugin, das Spendenformulare, Zahlungsgateways, Spenderverwaltung und Berichte für gemeinnützige Organisationen und andere Fundraising-Organisationen bereitstellt. Die Schwachstelle, verfolgt als CVE-2026-82222, erhielt einen CVSS-Schweregrad von 10.0, die höchstmögliche Bewertung. Sie betraf GiveWP-Versionen 4.16.7.1 und früher und wurde in Version 4.16.7.2 behoben, die am 27. August 2026 veröffentlicht wurde. Patchstack, ein WordPress-Sicherheitsunternehmen, gab an, dass seine Benutzer durch Mitigationsregeln geschützt waren und dass das Problem vom Forscher Udin Chan entdeckt und gemeldet wurde. Der Hinweis listet das Plugin mit rund 100.000 Installationen auf, was das Update für viele Website-Besitzer dringend macht.

Das technische Problem ist als PHP-Objektinjektion bekannt. Websites, die auf WordPress und PHP basieren, speichern komplexe Daten oft als Textzeichenfolge, ein Prozess namens Serialisierung, und wandeln diese Zeichenfolge später durch eine Funktion namens unserialize wieder in ein lebendiges Programmobjekt um. Wenn ein Angreifer den serialisierten Text kontrollieren kann, kann die PHP-Anwendung dazu gebracht werden, ein gefährliches Objekt zu erstellen, das vom Angreifer gewählten Code ausführt. GiveWP versuchte, dies mit einer Hilfsfunktion namens safeUnserialize sicher zu machen, die die PHP-Option allowed_classes auf false setzte. Diese Option löscht das Objekt des Angreifers jedoch nicht. Stattdessen wandelt sie das Objekt in einen Platzhalter namens __PHP_Incomplete_Class um, der den ursprünglichen Klassennamen und alle seine Eigenschaften behält. Wenn dieser Platzhalter später erneut serialisiert wird, schreibt PHP die ursprünglichen gefährlichen Bytes unverändert zurück. Wie der Patchstack-Hinweis erklärt, versteckte die Hilfsfunktion die Nutzlast für einen Lesevorgang und übergab dann das unberührte serialisierte Objekt zurück an den Speicher, sodass der Angriff einfach beim nächsten ungeschützten Lesevorgang stattfand.

Der erste Schritt des Angriffs erfordert einen angemeldeten Spender. Das klingt nach einer Hürde, aber Forscher beschrieben einen Weg, um kostenlos ein Konto zu erhalten. GiveWP stellt eine nicht authentifizierte Registrierungsaktion namens give_action=user_register bereit, die nie die WordPress-Einstellung überprüft, die steuert, ob Besucher sich registrieren können. Selbst auf einer Website mit deaktivierter Registrierung konnte ein Angreifer eine manipulierte Anfrage senden, um ein Konto zu erstellen und ein Authentifizierungscookie zu erhalten. Vor Version 4.16.6 gab es keine Nonce-Anforderung für diesen Handler. Eine Nonce ist ein temporäres Token, das beweisen soll, dass eine Anfrage von einer erlaubten Seite stammt. Version 4.16.6 fügte eine Nonce-Anforderung hinzu, aber die Nonce wird nur von einer Seite ausgegeben, die den [give_register]-Shortcode verwendet, und WordPress-Nonces für abgemeldete Besucher sind für jede anonyme Anfrage an dieselbe Website identisch. Das bedeutet, dass ein Angreifer die Nonce einmal ernten und auf jeder Website wiederverwenden kann, die diesen Shortcode öffentlich rendert. Kurz gesagt, die Kontohürde war keine echte Hürde.

Einmal drin, platziert der Angreifer eine serialisierte Gadget-Kette im Nachnamenfeld seines eigenen Kontos über die Profilseite. Der Begriff Gadget-Kette bezieht sich auf eine Abfolge von Methoden in bereits geladenem Code, die, wenn ein Objekt zerstört oder serialisiert wird, letztendlich eine gefährliche Funktion aufruft. GiveWP wird mit zwei Bibliotheken geliefert, die zusammen eine vollständige Kette bilden: die TCPDF-Bibliothek und die Give\TestData-Klassen. Wenn das injizierte Objekt zerstört wird, tritt es in TCPDF::__destruct ein, das _destroy aufruft, und das erreicht eine magische Methode im ProviderForwarder-Trait. Diese Methode verwendet call_user_func_array mit einem vom Angreifer kontrollierten Callable und Argument. Da der Angreifer eine Array-Eigenschaft namens loadedProviders im injizierten Objekt kontrolliert, kann er sie auf die PHP-Systemfunktion setzen. Das Ergebnis ist die Ausführung eines beliebigen Betriebssystembefehls als Webserver-Benutzer.

Der Spendenablauf verbindet diese Teile. Wenn der angemeldete Angreifer eine Spende einreicht, erstellt das Plugin einen Spendendatensatz. Es nimmt den last_name-Wert aus der Datenbank, wo die serialisierte Gadget-Kette gespeichert wurde, und führt ihn durch die "sichere" unserialize-Hilfsfunktion. Da die Daten aus der Datenbank und nicht direkt aus der Anfrage stammen, sieht die normale Eingabevalidierung sie nie. Das Platzhalterobjekt wird dann auf dem Weg in die wp_give_sessions-Tabelle serialisiert, und die ursprünglichen gefährlichen Bytes werden intakt gespeichert. Wenn die Website diese Sitzung das nächste Mal liest, unserialisiert sie die Bytes ohne den allowed_classes-Schutz, was die echte Gadget-Kette zum Leben erweckt. Die von Patchstack beschriebene vollständige Kette hat vier Schritte: Registrieren Sie ein Konto, platzieren Sie die Gadget-Kette im Profil, vergiften Sie die Sitzung, indem Sie eine Spende ohne last_name-Wert einreichen, und fordern Sie dann mit demselben Cookie eine beliebige Frontend-Seite an, um den Befehl auszulösen.

Der Hinweis erklärt auch eine Änderung der Erreichbarkeit zwischen Versionen. Auf GiveWP 4.16.5.1 und früher war eine Standardinstallation ausreichend: Das Plugin wurde mit einem aktiven manuellen (Test-Spenden-)Gateway und einem aktiven Offline-Gateway geliefert und benötigte nur ein veröffentlichtes Spendenformular. Kein Testmodus, keine offene Registrierung, kein Debug-Modus und keine Administratoraktion waren erforderlich. In den Versionen 4.16.6 bis 4.16.7.1 brach der Legacy-Spendenprozessor ab, wenn das eingereichte Formular ein Visual Form Builder (v3)-Formular ist, sodass eine frische Standardinstallation über diesen Pfad nicht mehr ausnutzbar war. Ein einzelner give_forms-Beitrag ohne formBuilderSettings bewaffnet die Kette jedoch erneut, in jedem Beitragsstatus, einschließlich Entwurf und Papierkorb. Das betrifft Websites, die von älteren Versionen aktualisiert wurden, jeden Formularimport oder jede Wiederherstellung und jede Website, auf der ein Administrator den optionenbasierten Formular-Editor aktiviert hat.

Der Patch enthält eine wichtige Lektion über Deserialisierungsfehler. Vor dem endgültigen Fix veröffentlichte GiveWP Version 4.16.6, die versuchte, den __PHP_Incomplete_Class-Platzhalter zu erkennen und, wenn gefunden, die rohe serialisierte Zeichenfolge zurückzugeben. Das gab die ursprünglichen Nutzlastbytes wörtlich zurück, sodass der Angriff später genauso möglich blieb. Version 4.16.7.2 änderte dies, um stattdessen false zurückzugeben, was die Nutzlast stoppt. Die Entwickler schlossen dann die Kette an fünf unabhängigen Punkten. Der Schreibpfad in process-donation.php lehnt jetzt eine Spende direkt ab, wenn ein Namensfeld serialisierte Daten enthält, und der User-Meta-Fallback läuft durch give_clean, das für serialisierte Eingaben eine leere Zeichenfolge zurückgibt. Drei Lese-Senken übergeben jetzt allowed_classes auf false: der Sitzungs-Getter, der Sitzungstabellen-Lesezugriff und die Spenderwand. Die Spenderwand ist wichtig, da sie von einem anonymen Besucher über den öffentlichen [give_donor_wall]-Shortcode ohne Sitzungscookie erreichbar war. Die Gadget-Kette selbst wurde behoben: ProviderForwarder::__call überprüft jetzt, ob der aufgelöste Provider den erwarteten Vertrag implementiert, bevor er ihn aufruft. Spender- und Abrechnungsnamen-Meta werden beim Speichern von Zahlungen durch sanitize_text_field geleitet. Schließlich durchläuft eine Migration namens SanitizeSerializedObjectPayloads usermeta, give_donormeta, give_donationmeta und give_sessions und ersetzt jedes verschachtelte Objekt durch eine leere Zeichenfolge. Dieser letzte Schritt entfernt Nutzlasten, die vor dem Update bereits in der Datenbank gespeichert wurden.

Der Hinweis weist auf einen Punkt aus dem Bericht hin, der nicht behoben wurde. Der nicht authentifizierte Registrierungshandler give_action=user_register berücksichtigt weiterhin nicht die WordPress-Option users_can_register. Patchstack beschreibt dies als Zugriffskontrollproblem und nicht als Schritt zur Codeausführung, sobald die Objektinjektion geschlossen ist. Website-Besitzer sollten dies dennoch im Hinterkopf behalten, aber die Remote-Codeausführungskette selbst ist durch die fünf Fix-Ebenen unterbrochen. Die Zeitleiste zeigt, dass der Bericht am 28. Juli 2026 einging, am selben Tag bestätigt und dem Anbieter offengelegt wurde. Mehrere Patchversuche wurden abgelehnt, bevor am 27. August 2026 Version 4.16.7.2 veröffentlicht wurde. Der Hinweis wurde am 28. August 2026 öffentlich gemacht.

Für Website-Besitzer ist dieser Fall eine Erinnerung daran, dass ein Plugin mit großer Installationsbasis und Zahlungsfunktionalität ein Hauptziel ist. Aktualisieren Sie GiveWP und alle aktiven Plugins umgehend und behandeln Sie Sicherheitsupdates als zeitkritische Wartung. Verwaltete WordPress-Hosting-Dienste, die Plugins gepatcht halten, wie AEU Hosting, können die Zeit verkürzen, in der eine anfällige Version auf einer Produktionswebsite verbleibt. Das ist praktischer Schutz für die vielen gemeinnützigen Organisationen, Fundraiser und kleinen Unternehmen, die sich auf GiveWP verlassen, um online Spenden zu sammeln.