GiveWP CVE-2026-82222: The CVSS 10.0 Deserialization Chain That Makes Every Published Donation Form an Unauthenticated RCE Path

digital interactive web development hero image

A Perfect Ten. That Is Not a Good Thing.

On August 28, 2026, Patchstack published CVE-2026-82222 against GiveWP — the fundraising and donation plugin with more than 100,000 active WordPress installations. The CVSS score is 10.0. That is the ceiling. No rounding, no reclassification pending. Maximum severity, network-accessible, no authentication required, no user interaction needed.

This is the first confirmed CVSS 10.0 WordPress plugin vulnerability of 2026, and it arrived on the same week that Everest Forms dropped its own CVSS 9.8 file-upload flaw affecting a separate 100,000 sites. The timing is coincidental. The underlying pattern is not.

What the Flaw Actually Does

Three separate weaknesses chain into one complete attack. None of them is exploitable in isolation the way a typical SQLi or auth bypass works. Together they hand an attacker arbitrary OS command execution on the server.

The first link is a broken safeUnserialize() helper inside GiveWP. The function was written to prevent unsafe deserialization of user-controlled data. It does not. Attacker-controlled serialized objects pass through it without meaningful filtering and get written into the site’s database during the donation processing flow. That is the storage step.

The second link is the donation processing flow itself. GiveWP’s payment gateway pipeline accepts and stores the serialized payload that safeUnserialize() failed to block. At this point the attacker’s object is sitting inside the database, waiting.

The third link is a gadget chain shipped inside GiveWP’s own bundled libraries. Gadget chains are sequences of existing class methods that, when triggered during deserialization, execute in a path the developer never intended — in this case, running arbitrary operating system commands. The gadget chain is not attacker code. It is GiveWP’s own code being redirected.

Versions 4.16.5.1 and earlier have a default attack path: one published donation form, one active payment gateway, and the site is fully exploitable with no credentials. GiveWP narrowed that path in versions 4.16.6 through 4.16.7.1, but the underlying deserialization flaw remained open. Version 4.16.7.2 breaks the chain at two independent points — blocking serialized data during donation processing and restricting object creation in the gadget chain path.

The Registration Bypass That Completes the Picture

Patchstack flagged a separate but related problem. GiveWP exposes an unauthenticated registration action at give_action=user_register. That action never consults WordPress’s users_can_register option. A site with public registration disabled can still have an account created through this endpoint. On sites where the vulnerability requires an existing account, this bypass restores the fully unauthenticated attack surface.

That combination — broken deserialization, a gadget chain producing OS command execution, and a registration endpoint that ignores your site’s own settings — is why this got a 10.0 and not a 9.8.

What Is at Risk on a Donation Site

GiveWP is not a generic contact form plugin. Sites running it are typically processing charitable donations, collecting donor personal data, and in many configurations storing or transmitting payment information via active payment gateways. The required condition for exploitation — “one published donation form and one active payment gateway” — describes a live fundraising site in normal operating state, not an edge-case configuration.

Successful exploitation gives an attacker a server shell. From there: database credential theft, donor record exfiltration, payment data access depending on the gateway integration, or use of the compromised server as infrastructure for further attacks. GiveWP has been targeted before. Attackers previously exploited a GiveWP vulnerability to breach the Pi-hole project indirectly, exposing the names and email addresses of 30,000 donors.

The Week’s Broader Context

CVE-2026-82222 was not the only critical form-related WordPress vulnerability disclosed this week. Everest Forms (CVE-2026-19598, CVSS 9.8) dropped August 26 with an identical class of flaw — insufficient file-type validation in the EVF_Form_Fields_Upload class, unauthenticated file upload, full RCE via PHP web shell. That vulnerability affects Everest Forms versions before 3.0.9.5 and hits more than 100,000 sites. Patch is version 3.0.9.5 or later.

Two CVSS 9.8-or-higher file-upload or deserialization RCE vulnerabilities in separate form plugins published within 48 hours of each other is not a coordinated attack campaign. It reflects the pace at which WordPress plugin security research is now running — and the speed with which researchers and threat actors both scan that research once it publishes.

What to Do Right Now

For GiveWP: update to version 4.16.7.2 immediately. If an immediate update is not possible, disable the plugin until the update can be applied. Check wp-content/uploads/ and any directories accessible via your web server for unexpected PHP files. Review administrator account lists for accounts you did not create — the give_action=user_register bypass can create accounts silently.

For Everest Forms: update to 3.0.9.5 or later. Inspect wp-content/uploads/ for recently created PHP files. Log review should focus on POST requests hitting form upload endpoints from unexpected IPs.

Rotate credentials — WordPress admin password, database password, hosting panel — if you have any reason to believe a vulnerable version was running on a site with active donation forms or public-facing Everest Forms file-upload fields. The Patchstack State of WordPress Security in 2026 whitepaper documented that the weighted median time to first exploit for heavily targeted vulnerabilities is five hours from disclosure. Both of these dropped August 26–28.

Confidence and Evidence Notes

All technical details on CVE-2026-82222 source from Patchstack disclosure data, BleepingComputer, and The Repository’s coverage of the GiveWP patch notes. The CVSS 10.0 score is confirmed across multiple independent trackers. The claim that versions 4.16.6 through 4.16.7.1 narrowed but did not close the attack path comes from The Repository’s patch analysis. The Pi-hole breach reference is confirmed by BleepingComputer’s prior reporting. No exploit code has been published as of August 28, 2026.

Confidence: High.

Sources: