In August 2024, one of the most widely used donation plugins in the WordPress ecosystem was found to contain a flaw carrying the highest possible severity rating. GiveWP – the donation and fundraising platform installed on more than 100,000 websites – was vulnerable to an attack that let complete strangers run their own code on the server and delete files at will. Tracked as CVE-2024-5932 and scored a perfect 10.0 on the CVSS scale, the vulnerability required no login, no account, and no special access. For the nonprofits, charities, churches, and community groups that rely on GiveWP to collect real money, few problems could be more serious. This post explains what went wrong, what an attacker could do with it, and exactly how to make sure your site is safe.
CVE-2024-5932 at a glance
- CVE ID: CVE-2024-5932
- Affected software: GiveWP – Donation Plugin and Fundraising Platform (plugin slug: give)
- Vulnerability type: Unauthenticated PHP Object Injection leading to Remote Code Execution (RCE) and arbitrary file deletion
- CVSS score: 10.0 (Critical) – vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
- Affected versions: All versions up to and including 3.14.1
- Patched version: 3.14.2, released August 7, 2024
- Active installations: 100,000+
- Discovery: reported by the researcher villu164 through the Wordfence Bug Bounty Program
How the vulnerability works
To understand this flaw, it helps to know a little about how PHP stores data. PHP can turn a complex value – including a whole object with its internal properties – into a compact text string through a process called serialization. The reverse process, unserialization, rebuilds the object from that string. This is convenient and common, but it becomes dangerous when a plugin unserializes data that came from an untrusted source, such as a web form. An attacker who controls that string can craft it so that unserializing it creates an object of the attacker’s choosing. This technique is known as PHP Object Injection.
GiveWP’s developers were aware of this risk. When a donation form is submitted, the plugin inspects the incoming fields and rejects any that appear to contain serialized data, returning the message “Serialized fields detected. Go away!” The problem was that one field slipped through this net: the give_title parameter, the donor’s honorific or title, was never included in that check. An attacker could therefore place a malicious serialized payload in give_title and it would pass validation untouched.
From there, the value took a winding path. GiveWP saved the submitted title into the database as donor metadata under the key _give_donor_title_prefix, storing it in serialized form. Later, during ordinary payment processing, the plugin read that metadata back and unserialized it – turning the attacker’s crafted string into a live PHP object. On its own, an injected object is harmless. What made this critical is that GiveWP (and libraries it bundles) contained classes with so-called “magic methods” that fire automatically when an object is used or destroyed. By chaining several of these together – a technique called a POP chain – the researcher was able to reach PHP’s call_user_func and ultimately shell_exec, allowing arbitrary operating-system commands to run and a web shell to be uploaded. A second chain abused the destructor of the bundled TCPDF library to call unlink and delete any file on the server, such as wp-config.php.
The crucial takeaway is that none of this required an account. Submitting a specially crafted donation form – something any visitor can do – was enough to trigger the entire chain.
Real-world impact
Remote code execution is the most severe outcome a web vulnerability can produce, because it hands the attacker the same power over the server that the site’s own code has. On an unpatched GiveWP site, an attacker could install a persistent backdoor or web shell, giving them ongoing control long after the initial break-in. From that foothold they could steal donor records and payment details, siphon or redirect donations, deface the site, plant spam or malware to infect visitors, and pivot deeper into the hosting environment. The arbitrary file deletion path is equally damaging: removing wp-config.php resets WordPress to its setup state, which a clever attacker can use to reconnect the site to a database they control and seize the administrator account. For a charity or nonprofit, the fallout is not just a defaced page – it can mean exposed supporter data, diverted funds, and a serious breach of donor trust.
How to check if you are affected
You are exposed if your site runs GiveWP version 3.14.1 or earlier. To confirm which version you have:
- Log in to your WordPress dashboard and go to Plugins > Installed Plugins. Find “GiveWP – Donation Plugin and Fundraising Platform” and read the version number shown beneath it.
- Alternatively, go to Donations > Settings, where the version is often displayed, or check the plugin’s readme file at
/wp-content/plugins/give/readme.txt. - If you manage the server directly, you can also confirm the installed version through your host’s file manager or over SFTP.
If the version is 3.14.2 or higher, you already have the fix. If it is anything lower, treat the site as vulnerable and act immediately. Because this flaw was exploitable without authentication, do not assume you were spared simply because you never noticed anything unusual – successful exploitation is often silent.
How to fix it
The single most important step is to update GiveWP to version 3.14.2 or later, which fully closes the vulnerability by adding the missing validation. In your dashboard, go to Plugins > Installed Plugins, and if an update is available for GiveWP, click Update Now. Confirm afterward that the version reads 3.14.2 or higher.
Beyond updating, take these additional hardening steps, especially if your site was running a vulnerable version for any length of time:
- Enable automatic updates for GiveWP and other critical plugins so future security releases are applied without delay.
- Scan for compromise. Run a reputable malware scanner and look for unfamiliar files in
/wp-content/, unexpected admin accounts, or modified core files – signs a web shell may have been planted. - Deploy a web application firewall (WAF). A firewall with PHP Object Injection protection can block exploit attempts even before a patch is installed, buying valuable time.
- Rotate secrets if you suspect a breach. Change database credentials, WordPress salts in
wp-config.php, and administrator passwords, and review connected payment gateway keys. - Keep verified backups so you can restore cleanly if the worst happens.
Takeaway
CVE-2024-5932 is a textbook reminder that a single overlooked input – here, one form field left out of a security check – can undermine an otherwise careful plugin and expose 100,000 sites at once. The good news is that the defenses are the same ones that protect against nearly every plugin vulnerability: update promptly, run a firewall and malware scanner, limit what untrusted visitors can reach, and keep clean backups. Donation and e-commerce plugins deserve extra attention because they handle money and personal data, making them attractive targets. Patch GiveWP today, make timely updates a habit, and your site will be resilient not just to this flaw but to the next one as well.