The exposed registration action removes the account requirement that was meant to cap this bug. Patchstack's chain stacks three defects: an unsafe helper for unserializing PHP data, a donation-processing flow that stores attacker-controlled serialized objects, and a gadget chain inside libraries the plugin bundles that can invoke arbitrary system commands [5]. The chain needs an account on the target site [6], and that is the precondition the exposed registration action removes.
The request sequence is short. Create the account and collect the authentication cookie, write the serialized gadget into a profile field, then submit a crafted donation. George Johnstone of Patchstack says the server writes the gadget object into wp_give_sessions before returning an HTTP 500 [9]. Fetch any front-end page with the same cookie and the server unserializes the gadget and executes the command [10]. The 500 is therefore a log artifact worth grepping for, as is a new user account on a site whose registration is switched off.
Version triage is messier than "through 4.16.7.1" implies [2]. Patchstack names upgraded installations, sites using the plugin's option-based form editor, and older forms brought back by import or restore as the places that legacy-form condition turns up [12]. Earlier releases narrowed the exploitable population rather than closing the path; 4.16.7.2 blocks serialized data during donation processing and restricts object creation at several deserialization points [13].
Udin Chan reported the chain on July 28 through Patchstack [3]; the fix shipped on August 27 [13]. That is 30 days, assuming both dates fall in the same year, which the source does not state [17]. Nothing in the reporting describes exploitation in the wild [18].
What survives the patch is the registration action itself. Patchstack says it still does not honor the WordPress user registration setting, and says that is no longer exploitable for code execution [15]. The consequence carries forward: the next authenticated-only vulnerability found anywhere in GiveWP starts, from the attacker's side, already authenticated [19]. GiveWP's own registration path keeps handing that head start to whatever bug turns up next in the same codebase.
