A visitor who never logs in, never donates, and never passes a login screen can end up able to run commands on the server behind your donation form.
On August 28, 2026, researchers disclosed a maximum-severity flaw in GiveWP, the WordPress donation and fundraising plugin used on more than 100,000 sites (Patchstack, Aug 28, 2026; BleepingComputer, Aug 28, 2026). Tracked as CVE-2026-82222 and rated CVSS 10.0 out of 10, Critical, it allows an unauthenticated attacker to execute arbitrary commands on the hosting server. Every version through 4.16.7.1 is affected; the fix is 4.16.7.2, released August 27, 2026 (NVD; CVE.org). If your nonprofit, church, or charity collects donations through GiveWP, this is the update to prioritize — because the asset at stake is not just a website, it is donor trust.
What happened
GiveWP provides donation forms, payment gateways, donor management, and fundraising reports for nonprofits (Patchstack, Aug 28, 2026). The flaw chains three weaknesses into a single attack.
First, a helper function that was supposed to make stored data safe did not. GiveWP wraps a risky PHP operation in a function called safeUnserialize. That function was meant to neutralize hidden objects in stored data, but it only disguised them for one read and handed the untouched malicious content back to storage (Patchstack, Aug 28, 2026).
Second, the donation flow carried attacker-controlled data straight into that helper. An attacker stores a malicious package in their own account's last-name field, then submits a donation. The plugin builds the donation record from the account data, runs it through the not-actually-safe helper, and saves the result in its session table. The next page load that reads the session back opens the package without any guard (Patchstack, Aug 28, 2026).
Third, code that GiveWP ships with the plugin finishes the job. Two bundled components — the TCPDF library and the plugin's own test-data classes — form what researchers call a gadget chain: a sequence of already-loaded routines that ends in a function capable of running any operating-system command the attacker chooses, as the web server user (Patchstack, Aug 28, 2026).
The part that removes the last barrier: GiveWP hands the attacker the account they need. An unauthenticated registration action creates an account and returns a login cookie without ever checking the site's own registration setting — even on sites where registration is disabled (Patchstack, Aug 28, 2026). Version 4.16.6 added a confirmation token to that handler, but the token is identical for every logged-out visitor on sites that show the registration form publicly, so an attacker simply reads it once and reuses it (Patchstack, Aug 28, 2026).
The timeline is compact. Researcher Udin Chan reported the flaw to Patchstack on July 28, 2026; Patchstack confirmed it the same day, disclosed it to the vendor, and assigned CVE-2026-82222 (Patchstack, Aug 28, 2026). Patchstack notes it rejected several incomplete patch attempts before the vendor shipped the final fix in 4.16.7.2 on August 27 (Patchstack, Aug 28, 2026). The public advisory, the NVD record, and BleepingComputer coverage all landed on August 28, with mainstream security-press follow-up including SCWorld in early September.
One precision matters, because most headlines blur it. Having GiveWP installed is the ceiling, not the exposure. On 4.16.5.1 and below, a default setup is enough to exploit: one published donation form plus an active payment gateway, both of which ship active out of the box, with no special modes or admin action needed (Patchstack, Aug 28, 2026). On 4.16.6 through 4.16.7.1, the path narrows but does not close: a single older-style donation form without the newer form-builder settings re-arms the whole chain — in any status, including draft and trashed. That covers every site upgraded from an older version, any imported or restored form, and any site with the option-based form editor enabled (Patchstack, Aug 28, 2026; BleepingComputer, Aug 28, 2026).
Why this matters to website owners
For a shop, a server compromise means stolen orders. For a nonprofit, it means something harder to rebuild: donor confidence.
A donation page is where your most trusting visitors arrive — people ready to hand over their name, email, address, and payment details because they believe in the cause. A flaw that lets a stranger run commands on that server puts every one of those things within reach: reading donor records, redirecting donations, installing hidden backdoors, or sending mail from your domain. The CVSS rating itself confirms the scope: complete loss of confidentiality, integrity, and availability (NVD; CVE.org).
Three things make this pattern worse than a typical website bug.
First, the entry point looks like generosity. Nothing about the attack resembles a break-in to a visitor. Someone creates an account, edits a profile name, and submits a donation. Behind the scenes, the profile name is a weapon and the donation is the delivery vehicle. Your genuine donors see nothing unusual.
Second, the damage outlives the patch. Data saved before the update can keep a live malicious package sitting in the database. Updating closes the hole for new attacks, but a site poisoned earlier needs the cleanup the fix includes — which is why the "update and move on" instinct falls short here.
Third, the sector has been here before. Attackers targeted GiveWP last year as the indirect route into Pi-hole, the popular ad-blocking project, exposing the names and email addresses of 30,000 donors (BleepingComputer, Aug 28, 2026). Donation plugins are attractive precisely because one compromise can yield thousands of donor identities — and because small nonprofits rarely have anyone watching server logs.
What to do
Update GiveWP to 4.16.7.2 or later. In WordPress, go to Dashboard then Updates, or ask the person who maintains the site to apply it and confirm the version number. This comes first because the release fixes the chain at several independent layers: it stops storing raw serialized data from donation fields, restricts object creation where stored data is read back, and tightens the final link in the chain (Patchstack, Aug 28, 2026; BleepingComputer, Aug 28, 2026). Updating is the fix; everything below is verification. If you use Patchstack, its mitigation rules can shield unpatched sites in the meantime — but treat that as a bridge to the update, not a substitute.
Let the update finish its cleanup, then verify donor records. Version 4.16.7.2 includes a database migration that walks donor, donation, and session tables and removes hidden object packages left by earlier attacks (Patchstack, Aug 28, 2026). The reason this step is built into the fix is that a poisoned database stays dangerous after the code is patched. After updating, ask your developer or host to confirm the update completed without errors, then review for signs of earlier abuse: unexpected administrator accounts, unfamiliar files or scheduled tasks, donation records or donor names containing strange text, and any period where donation totals or confirmation emails behaved oddly.
Ask your developer for a focused review of the donation path. The right question is narrow: which donation forms does the site have, including drafts, trashed forms, and imports, and which ones use the older form style. The reason is the reachability nuance above — a forgotten draft form can keep an otherwise modern site exposed on the 4.16.6 through 4.16.7.1 branch. While they are there, have them confirm the site is on the current GiveWP release and that automatic updates for plugins are on, so the next critical fix does not wait for someone's monthly routine.
Tell donors plainly if you find signs of compromise. Donor trust is the asset this flaw threatens most. If the review turns up evidence that the site was abused — rogue accounts, strange donation records, unfamiliar files — treat it as an active incident and get a focused security review rather than stopping at deletion. A short, honest note to affected donors about what happened, what was fixed, and what you are watching costs less than the silence that follows a second discovery.
Key numbers
- 100,000+ active installations of GiveWP — Patchstack, Aug 28, 2026; BleepingComputer, Aug 28, 2026.
- CVSS 10.0 out of 10, Critical, CWE-502 deserialization of untrusted data — NVD (CNA: Patchstack); CVE.org. (WPScan rates the same flaw at 9.8; the CNA score is used here as primary.)
- Affected: all versions through 4.16.7.1; fixed: 4.16.7.2, released Aug 27, 2026 — NVD; Patchstack timeline; BleepingComputer.
- Reported Jul 28, 2026 by Udin Chan via Patchstack; advisory Aug 28, 2026; mainstream security-press follow-up in early September including SCWorld — Patchstack; NVD; BleepingComputer; SCWorld.
- Precondition (precise): on 4.16.5.1 and below, one published donation form plus an active gateway (default setup qualifies); on 4.16.6–4.16.7.1, one legacy-style form in any status re-arms the chain — Patchstack.
- Precedent: prior GiveWP abuse indirectly breached Pi-hole, exposing 30,000 donor names and emails — BleepingComputer, Aug 28, 2026.
- Remainder: the registration action still does not honor the site's registration setting — an access-control issue that is no longer a path to code execution once patched — Patchstack.
Final takeaway
A donation form is a promise: give generously, and we will guard what you share. This flaw broke that promise silently — no login, no alarm, just a profile name and a donation turning into server commands. Version 4.16.7.2 restores it, including cleanup of poisoned records left behind. Update, verify the donation path including forgotten drafts, and keep automatic updates on. That is an afternoon of work that converts your highest-trust page back into the thing it should be: a safe place to give.
Is your site ready? Run a free security scan — 40+ automated checks, instant results, no commitment.