signal

A donation plugin with 100,000+ installs had a perfect-10 flaw

A GiveWP flaw let anyone run commands on a donation site with no login. The vendor patched it fast. The gap that matters now is how fast each site updates.

Go Voltic · published

A vulnerability disclosed on August 28 let an attacker run arbitrary commands on a WordPress site running GiveWP without logging in, without tricking anyone into clicking anything, and on the oldest affected versions, without any special configuration at all. The scoring system used across the industry rates it 10.0 out of 10, the maximum. GiveWP runs on more than 100,000 sites, most of them nonprofits and small organizations collecting donations and storing donor information.

The flaw needed no password and, on older versions, no configuration

The weakness sits in how GiveWP's donation form handler deserializes data submitted by a visitor. Deserialization takes a string and turns it back into a program object, and if that string comes from an untrusted visitor and the code trusts it too much, an attacker can shape the string to construct objects the application never meant to receive. The flaw was found by researcher Udin Chan and reported to Patchstack, which publishes GiveWP's security advisories; its writeup describes the chain as three pieces working together: an unsafe deserialization helper, a registration mechanism reachable without logging in, and a "gadget," a piece of code already present in a library GiveWP ships, that the crafted object triggers to execute commands on the server.

On GiveWP 4.16.5.1 and earlier, Patchstack's advisory states plainly that "a default installation is enough to exploit." No legacy form had to be enabled, no unusual setting had to be switched on. Versions 4.16.6 through 4.16.7.1 narrowed the path, requiring either a legacy form type or an administrator-enabled setting to be reachable, but the flaw was still present and still rated at the same severity once reachable.

The vendor did the responsible thing, and that is not where the risk ends

The disclosure timeline here is close to the industry's own model for how this is supposed to go. The vulnerability was reported on July 28. StellarWP, GiveWP's developer under Liquid Web, shipped a fix in version 4.16.7.2 on August 27, a month later, and the public advisory went out the next day, August 28, after sites had a patched version available to install. The mechanism was not made public until after the fix existed.

That is the part a vendor controls. What happens after August 28 is not. A public advisory naming the exact mechanism, the exact affected version range, and the exact fix is also a set of instructions for anyone who wants to build an exploit and go looking for sites that have not updated yet. The gap that decides whether a given site gets hit is no longer about the vendor. It is entirely about how long that individual installation runs an unpatched version after the fix exists.

What to check on your own site

  1. If you run GiveWP, confirm you are on 4.16.7.2 or later. The plugin directory lists 4.16.8, released September 2, as current. Check under Plugins in your WordPress admin, or the version line in the plugin's readme.txt.
  2. More generally, list every plugin and theme installed on your site, including ones nobody actively maintains content in. A checkout form, a booking widget, or a donation tool installed once and left alone is exactly the kind of software that goes unpatched, because nobody thinks about it until something breaks.
  3. Turn on automatic updates for plugins where you can tolerate an occasional unattended change. WordPress has supported this per-plugin since version 5.5: on the Plugins screen, each plugin has an "Enable auto-updates" action link in the Automatic Updates column. Sites with heavy customization sometimes turn this off deliberately; if yours does, that decision now has to be paired with someone actually watching for advisories.
  4. Keep backups current before turning on auto-updates, so a bad update is a rollback rather than an emergency.
  5. Where a plugin handles anything sensitive, payments, donor or customer records, account logins, treat its advisories as worth checking directly rather than waiting for the general WordPress update nag. GiveWP publishes its own changelog on its plugin page, and Patchstack's public feed covers plugins across the WordPress ecosystem, not just this one.

Why a donation plugin specifically raises the stakes

A vulnerability of this severity would be serious on any site. On a donation platform it lands on data with a narrower, harder consequence: donor names, contact details, and payment-related records, held by organizations that in many cases have no dedicated technical staff watching for this kind of advisory at all. A marketing site with a compromised contact form loses a form. A donation platform with the same class of compromise is handling exactly the kind of information a breach notification law is written to cover, run by exactly the kind of organization least equipped to respond to one.

None of this is a statement about GiveWP's overall security practice. A CVSS 10.0 vulnerability discovered by outside researchers, reported privately, and patched within a month is closer to the system working than to a failure of it. The open question a piece like this can only point at, not answer for a particular site, is whether that patch actually reached every one of the 100,000-plus installations before anyone went looking for the ones that hadn't updated.

Sources

  1. CVE-2026-82222 detail. NVD, read 2026-09-08
  2. Unauthenticated PHP Object Injection to Remote Code Execution on GiveWP. Patchstack, read 2026-09-08
  3. GiveWP plugin directory listing. WordPress.org, read 2026-09-08
  4. Plugin and themes auto-updates. WordPress.org, read 2026-09-08

Run a free Instant Scan on your own site · More from the Newsroom