GiveWP CVE-2026-82222: registration bypass plus PHP object injection add up to unauthenticated RCE — fixed in 4.16.7.2

TL;DR — 90 seconds

Affected?

GiveWP (WordPress donation plugin) up to version 4.16.7.1, with over 100,000 active installations per the WordPress plugin directory. Installations with older donation forms lacking the formBuilderSettings field are especially exposed.

Risk?

A chain combining PHP object injection in donation processing with a bypass of the registration lock (the registration action never checks the users_can_register option) adds up to unauthenticated remote code execution. Press coverage rates the flaw as "maximum severity"; no official CVSS vector was available in the sources we reviewed as of this post — we'll update this post once one is published.

Immediate action?

Update to GiveWP 4.16.7.2 (released Aug 27, 2026). The patch blocks serialized data in donation processing, restricts object creation at the deserialization points, and removes already-stored malicious payloads from the database.

Recommendation?

Patch immediately, regardless of your next maintenance window — a donation plugin typically handles personal and payment-adjacent data, and the flaw is exploitable without authentication.

Criticality?

high to critical — an unauthenticated RCE chain, actively discussed, in a widely deployed plugin.

What is the problem?

CVE-2026-82222 is not a single flaw but a three-part chain that the GiveWP team and security researchers broke down jointly:

1. Unsafe deserialization helper: an internal check meant to detect and block serialized data in input can be bypassed with specific input patterns.
2. Donation processing without sufficient validation: donation-processing form fields store attacker-controlled serialized objects without validating their structure against an allowlist.
3. Gadget chain in bundled libraries: already-known POP (property-oriented programming) gadget chains in GiveWP's bundled dependencies turn the deserialized objects into actual command execution.

Compounding the problem, GiveWP ships its own registration action that never consults the WordPress users_can_register option. An attacker can therefore create a user account even when registration has been explicitly disabled in the WordPress backend — fully bypassing what was meant to be an authentication hurdle. Combined, the result is a vulnerability that, despite involving several components, ends up exploitable without any authentication.

This bug class is not new for GiveWP: back in January 2025, the team closed CVE-2025-22777 (CVSS 9.8), a structurally similar PHP object injection flaw where a regex-based serialization check could be bypassed with URL-encoded special characters. And in 2024, an earlier PHP object injection vulnerability in GiveWP was used to gain access to roughly 30,000 donor records via compromised environments. Recurring deserialization bypasses in the same codebase are a pattern worth factoring into your risk assessment.

Who is affected?

Check your installed version in the WordPress backend under Plugins → Installed Plugins, or via WP-CLI:

wp plugin get give --field=version

Impact

At the end of the chain sits remote code execution in the context of the hosting server — not just manipulation of WordPress content. A successful attack potentially gives an unauthenticated attacker full access to the entire WordPress installation and its database, to all personal and payment-adjacent donor data stored in donation processing, and — depending on the hosting environment — to other applications running on the same server.

Donation plugins are an especially attractive target: they process names, addresses, email addresses, and sometimes payment references, often for nonprofit organizations that less frequently have dedicated security teams than commercial operators do. The pattern of repeated deserialization flaws in this exact codebase — most recently in 2024 with a leak of roughly 30,000 donor records, in January 2025 with CVSS 9.8, and now again with a chain rated maximum severity — raises the urgency: anyone running GiveWP should treat updates in this category as a standing priority rather than something to weigh case by case.

Mitigation / immediate steps

Operational decision block

• Act now if … your GiveWP installation runs a version up to 4.16.7.1 and the donation form is publicly reachable — practically the default case.
• Check with priority if … you're running older, non-migrated donation forms without formBuilderSettings.
• Next regular window if … GiveWP is already updated to 4.16.7.2 or newer.

Step 1 — check version and update

# check installed version
wp plugin get give --field=version

# apply the update (WP-CLI)
wp plugin update give

# target version: 4.16.7.2 or newer
wp plugin get give --field=version

Alternatively, in the WordPress backend under Plugins → Installed Plugins → Give → Update Now. Do this outside your next regular maintenance window — the flaw is exploitable without authentication.

Step 2 — double-check the registration setting

# check current state of the registration option
wp option get users_can_register

