WordPress Registration Was Disabled. GiveWP Still Created the Account and Reached Server Commands.
GiveWP has fixed a CVSS 10.0 vulnerability that can turn a WordPress donation workflow into unauthenticated remote code execution. The attack does not require WordPress registration to be enabled. GiveWP exposes its own account-creation path, allowing an attacker to cross a boundary the site owner may believe is closed.
The vulnerability, CVE-2026-82222, affects GiveWP 4.16.7.1 and earlier. GiveWP is installed on more than 100,000 WordPress sites and is widely used by charities, campaign groups and other organisations that collect donations online. Version 4.16.7.2 fixes the remote-code-execution chain.
Patchstack published the full technical analysis on 28 August 2026, one day after the fixed version became available. No malicious exploitation has been confirmed, and BlackTree did not locate a standalone public exploit. The disclosure nevertheless provides enough detail to materially shorten exploit development. Administrators should treat the patch as urgent rather than waiting for exploitation reports.
The attack begins with an account the site owner did not enable
The full chain needs a logged-in donor account, but GiveWP can create one for an unauthenticated visitor. Its give_action=user_register handler does not consult WordPress’s users_can_register setting. Disabling registration in WordPress therefore does not close this GiveWP-specific path.
GiveWP 4.16.6 added a nonce requirement to the handler, but that only narrows the exposure. A public page containing the [give_register] shortcode can provide the nonce, and logged-out WordPress nonces are shared among anonymous visitors to the same site for their validity period.
That distinction is the central trust failure. A control visible in WordPress can say registration is disabled while a plugin exposes another identity-creation route with different rules.
Four requests can move from registration to server commands
- Create an account. The attacker uses GiveWP’s registration action and receives an authenticated WordPress session even when normal site registration is disabled.
- Store the object. The attacker places a malicious serialized PHP object in a profile field such as the account’s last name.
- Poison the donation session. A donation submission copies the account data into GiveWP’s session storage. A helper intended to make unserialisation safe converts the object into
__PHP_Incomplete_Class, but preserves its original class name and properties when the value is written back to the database. - Trigger execution. A later front-end request reads the poisoned session without the same restriction. Classes shipped with GiveWP provide a gadget chain that reaches
call_user_func_array(), allowing the attacker to call a function such assystem()under the web-server account.
The malicious object does not arrive directly in the request that executes it. It is stored first and becomes dangerous when trusted application code reads it later. That separation can defeat validation focused only on the final request.
Which GiveWP installations are reachable
| GiveWP version | Reachability described by Patchstack | Required action |
|---|---|---|
| 4.16.5.1 and earlier | A default installation can be exploitable when it has one published donation form and one active payment gateway. Test mode, open WordPress registration and administrator interaction are not required. | Update immediately to 4.16.7.2 or later. |
| 4.16.6 through 4.16.7.1 | A fresh installation using only Visual Form Builder forms is not reachable through the demonstrated path. The chain becomes reachable when any give_forms post lacks formBuilderSettings, including a draft or trashed legacy form. | Do not treat the newer branch as safe. Update, then inventory legacy, imported, restored, draft and trashed forms. |
| 4.16.7.2 and later | The reported object-injection and code-execution chain is fixed at several layers. | Verify the installed version and complete post-update review. |
Sites upgraded from older releases, sites that imported or restored forms, and sites using the option-based form editor are particularly important to identify. A form does not need to be publicly visible to re-enable the vulnerable processing path described by the researchers.
The fix breaks the chain in several places
GiveWP 4.16.7.2 does more than patch one request. It rejects serialized data before donation details are stored, restricts object creation at multiple read points, validates the provider object used by the terminal gadget, sanitises donor and billing names, and adds a migration that removes nested objects already stored in user, donor, donation and session metadata.
This layered approach matters because deserialisation vulnerabilities rarely exist at only one entry point. Blocking the demonstrated write, neutralising the later read and disabling the gadget make alternate paths harder to construct.
One access-control issue remains. According to Patchstack, GiveWP’s registration action still does not honour the normal WordPress registration setting. That behaviour no longer leads to the reported remote-code-execution path after the object-injection fix, but administrators should not assume the WordPress setting governs every registration route exposed by the plugin.
What defenders should do now
- Update GiveWP to 4.16.7.2 or later. Confirm the running code was replaced successfully and that caching or deployment tooling has not left an older copy active.
- Inventory every form state. Include published, draft, trashed, imported and restored donation forms. Check whether older records lack
formBuilderSettings. - Review recent account creation. Look for unexpected subscriber or donor accounts, especially on sites where WordPress registration was believed to be disabled.
- Hunt beyond the plugin. Review web-server child processes, recently modified PHP files, new administrator accounts, scheduled tasks, outbound connections and changes to themes or plugins.
- Preserve evidence when activity is suspicious. Updating removes the vulnerable code, but it cannot prove an exposed site was not compromised before the patch.
- Do not overstate the evidence. The vulnerability is critical and technically detailed, but active malicious exploitation had not been confirmed at the time of writing.
The BlackTree view
The most important lesson is not only that unsafe PHP deserialisation can become code execution. It is that plugins can create identity, storage and execution paths outside the control boundaries administrators believe they configured.
WordPress said registration was disabled. GiveWP still had a registration action. A helper said unserialisation was safe. The object survived. A donation session looked like stored application data. It still carried attacker-controlled instructions into a later read.
Defensive review therefore has to follow the complete workflow, not stop at the setting label or the first validation function.
Sources
- Patchstack technical analysis, published 28 August 2026. No publication time was provided.
- Patchstack vulnerability record, published 28 August 2026.
- GiveWP release and installation information on WordPress.org.
- BleepingComputer independent report, published 28 August 2026 at 14:18. The page does not identify a timezone.
