GiveWP plugin flaw let unauthenticated attackers run commands on 100,000+ WordPress sites
Chaining three separate weaknesses turned the donation plugin into a remote code execution path, no valid account required. A fix shipped August 27.
A hundred thousand installations, a maximum CVSS score of 10.0, and an exploitation chain that did not even require a working account on the target site. The flaw in GiveWP, a widely used WordPress plugin for accepting online donations, checks every box of an incident administrators should treat as urgent rather than routine.
Researcher Udin Chan found it and reported it through the Patchstack platform on July 28. The bug chains three distinct weaknesses: an unsafe PHP deserialization helper, a donation-processing flow that stores attacker-controlled serialized objects, and a gadget chain inside bundled libraries that ultimately allows arbitrary system command execution.
On paper, exploitation usually requires an attacker to already hold an account on the target site. The detail that changes everything: an unauthenticated registration action stayed exposed even when public registration was switched off in WordPress settings, letting an attacker create an account anyway and route straight past that protection.
A hundred thousand installations, a maximum CVSS score of 10.0, and an exploitation chain that did not even require a working account on the target site.
GiveWP fixed the issue in version 4.16.7.2, released August 27, blocking serialized data during donation processing and restricting object instantiation. The advice for any site administrator running the plugin is short and does not leave room for waiting: update now.
This kind of bug is a recurring lesson for the WordPress ecosystem specifically. Core itself is maintained tightly and patched fast in the overwhelming majority of cases. The real attack surface is the sum of every plugin installed on top of it, and each one adds its own exposure. A donation plugin, frequently running on nonprofit and community-organization sites without a dedicated technical staff, is exactly the kind of install where a critical patch can sit unapplied for weeks after release.
That gap between release and application is where most of the real-world damage in plugin ecosystems actually happens. Researchers routinely find mass scanning activity targeting a WordPress vulnerability within 48 to 72 hours of a public writeup, well before the tail end of any plugin's install base has updated. GiveWP's own numbers illustrate the problem: over 100,000 active installs is a large population to expect to move in unison, and a single unpatched nonprofit site can sit exposed for months without anyone noticing, since a compromised donation form does not necessarily announce itself the way a defaced homepage would.
Based on reporting by BleepingComputer.
