GiveWP Has a CVSS 10 RCE — 100,000 WordPress Sites Are in the Blast Radius
- The Mess: A critical GiveWP vulnerability, CVE-2026-82222, lets unauthenticated attackers inject PHP objects and execute arbitrary commands on vulnerable WordPress servers. GiveWP versions through 4.16.7.1 are affected.
- The Damage: An attacker doesn’t need an account, a password or a victim’s click — a vulnerable donation plugin can become a direct route to full server compromise.
- The Fix: Update GiveWP to 4.16.7.2 or later immediately and investigate the site if an affected version was exposed to the Internet.
WordPress plugins don’t normally get treated like remote shells.
This one can.
CVE-2026-82222 gives an unauthenticated attacker a path from a crafted request to PHP object injection and remote code execution on the hosting server. The vulnerability carries a CVSS 10.0 score.
And GiveWP isn’t some obscure plugin hiding on a forgotten development server.
Patchstack lists roughly 100,000 installations.
No Login. No Click. No Problem.
The ugly part is the attack requirements.
The vulnerability is rated:
Network
Low complexity
No privileges
No user interaction
That means the attacker doesn’t need to convince an administrator to click a fake CAPTCHA.
They don’t need a stolen WordPress account.
They don’t need to authenticate first.
The vulnerable application is the target.
The Bug Lives in PHP Deserialization
CVE-2026-82222 is classified as CWE-502 — Deserialization of Untrusted Data.
GiveWP processes attacker-controlled data in a way that can allow PHP object injection.
That becomes much more dangerous when the application contains a usable gadget chain.
Patchstack researchers demonstrated exactly that: an unauthenticated request can reach the vulnerable deserialization logic and ultimately trigger arbitrary command execution.
In other words:
HTTP request
↓
PHP object injection
↓
gadget chain
↓
remote code execution
No WordPress login required.
It Can Become a Server Takeover
RCE isn’t just another scary acronym.
Successful exploitation gives the attacker the ability to execute commands on the server.
From there, the attacker can potentially:
modify website files
install a backdoor
create persistence
steal credentials
access databases
alter donation functionality
or use the compromised WordPress installation as a launching point against other systems.
Patchstack explicitly warns that the flaw can be used to gain backdoor access and take full control of the website.
GiveWP Is a Donation Plugin
That makes the situation particularly interesting.
GiveWP is designed to handle online donations and fundraising.
So a compromised installation isn’t necessarily just a blog.
It can sit on a website processing:
donation requests
donor information
payment integrations
user accounts
and other application data.
The attacker doesn’t have to care about the WordPress homepage.
The interesting material can be sitting behind it.
The Patch Is Already Available
The good news:
GiveWP 4.16.7.2 fixes the vulnerability.
Versions 4.16.7.1 and earlier are affected according to Patchstack.
WordPress.org’s current changelog shows security-related releases throughout August, including 4.16.7.1 on August 24.
That means administrators should not assume that “the latest version I installed last week” is necessarily safe.
Check the exact version.
The Timing Is Interesting
The vulnerability was reported to Patchstack on July 28.
Patchstack published the vulnerability information on August 28.
The CVE was published on August 28 as well.
That’s a very short window for defenders once the technical details become public.
Attackers can now study the disclosure.
They can study the patch.
They can reproduce the vulnerable code.
And they can automate scanning.
This Is Where WordPress Gets Dangerous
A vulnerable WordPress plugin doesn’t need to be installed on a famous website.
Attackers don’t care whether the site gets:
10 million visitors
or
17 visitors and the owner’s mother.
If the vulnerable endpoint is reachable, automation can find it.
That’s why plugin vulnerabilities are so attractive for mass exploitation.
Patchstack specifically warns that vulnerabilities like this are expected to become targets for mass-exploitation campaigns.
The Exploit Doesn’t Need a Human
We’ve recently seen WordPress attacks built around ClickFix, fake reCAPTCHA pages and social engineering.
GiveWP is different.
There is no need for that extra layer.
The theoretical chain is much simpler:
Internet
↓
GiveWP
↓
CVE-2026-82222
↓
RCE
That is exactly the sort of vulnerability attackers like to automate.
Don’t Confuse This With the Older GiveWP Bugs
GiveWP has accumulated several security fixes during August.
There are separate issues involving:
broken access control
XSS
authorization
and other weaknesses.
CVE-2026-82222 is different.
It’s the one with the CVSS 10.0 remote-code-execution impact.
That’s why it deserves its own warning.
What Administrators Should Do
First:
check the GiveWP version.
If it is:
4.16.7.1 or older
update immediately.
The safe version is:
4.16.7.2+.
Second:
don’t assume updating is enough if the server was exposed while vulnerable.
Look for:
unexpected PHP files
new WordPress administrators
modified plugins
unknown cron jobs
suspicious scheduled tasks
unexpected outbound connections
and
recent requests targeting GiveWP endpoints.
If You Already Updated
Good.
Now check the logs.
This is the difference between:
“we patched the vulnerability”
and
“we know nobody exploited it.”
The first statement is easy.
The second requires evidence.
The 100,000 Number Matters
Patchstack lists approximately 100,000 installations of GiveWP.
That doesn’t mean 100,000 websites are compromised.
It means the potential deployment footprint is large enough to make automated exploitation attractive.
One exploit.
Thousands of targets.
Potentially one mass campaign.
That’s how WordPress incidents scale.
The Payment Angle Makes It Worse
A compromised donation website creates an obvious secondary target.
An attacker who gains control could potentially tamper with the site’s donation flow or use the compromised server to harvest information.
That doesn’t mean CVE-2026-82222 has already been used for payment theft.
There is no basis for claiming that.
But once arbitrary code execution exists, defenders have to consider what the compromised application could access.
This Is a Server-Side Problem
The victim doesn’t have to be sitting in front of Windows.
There doesn’t have to be malware on the user’s PC.
The initial compromise happens on the WordPress server.
That’s why this vulnerability belongs in the same category as the bugs administrators should patch before attackers turn them into infrastructure footholds.
CVSS 10 Doesn’t Mean “Guaranteed Breach”
A CVSS 10 score doesn’t mean every vulnerable site has been compromised.
It means the vulnerability’s technical characteristics and potential impact are at the maximum end of the scoring system.
For CVE-2026-82222, the important combination is:
remote
unauthenticated
no user interaction
arbitrary code execution.
That’s bad enough without exaggerating it.
Bugstoday Opinion
This is exactly the kind of WordPress vulnerability that shouldn’t be allowed to sit in the update queue.
Not because it has a flashy name.
Not because somebody posted a scary screenshot.
Because the attack requirements are brutally simple.
No account.
No password.
No click.
Just a vulnerable GiveWP installation exposed to an attacker.
The fix already exists.
So there is very little reason to gamble.
Bugstoday verdict: CVSS 10 is justified here. GiveWP isn’t merely leaking information or breaking a permission check — CVE-2026-82222 can turn an unauthenticated request into remote code execution on the WordPress server. With roughly 100,000 installations in the wild, waiting for the first mass-exploitation campaign would be an exceptionally bad patching strategy. Update to 4.16.7.2 or later. Then check the logs.
