CVE-2026-82222 is about as severe as a WordPress vulnerability gets: a perfect CVSS 10.0, unauthenticated, and remote code execution — on GiveWP, a donation plugin running on well over 100,000 sites. If a site has GiveWP active with at least one published donation form and one active payment gateway, that’s all the attacker needs. No login, no clicked link, no user interaction anywhere in the chain.
How the Exploit Chain Works
The root cause is PHP Object Injection (CWE-502, Deserialization of Untrusted Data). GiveWP’s donation-processing flow includes a “safe unserialize” helper meant to block dangerous object types from being reconstructed out of attacker-supplied data — but that helper has a flaw that lets serialized data through anyway. Because the donation flow feeds attacker-controlled input into that broken helper, and GiveWP itself ships classes that can be chained into a working “gadget chain,” an attacker can submit crafted donation data that gets deserialized into arbitrary PHP objects and ultimately executes commands on the server. Every link in that chain — the broken helper, the attacker-reachable input, and the gadget classes — already exists inside GiveWP itself; nothing external is required.
Who’s Affected
| Version | Status |
|---|---|
| 4.16.7.1 and earlier | Vulnerable — update immediately |
| 4.16.7.2 or later | Patched |
What to Do Right Now
- Update GiveWP to 4.16.7.2 or later before anything else — there’s no meaningful mitigation short of patching, since the flaw doesn’t require any specific configuration beyond having a live form and gateway, which is the plugin’s normal operating state.
- Check server logs for unusual donation-endpoint requests from before you patched, particularly unusually large or malformed POST bodies to donation processing URLs.
- Look for unfamiliar files in your uploads directory or webroot — a successful RCE is typically used to drop a persistent webshell.
- Rotate secrets (database credentials, API keys stored in wp-config.php) if you find any sign the vulnerability was actually exploited, since RCE gives an attacker read access to everything on the server, not just the database.
Why a Perfect 10.0 Score
CVSS 10.0 is reserved for the worst realistic case: no privileges required, no user interaction, full impact on confidentiality, integrity, and availability, exploitable over the network. Object injection bugs that chain into RCE routinely score this high because there’s effectively no floor to what an attacker can do once arbitrary code execution is achieved — it isn’t a narrow data leak or a single broken permission check, it’s the entire server.
This is a similar vulnerability class — untrusted data reaching a dangerous sink without proper validation — to the Forminator Forms RCE we covered recently, and it’s worth treating both the same way: patch first, investigate second. Need a hand auditing a site running GiveWP? Get in touch.
Frequently Asked Questions
Do I need an active donation campaign for this to matter?
You need one published donation form and one active payment gateway — which describes the normal, intended setup for almost every live GiveWP site, not an edge case.
Can a web application firewall protect me until I update?
A WAF might catch some exploitation attempts, but object injection payloads can be obfuscated in ways that are hard to reliably detect. Treat a WAF as a supplement, never a substitute for patching a CVSS 10.0 RCE.
Is this the same bug as other recent PHP object injection CVEs in WordPress plugins?
No — each is a distinct vulnerability in its own plugin’s code, though object injection as a bug class shows up repeatedly across the ecosystem whenever a plugin deserializes data it hasn’t fully validated first.
Featured image: original illustration.