Critical GiveWP Flaw Lets Attackers Run Commands on WordPress Servers

A critical GiveWP flaw lets unauthenticated attackers execute server commands. Version 4.16.7.2 fixes the PHP object injection chain.

A critical vulnerability in GiveWP, one of the most widely used WordPress plugins for online donations and fundraising, can let an unauthenticated attacker execute commands on the server. Patchstack disclosed the flaw on August 28, after researcher Udin Chan reported it on July 28, and GiveWP fixed it in version 4.16.7.2 released on August 27.

The issue, tracked as CVE-2026-82222 (CVSS score of 10.0), affects GiveWP versions through 4.16.7.1. An attacker doesn’t need an account or user interaction to exploit the underlying vulnerability.

“In versions 4.16.7.1 and below, GiveWP contains an unauthenticated PHP Object Injection vulnerability that can be chained into full remote code execution. On 4.16.5.1 and below a default installation is enough to exploit: it ships with an active manual (Test Donation) gateway and an active offline gateway, and only needs one published donation form.” reads the report published by PatchStack. “No Test Mode, open registration, debug mode, or administrator action is required.”

That description sounds severe because it is. The problem isn’t one isolated coding mistake. Patchstack found a chain involving unsafe handling of serialized PHP objects, a donation workflow that can carry attacker-controlled data into storage, and classes already included in GiveWP that can turn the injected object into command execution.

GiveWP is designed for nonprofits and other organizations that collect donations through WordPress. The plugin handles donation forms, payment gateways, donor information and reporting, so a server running it can hold data that attackers would have plenty of reasons to target.

The root cause of the problem is a helper that GiveWP created to make PHP’s unserialize() safer. It uses PHP’s allowed_classes => false option, which looks like a sensible defense at first glance.

There’s a catch. PHP doesn’t simply throw the serialized object away. Instead, it converts the object into an __PHP_Incomplete_Class placeholder while keeping the original class name and properties.

When GiveWP later serializes that placeholder again, those original object details go back into the serialized data. The application has effectively carried the attacker’s payload forward instead of removing it.

That distinction matters because the malicious object eventually reaches another part of GiveWP that reads the stored data without the same restriction. At that point, PHP can recreate the original object and the rest of the attack chain can continue.

The donation process gives the attacker a way to move that malicious data into GiveWP’s session storage. Patchstack found that the application reads donor information from the user’s account and sends the fields through the supposedly safe unserialization helper.

The attacker-controlled data can therefore survive the first check and reach the wp_give_sessions table. A later request reads the session and processes the serialized object again, this time without the protection that was supposed to stop it.

This is a classic example of why serialization bugs can be difficult to contain. Checking data at one point doesn’t help much if the application later stores that data and processes it differently somewhere else.

The object injection alone doesn’t automatically mean arbitrary command execution. An attacker also needs a gadget chain, meaning existing application code that can be manipulated to turn the injected object into a dangerous operation.

Patchstack found that GiveWP ships code that provides exactly that missing piece. The chain involves the TCPDF library and GiveWP’s own Give\TestData classes, eventually reaching a function call controlled by properties inside the injected object.

“Because loadedProviders is just an array property carried inside the injected object, the attacker sets it to any callable they like.” continues the report. “Pointing it at system() executes an arbitrary OS command as the web server user.”

That means the attacker can turn control of the object into control of what function the application calls. In the vulnerable code, that can lead to execution of an operating system command with the privileges of the web server.

At that point, this stops being a data-handling problem and becomes a server compromise problem. If the WordPress process has access to sensitive files, databases or other internal resources, the impact can extend well beyond the GiveWP plugin itself.

GiveWP’s registration feature ignores WordPress’s users_can_register setting, allowing attackers to create accounts even when registration is disabled. Version 4.16.6 added a nonce check, but attackers can still obtain and reuse the nonce on sites with the public registration shortcode.

Patchstack says versions 4.16.5.1 and earlier are directly exploitable on default installations. Versions 4.16.6–4.16.7.1 reduce the attack surface but leave the underlying flaw exploitable through legacy forms. Version 4.16.7.2 fully fixes the issue.

GiveWP 4.16.7.2 takes a broader approach to fixing the RCE. It blocks serialized data before storage, limits where stored data can be deserialized, hardens the vulnerable gadget and sanitizes donor and billing metadata. It also scans existing database records and removes serialized objects that could contain malicious payloads.

This cleanup matters because updating the code alone cannot remove data already stored by an attacker. Patchstack also found that the earlier 4.16.6 fix could preserve malicious serialized data after detecting __PHP_Incomplete_Class; 4.16.7.2 rejects it instead.

Administrators should update to 4.16.7.2 or later, review logs and signs of compromise, and check older or imported donation forms. The separate registration issue remains unresolved, but Patchstack treats it as an access-control problem rather than part of the patched RCE chain.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, GiveWP)