GiveWP Patches a CVSS 10.0 Flaw That Let Anonymous Visitors Take Over Donation Sites

Patchstack has disclosed an unauthenticated remote code execution vulnerability in GiveWP, the WordPress donation and fundraising plugin running on more than 100,000 sites, and rated it CVSS 10.0, the maximum score the scoring system allows. The flaw let a visitor with no account and no special configuration submit a donation and come away with the ability to run arbitrary commands on the server.

GiveWP, developed by Nexcess, provides donation forms, payment gateway integrations, and donor management for nonprofits and other fundraising organizations. Patchstack says the vulnerability affects version 4.16.7.1 and below and was fixed in 4.16.7.2, released on August 27, one day before the advisory went public.

A default installation was enough

On version 4.16.5.1 and below, Patchstack says exploitation needed nothing beyond a stock GiveWP setup: one published donation form and one active payment gateway, which describes a default installation, since GiveWP activates a manual “Test Donation” gateway and an offline gateway out of the box. No test mode, open registration, debug mode, or administrator action was required.

Versions 4.16.6 through 4.16.7.1 narrowed the hole without closing it. Those releases made GiveWP’s older donation processor stop short when a submitted form was built with the newer Visual Form Builder, so a freshly installed site was no longer exploitable through that specific path. Patchstack calls this a reachability change rather than a fix: a single donation form missing one internal setting (formBuilderSettings) re-arms the entire chain, in any status, including draft or trashed. That covers every site upgraded from an older GiveWP release, any form that was imported or restored, and any site where an administrator turned on the plugin’s “Option-Based Form Editor.”

Registering an account was optional too

Everything above still assumes an attacker has a GiveWP donor account to work from. Patchstack found that step doesn’t cost anything either. GiveWP’s registration handler creates a full WordPress user account and returns a valid authentication cookie in response to a plain POST request carrying give_action=user_register, regardless of whether the site’s own registration setting is turned on at all.

Version 4.16.6 added a security nonce to that request, but Patchstack says it only narrows the window rather than closing it. The nonce is emitted by the [give_register] shortcode template, and WordPress issues the identical nonce to every logged-out visitor of a given site. An attacker only has to find one public page that renders that shortcode, harvest the nonce once, and reuse it to keep minting free accounts.

A “safe” unserialize helper that wasn’t safe

PHP Object Injection bugs happen when an application hands attacker-controlled data to PHP’s unserialize() function, which reconstructs objects from serialized text and can be tricked, through what researchers call a gadget chain, into running attacker-chosen code once the application touches the reconstructed object. GiveWP anticipated the risk and wrapped unserialize() in a helper called safeUnserialize(), which calls it with the option allowed_classes set to false.

Patchstack’s write-up explains why that guard failed. Per PHP’s own documentation, allowed_classes => false does not discard a malicious serialized object. PHP instead reconstructs it as a generic placeholder called __PHP_Incomplete_Class that still preserves the original class name and every property. When that placeholder is serialized again later, on its way into GiveWP’s session storage, PHP writes the exact original bytes back out. The helper never neutralizes the payload; it only hides it for the one read where it’s applied, then hands the untouched object back to storage, deferring the danger to the next place that unserializes the same data without the guard in place.

That next place, according to Patchstack, is the donation flow itself. An attacker plants a malicious serialized value in their own account’s last name field, then submits a donation. GiveWP’s own code copies that field into a session record, runs it through the ineffective “safe” helper, and writes it intact into the site’s wp_give_sessions database table. From there, the chain plays out in four steps: register a free account, plant the payload in the account’s profile, submit a donation that writes the payload into a session record, then load any front-end page using that same session cookie. The server reads the poisoned session back out, unserializes it a second time, and a gadget chain already present in code GiveWP ships turns the reconstructed object into arbitrary command execution, with the output readable back over an ordinary HTTP response.

The same function broke the same way in 2024

This is not GiveWP’s first unauthenticated Object Injection to RCE bug, and it is not even the first time the chain has run through the same code. In August 2024, Wordfence disclosed CVE-2024-5932, another CVSS 10.0 chain in GiveWP reachable through the plugin’s give_title field, fixed in version 3.14.2, reported by researcher villu164, and rewarded with a $4,998 bug bounty. According to The Hacker News’s coverage at the time, that flaw also lived inside GiveWP’s give_process_donation_form() function, the exact function Patchstack now identifies as the point where this year’s chain reaches its broken unserialize helper. Two years and roughly a full major version apart, the same donation-processing code has produced the same class of maximum-severity bug twice.

What GiveWP fixed

Patchstack credits researcher Udin Chan with reporting the current bug on July 28, initially against version 4.16.5.1 and below. Patchstack says it confirmed the vulnerability the same day and spent the following month working with the vendor, rejecting what it describes as several inadequate patch attempts before 4.16.7.2 shipped. One earlier attempt, in version 4.16.6, added a check that detected the __PHP_Incomplete_Class placeholder and then simply handed back the original serialized string verbatim, the same vulnerable outcome as before, so the underlying flaw was merely deferred rather than fixed.

Version 4.16.7.2 takes a different approach, closing the chain at several independent points instead of patching only the entry point that was originally reported. Patchstack’s advisory does not cite a CVE identifier as of publication. Any GiveWP site running version 4.16.7.1 or earlier should update to 4.16.7.2 immediately: the plugin’s active-install base puts more than 100,000 nonprofit and fundraising sites in the affected range.