GiveWP Max-Severity Flaw Turns Donation Forms Into Remote Shells

A max-severity GiveWP flaw turns a WordPress donation form into a remote shell

If your organisation raises money through a WordPress site, there is a good chance it runs GiveWP. The plugin sits on more than 100,000 installations, which makes CVE-2026-82222, rated maximum severity, a problem for a large and badly under-defended slice of the web: churches, NGOs, schools, and community fundraisers that nobody assigns a security team to.

The vulnerability lets an unauthenticated attacker execute arbitrary commands on the hosting server. Not the WordPress admin panel, the server underneath it. Patchstack researcher Udin Chan reported it on July 28, and version 4.16.7.2 shipped a fix on August 27. If you have not updated, assume you are exposed until proven otherwise.

How the attack chain works

No single bug here gives you code execution. The exploit chains three weaknesses, and the first one is the quiet killer.

GiveWP exposes a registration action, give_action=user_register, that never checks WordPress’s own users_can_register setting. Patchstack’s George Johnstone puts it plainly: even on a site where registration is disabled, an attacker can create an account and receive an authentication cookie, then carry out the rest of the attack in the same sequence.

Once logged in as a phantom account, the attacker:

• Stores a malicious serialized object in their user profile.
• Submits a crafted donation, which injects that object into the plugin’s session database. The server writes the gadget into wp_give_sessions before returning an HTTP 500 error.
• Requests any front-end page with their cookie. The server unserializes the gadget and runs the attacker’s command.

That is a classic PHP object-injection gadget chain, the kind people in this industry assumed was solved a decade ago. It still ships in plugins used by hundreds of thousands of sites because donation forms accept flexible data structures, and session storage trusts whatever comes back.

The patch is good, the root cause is not

Version 4.16.7.2 blocks serialized data during donation processing, restricts object creation at several deserialization points, and clears serialized payloads already sitting in affected databases. That closes the code-execution path.

But Patchstack notes the registration action still ignores WordPress’s registration settings. It is no longer exploitable for this attack, yet the design flaw remains in the codebase, and a future deserialization sink could make it live again. Sites running 4.16.6 through 4.16.7.1 with legacy donation forms (anything without formBuilderSettings, common after migrations or restores) were the softest targets.

Why African enterprises should care

Donation rails in South Africa, Nigeria, and Kenya run overwhelmingly on WordPress. The same plugin that processes a township school’s Term-2 fees appeal can hand an attacker a root shell on the host, and from there the damage spreads to everything else on that shared server, including email, donor records, and every other site the organisation runs.

This is not hypothetical. Last year attackers targeted GiveWP to breach Pi-hole indirectly, exposing the names and email addresses of 30,000 donors. Donation infrastructure is soft-target infrastructure by definition, and threat actors have noticed.

What to do now

1. Update GiveWP to 4.16.7.2 now, not next sprint.
2. Audit your user table for accounts you did not create, especially ones registered since late July.
3. Check wp_give_sessions for entries you cannot explain.
4. If your hosting setup allows it, restrict PHP object deserialization at the application boundary instead of trusting plugin hygiene.
5. Assume the registration bypass was used if you patched late. Rotating host credentials is cheap insurance.

eHawu works at the network layer, which is where breaches move after the initial foothold. A plugin vulnerability is how an organisation ends up on the evening news; what keeps it there is the absence of detection once an attacker is inside. If you run donation platforms, fundraising portals, or any WordPress estate that touches payments, you need your patch routine and your monitoring to cover each other. That gap is what eHawu was built for.