On this page (7 sections)
Patchstack has published research on a critical flaw in GiveWP, a WordPress donation and fundraising plugin. According to Patchstack, versions 4.16.7.1 and below contain a PHP Object Injection weakness that can be chained into remote code execution (RCE) on the server.
If your organization collects donations through GiveWP, check your installed version now. So far only one publisher covers this story, so some details below are marked as unconfirmed.
What happened
Patchstack, which says the issue was reported to it by researcher Udin Chan, describes a chain that lets an attacker with no account run arbitrary commands on the server of a GiveWP site. The conditions it names are one published donation form and one active payment gateway. On the versions where the chain is fully reachable, Patchstack says that describes a default installation.
Patchstack also says it has issued mitigation rules for its own users. That is protection through its service, not a plugin fix. The research available to us does not state a patched GiveWP release, and no CVE identifier is given. Check the plugin's changelog and the WordPress plugin directory for the current status.
How the weakness works
PHP Object Injection happens when an application turns attacker-influenced text back into PHP objects with unserialize(). If the application ships classes that do something dangerous when they are created or destroyed, an attacker can pick those classes and trigger the behavior. Such a sequence of classes is called a gadget chain.
Patchstack describes three parts that combine in GiveWP:
- A helper meant to be a safe unserialize. It calls unserialize() with allowed_classes set to false. Per Patchstack, citing the PHP manual, that does not discard the attacker's object. It becomes a placeholder (__PHP_Incomplete_Class) that keeps the class name and properties, and when it is serialized again the original bytes are written back out. The payload is hidden for one read and then stored untouched.
- A donation flow that feeds the helper. Patchstack says serialized data planted in a user's profile field (last_name user meta) is later read from the database when a donation is submitted, so the malicious data does not arrive in the triggering request.
- A gadget chain in code that GiveWP itself ships, which turns the stored object into command execution.
We are not reproducing exploit details here. The point for site owners is that the dangerous data is stored first and used later, which makes simple request filtering less reliable than updating the code.
Who is affected
Patchstack's reachability notes differ by version range:
| GiveWP version | Exposure |
|---|---|
| 4.16.5.1 and below | A default installation is enough: an active manual (Test Donation) gateway, an active offline gateway and one published donation form. No Test Mode, open registration, debug mode or administrator action needed. |
| 4.16.6 through 4.16.7.1 | Reachability narrows, but the vulnerability remains. A fresh default install is no longer exploitable through the legacy processor, but this is described as a reachability change, not a fix. |
On 4.16.6 through 4.16.7.1, Patchstack says a single give_forms post lacking formBuilderSettings re-arms the chain, in any post status including draft and trashed. It lists these situations: sites upgraded from an older version, any form import or restore, and any site where an administrator enabled Settings, Advanced, Option-Based Form Editor.
How to check your exposure
First find the installed GiveWP version. This read-only WP-CLI command lists all installed plugins with their name, status and version; run it from the WordPress root. Find the GiveWP entry (its slug is typically give) and look for a version of 4.16.7.1 or lower.
wp plugin list --fields=name,status,version,update_versionThe update_version column shows whether the plugin directory offers a newer release. If you prefer the admin dashboard, the Plugins page shows the same version number.
Then review your donation forms, since Patchstack says legacy-style forms keep the chain reachable on newer versions. In the WordPress admin, check whether Settings, Advanced, Option-Based Form Editor is enabled, and whether you have imported or restored forms or upgraded from an older GiveWP release.
What to do now
0 of 8 done
Once the vendor ships a fixed release, you can update from the Plugins page, or use WP-CLI. This command updates the plugin with the slug give from the WordPress root; take a backup first and confirm the slug in the list output above.
wp plugin update giveDetection and monitoring afterward
Because the payload is stored in the database and used later, a site could be compromised after the data was planted. After updating, check for signs of intrusion: new administrator accounts, changed files, unexpected scheduled tasks and outbound connections you do not recognize. Our guides on checking whether a website is hacked and what to do if it is walk through this.
You can run a read-only outside-in check with the free malware scanner, keeping in mind what outside-in detection can and cannot see. Ongoing monitoring of uptime and header changes helps you notice a site that starts behaving differently. For future plugin issues, the WordPress plugin vulnerability list is a useful reference.
What is still unknown
- No CVE identifier appears in the research.
- No patched GiveWP version is stated in the part of the write-up we have.
- No confirmation of exploitation in the wild.
- Only one publisher, Patchstack, has covered this so far, and it also sells protection against the issue, so wait for vendor confirmation of the fix.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.