Important: this option alone does not protect you while the vulnerable plugin version is active — the reported bypass works around exactly this check. It's still worth hardening as a defense against other attack paths.

Step 3 — identify legacy forms

In the GiveWP forms overview, check which donation forms have not yet been migrated to the current form builder (forms without formBuilderSettings). Re-test these with priority after updating.

Step 4 — if an immediate update isn't possible

Consider a temporary WAF rule that inspects POST requests to the donation-processing endpoints for typical serialized PHP object signatures (e.g., patterns like O: followed by a digit and a colon in URL-decoded fields) — as a stopgap, not a substitute for the update.

Detection / verification

Plugin version and patch status

wp plugin get give --field=version
wp plugin status give

Check for suspicious user accounts

If registration was disabled in the backend but the bypass was used anyway, recently created accounts should stand out:

# list user accounts created in the last 30 days
wp user list --fields=ID,user_login,user_registered,roles --orderby=registered --order=DESC

Pay particular attention to accounts with unusual login names or email domains that coincide in time with anomalous traffic to the donation form.

Check the database for suspicious serialized payloads

PHP object injection payloads typically follow the pattern O:<length>:"<class name>". Search the donation-processing postmeta/form metadata for unusual entries of this shape:

# rough search for suspicious serialized object signatures in wp_postmeta
wp db query "SELECT post_id, meta_key, LEFT(meta_value, 80) FROM wp_postmeta WHERE meta_value LIKE 'O:%:\"%' LIMIT 50;"

Hits aren't automatically malicious — GiveWP legitimately uses serialization in places — but they're a good starting point for manually reviewing unusual class names that don't come from your own theme/plugin stack.

Web shells and unexpected files

# recently modified PHP files in the uploads directory (unusual, since PHP files typically shouldn't be there)
find wp-content/uploads -name "*.php" -newer wp-content/plugins/give/give.php

As of this post, no publicly published indicators of compromise (IOCs) specific to CVE-2026-82222 are available — the steps above are best practices derived from the known vulnerability class (PHP object injection in GiveWP), not confirmed indicators for this specific case.

Operator guidance

Mid-market / nonprofit organizations

Update to 4.16.7.2 immediately — regardless of your regular update cycle. Donation platforms often carry particular trust from donors; an incident damages that trust independent of the technical severity.

Enterprise / multi-site operators

Beyond the update: audit user accounts from the past few weeks, review donation metadata for suspicious serialized payloads, and review all older, non-migrated donation forms. If you run multiple WordPress instances with GiveWP, maintain a central inventory — individual legacy installations are commonly overlooked in rollouts like this.

Agencies with GiveWP client projects

Proactively identify all managed installations and roll out the update rather than waiting for individual client requests — with an unauthenticated, exploitable RCE chain in a widely used plugin, being proactive is cheaper than reacting after an incident.

Decision block

Act today if: GiveWP is running in production with a publicly reachable donation form on a version up to 4.16.7.1. Monitoring is enough if: you've already updated to 4.16.7.2 and found no anomalies in user accounts or donation metadata.

Conclusion

CVE-2026-82222 is a textbook example of why individually "minor" weaknesses become dangerous in combination: on its own, neither an incomplete serialization check nor an overlooked option check on registration would be a critical finding — together they add up to unauthenticated remote code execution in a plugin with over 100,000 installations. The pattern is also notable: GiveWP has reported multiple structurally similar PHP object injection vulnerabilities within roughly two years. Anyone running the plugin should treat updates in this category as a standing high priority rather than something to weigh case by case — and, when in doubt, check whether fully migrating all donation forms to the current form builder further reduces the attack surface.

Sources

• BleepingComputer — GiveWP WordPress donation plugin flaw lets hackers execute server commands (Aug 28, 2026)
• SC World — Critical vulnerability in GiveWP plugin allows remote code execution (Aug 28, 2026)
• The Hacker Wire — CVE-2026-82222: Deserialization of Untrusted Data Vulnerability
• Patchstack — GiveWP PHP object injection history (earlier CVE-2025-22777, for comparison of the bug class)
• GiveWP — official update documentation
• WordPress.org — GiveWP plugin directory