GiveWP Plugin Flaw Enables Unauthenticated Command Execution

Why the flaw matters

GiveWP’s donation plugin, sitting on more than 100,000 WordPress sites, silently handed an attacker a way to execute arbitrary commands on the server – and they didn’t even need a valid WordPress account to start.

Technical walk‑through

The chain begins with the unauthenticated registration endpoint give_action=user_register. Although site owners may have disabled user sign‑ups, the endpoint still creates a new WordPress user when called.

Once logged in, the attacker stores a maliciously crafted serialized PHP object in their user profile. A later donation request injects that object into the wp_give_sessions table. When the front‑end processes the next request, WordPress unserializes the data and runs the attacker‑supplied system command.

The vulnerability only affects GiveWP versions up through 4.16.7.1, specifically 4.16.6‑4.16.7.1, and is most exploitable on sites that still use legacy donation forms missing the formBuilderSettings field.

Patch and mitigation

GiveWP issued version 4.16.7.2 on August 27. The update blocks serialized data during donation processing, narrows the deserialization surface, and wipes any previously stored malicious payloads.

Patchstack confirmed the registration action still bypasses WordPress’s native registration setting, but the code path no longer leads to code execution.

Who’s at risk?

Any WordPress installation running GiveWP ≤ 4.16.7.1 is potentially vulnerable – from small NGOs to large fundraising platforms. Sites that disabled user registration assumed they were safe, but the bug proved otherwise.

Immediate defensive steps

1. Upgrade to GiveWP 4.16.7.2 or later immediately.
2. If you cannot patch right away, disable the give_action=user_register endpoint via a web‑application firewall rule or by adding remove_action('init','give_register_user'); to your theme’s functions.php.
3. Audit the wp_give_sessions table for unexpected serialized payloads and purge them.
4. Review WordPress user accounts for any that were created after the vulnerability’s disclosure date and remove suspicious ones.
5. Monitor server logs for calls to give_action=user_register and for execution of unusual system commands.