What makes this chain interesting is the gap between planting the payload and firing it. After the account exists, the attacker stores a serialized PHP gadget in the `last_name` profile field as an ordinary string [5]. GiveWP's donation processing then converts that value into an incomplete object and writes it back into the `wp_give_sessions` table [6]. An incomplete object is what PHP produces when it deserializes data whose class is not loaded yet: a typed placeholder that sits inert. At that point the payload is indistinguishable from normal session data in the database.
On the next request GiveWP reads that session and reconstructs the object with its class available, and that is when the gadget chain runs [7]. It terminates at `call_user_func_array()`, reached through a TCPDF gadget chain, which is the point where anonymous input becomes an OS command executing as the web server process [8][9][10].
Storing the gadget and detonating it on a later read is what makes this awkward to catch at the boundary. The request that plants the payload reads as a routine profile update. The request that triggers it carries nothing suspicious, because the dangerous data is already inside the session store the application trusts.
Detection therefore leans on the seams of that flow. Watch for sequential requests to `give_action=user_register`, then profile updates, then the donation and session APIs [15]. Watch for serialized strings landing in a `last_name` field, and for web server processes such as `php-fpm`, `apache2`, or `httpd` spawning shells or network tools [15]. Each of those signals is unremarkable on its own and telling in sequence. None of them requires the operator to have left registration switched on to notice.
