A Donation Plugin on 100,000 Sites Just Got a 10.0. The Victims Are Food Banks and Animal Shelters, and the Exploit Is Already a Point-and-Click Module.
- Patrick Duggan
- 5 hours ago
- 5 min read
CVE-2026-82222 is a CVSS 10.0 in GiveWP, the WordPress donation and fundraising plugin, affecting every version through 4.16.7.1. An unauthenticated attacker can execute arbitrary commands on the hosting server. The fix is 4.16.7.2. There are more than 100,000 installs.
If you run one of them, stop reading and go update. Everything below will still be here.
Who Actually Runs This Plugin
We write a lot about Fortune 500 breaches because that is where the disclosures are. This one is different and it is worth saying out loud before the technical part.
A donation plugin with a hundred thousand installations is not deployed at banks. It is deployed at food banks. Animal rescues, parish churches, volunteer fire departments, school PTAs, mutual aid groups, a hospice in a market town, the local land trust. Organizations with one contractor who set up the site four years ago and a board member who has the password written down somewhere.
These are the people who have no security team, no WAF, no SIEM, no patch window and no evening free to read a CVE. They are also, structurally, the ones for whom this matters most: the vulnerable surface is the donation form, and the donation form is the one thing they cannot take offline, because it is the money.
That combination — maximum severity, no defensive capacity, and a component you cannot switch off without losing revenue — is roughly the worst configuration available. It is also exactly the population this shop exists to serve, so this post is the whole reason we do the free feed.
What The Bug Actually Is
Three separate weaknesses chained together, which is why the score is a 10.0 rather than a 9-point-something.
First, an unsafe PHP deserialization helper. Second, a donation processing flow that stores attacker-controlled serialized objects — the attacker gets to put their data into a place the application will later trust enough to unpack. Third, a gadget chain inside libraries GiveWP bundles, which turns "this object got unpacked" into "this command got run."
None of those three is a catastrophe alone. That is the recurring lesson of object injection and always has been: the deserialization call is only as dangerous as the classes that happen to be loaded next to it, which means a plugin can inherit a critical vulnerability from a dependency it never audited and does not think about.
PHP object injection was documented as a bug class around 2009. It is producing a maximum-severity unauthenticated RCE on a hundred thousand charity websites in 2026. Some categories do not get solved, they just get rediscovered in a new place every few years by somebody looking carefully.
The Detail That Should Make You Angriest
There is a second issue in the same advisory: an exposed unauthenticated registration action that lets an attacker create an account even when user registration is turned off.
Think about what that means for the administrator. Somewhere in that site's settings, a person made a correct security decision. They found the "anyone can register" checkbox, understood the risk, and unticked it. They did the thing the hardening guide told them to do.
And it did not matter, because a plugin shipped an action path that never consulted the setting.
That is the failure shape we keep naming: the control held, and the handoff between the control and the code that was supposed to honor it was not assigned to anybody. The admin was not careless. Their configuration was correct and unenforced, which is worse than being wrong, because being wrong at least leaves you looking.
If you have ever hardened a WordPress install and felt reasonably good about it afterwards, this is the reminder that your settings are requests, not guarantees, whenever a plugin is in the room.
It Is Already Weaponized
There is a public exploit module for this. Not a proof of concept in a gist, not a technique described in a paper — a module in a mainstream exploitation framework, which means the skill required to use it against a food bank is approximately none.
That collapses the timeline that usually protects small organizations. The comfortable assumption behind "we are too small to be a target" is that exploitation takes effort and attackers spend effort where the money is. A framework module removes the effort. What is left is a scan of the internet for a plugin fingerprint and a list of hosts, and every one of those hosts is worth the same trivial amount to somebody selling access or hosting a phishing page.
Small does not mean safe. It means unnoticed, and unnoticed stops applying the moment somebody writes the module.
Credit where it is owed: the vulnerability was reported by researcher Udin Chan on July 28 through Patchstack, and GiveWP shipped 4.16.7.2 blocking serialized data during donation processing and restricting object creation. That is a disclosure process working as designed. The exposure now is entirely in the gap between a patch existing and a patch being applied, which on volunteer-run infrastructure is measured in months.
What To Do, In Order
Update GiveWP to 4.16.7.2 or later. This is the whole fix and everything else on this list is a consolation prize.
If you genuinely cannot update today, the donation endpoint is the exposure. Putting the site behind any reverse proxy that blocks serialized PHP payloads in request bodies buys you time, and so does taking the donation form offline for an evening, though we recognize what that costs an organization that runs on donations.
Then look for whether it already happened. Check your WordPress user list for accounts you did not create — the registration bypass means new users are the cheapest tell. Look at file modification times under wp-content for anything changed recently that you did not change. Check for PHP files in your uploads directory, which is the classic landing spot and should never contain executable code. And look at outbound connections from the host if your provider gives you any visibility at all.
If you find any of that, the site is a compromised host and not a plugin problem, and restoring from a backup taken before the intrusion is the honest answer.
What We Have On This, Which Is Nothing
We hold no indicators for exploitation of CVE-2026-82222. Our exploit harvester, which watches for public proof-of-concept drops, did not catch this one. Our own morning sweep flagged the story as a gap in our coverage, which is the only reason this post exists.
We are telling you that because the alternative is implying a coverage we do not have. If exploitation attempts start showing up at our edge sensors we will publish the indicators and they will be free like the rest.
We cap confidence at 95 percent. The most likely thing wrong here is scale: install counts on plugin directories are estimates, and how many of those hundred thousand sites are still running an unpatched version a week from now is unknown to everybody, including GiveWP.
Sources
Reporting from BleepingComputer, SC Media and Security Affairs, the Patchstack advisory, and the exploit module documentation from Rapid7. The research is Udin Chan's.
If you know somebody who runs a small charity website, this is the post to forward. They are not reading security news today, and the update takes two minutes.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=a-donation-plugin-on-100-000-sites-just-got-a-10-0-the-victims-are-food-banks-and-animal-shelters
Comments