GiveWP donation plugin flaw allows unauthenticated remote code execution on WordPress sites

Critical flaw in GiveWP

GiveWP, a WordPress plugin that nonprofits use to collect donations, contains a critical vulnerability that allows attackers with no credentials at all to execute operating system commands on an affected site. BleepingComputer reported the flaw on August 28, 2026, drawing on a technical analysis by Patchstack. It is tracked as CVE-2026-82222 and affects every version of the plugin up to and including 4.16.7.1. Version 4.16.7.2 fixes the issue and, importantly, also migrates any malicious serialized data that may already be sitting on a compromised site.

How the attack chain works

The chain starts with GiveWP's own account handling. A request to the give_action=user_register endpoint creates an account and issues a session cookie even when WordPress's users_can_register setting is switched off, meaning sites that deliberately blocked open registration are still exposed. According to the Patchstack analysis relayed in a dev.to write-up, the attacker then stores a PHP serialization gadget in the last_name field of their freshly created profile.

When a donation is processed, GiveWP converts stored values into an incomplete object and writes the result back into the wp_give_sessions table. Even though the code path uses allowed_classes=false, a setting intended to defuse untrusted serialized data, the crafted properties survive the conversion. On the next request, the session data is reconstructed as the original class, which revives the gadget. From there, gadget chains built on the TCPDF PDF library and a GiveWP class named ProviderForwarder reach call_user_func_array() and ultimately invoke system(), giving the attacker arbitrary command execution with the privileges of the web server process.

What exploitation looks like

The attack requires no interaction from the site owner or visitors; the whole sequence can be carried out through API requests alone. For it to succeed, the site must run GiveWP 4.16.7.1 or earlier, the custom registration and profile update features must be reachable, and a usable donation form or payment gateway must be exposed, including legacy ones.

Administrators hunting for signs of this activity should look for a specific pattern: sequential requests to give_action=user_register, followed by profile updates and calls to the donation and session APIs. Other red flags include accounts that exist despite open registration being disabled, serialized PHP strings stored in user last_name fields, and web server processes such as php-fpm, apache2 or httpd spawning shells or network tools. Outbound traffic to unknown destinations after such activity is another indicator worth checking in WAF, load balancer and audit logs.

Patching and cleanup

The primary fix is an update to GiveWP 4.16.7.2 or later, followed by completion of the migration process, which also scrubs malicious serialized data left behind on the site. Beyond upgrading, the write-up recommends removing suspicious accounts and sessions, deleting legacy forms that are no longer needed, and blocking PHP serialization patterns and OS command execution from web processes at the host level. Sites that find concrete evidence of compromise should isolate the affected machine and revoke related credentials and sessions.

Whether attackers have actually exploited this vulnerability in the wild cannot be confirmed from the public information available so far; the dev.to summary states this explicitly.

Why it matters

A successful exploit hands the attacker the full privileges of the web server process, which on typical shared or managed WordPress hosting means access to WordPress configuration, donor records and database credentials. From that foothold, an attacker can install web shells, deface the site, or pivot to other sites hosted on the same server. The vulnerability is also a useful case study in why unserializing data with allowed_classes=false is not a safe boundary on its own: GiveWP reconstructed the original object anyway, turning a hardened-looking code path into a working exploitation chain. Because the entry point is an unauthenticated registration flow rather than a privileged feature, every exposed site running an outdated copy of the plugin is a viable target, and the long tail of unpatched WordPress installs means this will likely remain a live risk long after the patch shipped.