GiveWP chains three bugs to open unauthenticated command execution on WordPress
On 27 August 2026, GiveWP fixed CVE-2026-82222, a three-bug chain that turns a WordPress donation form into remote command execution with no real authentication. Administrators must upgrade to 4.16.7.2 and check for rogue accounts, even on sites where registration was disabled.
28 July 2026. Researcher Udin Chan reports the flaw to Patchstack. 27 August 2026. GiveWP ships version 4.16.7.2. 28 August 2026. BleepingComputer documents the full chain. Net result: a donation plugin installed on more than 100,000 WordPress sites turns a simple form into a foothold for executing commands on the server, with no meaningful authentication. The patch is already available; the open question is how many of those sites have applied it before attackers automate the chain end to end.
A chain of three bugs, not one
CVE-2026-82222 is not a single vulnerability but the assembly of three distinct defects. The first is an unsafe PHP unserialization helper. The second is a donation-processing flow that stores attacker-controlled serialized objects. The third is a gadget chain inside libraries bundled with the plugin, capable of invoking arbitrary system commands.
Each link is harmless on its own. It is their combination that turns a business object — a donation, a profile — into an execution primitive. This is the textbook PHP object injection pattern: the application reads a serialized string, passes it to unserialize(), and the magic methods of the reconstructed objects trigger, hop by hop, a system call.
The decisive detail is that the donation flow writes the object into the wp_give_sessions table before returning an HTTP 500 error. The attacker does not need a valid donation: submitting a crafted object is enough to plant it for later replay.
Disabled registration does not protect you
Exploiting the chain nominally requires an account on the target site. Patchstack showed that this barrier can be bypassed. The plugin exposes an unauthenticated registration action — give_action=user_register — that never consults WordPress’s users_can_register option.
The direct consequence: even on a site where registration is disabled, an attacker can create an account and receive an authentication cookie, then continue in the same sequence. That is what lifts the flaw to critical: the “user account” prerequisite is no longer a prerequisite.
Once authenticated, the attacker stores a malicious serialized object in their profile, then injects it into the plugin’s session database through a crafted donation. All that remains is to request any public page with the cookie: the server deserializes the object and runs the command.
The technical core: a PHP gadget chain
The code execution does not come from a command the attacker types, but from a gadget chain — what researchers call a POP chain, for Property-Oriented Programming. In PHP, certain special methods, the magic methods such as __wakeup(), __destruct() or __toString(), run automatically when an object is deserialized or destroyed, without the application code ever calling them explicitly.
The attacker therefore composes an object whose properties, once restored, trigger those methods in an order that ends in a system call. They are not exploiting a vulnerable function: they are assembling legitimate building blocks already present in the plugin and its dependencies. That is what makes the flaw hard to fix at the root — each block is, in isolation, sound code.
GiveWP’s patch attacks exactly this point: by blocking serialized data upstream, it prevents the chain from forming at all, whatever gadget is available in the bundled libraries. The lesson travels beyond this plugin: any application that deserializes user-controlled data must treat it as a potential execution primitive.
Who is actually exposed
Versions 4.16.6 through 4.16.7.1 remain vulnerable. Exploitation requires one further condition: the site must contain a “legacy” donation form without the formBuilderSettings field. This is not an edge case — it appears on installations upgraded from an older version, on sites using the option-based form editor, and when old forms are imported or restored.
In plain terms, the oldest sites are the most exposed: those carrying a history of upgrades and forms that predate the modern builder. An ageing WordPress estate is precisely the profile attackers automate first.
The 4.16.7.2 fix closes the chain at three levels: it blocks serialized data during donation processing, restricts object creation at several deserialization points, and purges serialized payloads already stored in affected databases. Patchstack notes, however, that the registration action still does not honour WordPress’s registration setting — it is simply no longer exploitable for code execution.
A precedent that carries weight
This is not the first time GiveWP has served as an entry point. Last year, attackers targeted the plugin to indirectly breach Pi-hole, the network ad-blocker, exposing the names and email addresses of 30,000 donors.
The parallel is not incidental. GiveWP handles sensitive data by nature: donor identities, amounts, payment methods. A donation plugin that becomes an RCE vector compromises not just the site but donor trust, and potentially payment data if the site stores it.
WordPress concentrates its risk in extensions
This chain fits a wider trend. The most-exploited flaws in the WordPress ecosystem no longer touch the core but the high-install extensions. GiveWP, with its 100,000 active installs, is exactly the profile attackers automate: one target, one patch, thousands of sites to compromise.
The donation plugin compounds two aggravating factors. It handles sensitive data — donor identity and payment details — and it is often installed on charity or non-profit sites with limited administration. A small organisation is less likely to have dedicated security monitoring than an enterprise, yet it carries the same risk.
The lesson for a WordPress administrator is not to remove plugins but to treat them as full dependencies: inventory, version, security advisories. An unmonitored plugin is a door whose state no one knows.
What to do now
Update GiveWP to 4.16.7.2 immediately. The fix is retroactive against payloads already stored, which simplifies clean-up, but does not replace verification.
Then audit the user account list. The registration flaw allowed account creation even where registration was disabled: look for recent accounts with no legitimate activity, created on sites that do not normally allow sign-ups.
Finally, treat the plugin as a full attack surface. WordPress concentrates most of its risk in extensions, not its core. An inventory of installed plugins, monitoring of their security advisories, and an automatic-update policy for critical extensions are the only realistic defence against this kind of chain.
Patchstack’s write-up underlines why the window mattered: the flaw was reported on 28 July 2026 and fixed on 27 August 2026, a full month later. During that interval, every site on 4.16.6 through 4.16.7.1 carrying a legacy form was a candidate, and the registration bypass meant an attacker did not even need an invitation to get in. Upgraded sites that never rebuilt their old donation forms are the ones most likely to still meet the exploitation conditions today.
Verdict
If you run GiveWP, upgrade to 4.16.7.2 now and purge suspicious accounts. The flaw enables unauthenticated command execution on more than 100,000 sites, and disabled registration never counted as protection.
If you manage a WordPress estate, read this chain as a signal: high-install plugins are now exploited by chaining flaws together, not through one error. Automate extension updates and watch for accounts created outside your normal sign-up flow — that is where the compromise shows up first.