CVE-2026-82222 is a maximum-severity flaw in GiveWP, a WordPress donation plugin with more than 100,000 installations. It gives an unauthenticated attacker arbitrary command execution on the hosting server.

Versions up to 4.16.7.1 are affected. 4.16.7.2, released 27 August 2026, fixes it. It was reported on 28 July by Udin Chan through Patchstack.

Three weaknesses, one outcome

None of the three would do much alone:

  1. An unsafe helper that unserialises PHP data — the classic sink.
  2. A donation-processing flow that stores attacker-controlled serialised objects — the source, reachable by anyone making a donation.
  3. A gadget chain in libraries bundled with the plugin that can invoke arbitrary system commands — the thing that turns deserialisation into execution.

That is the standard PHP object injection shape, and it is the second unserialise story this week. The Kaltura mwEmbed flaws were also an unvalidated unserialise, in a call that had sat byte-identical since 2015.

PHP's unserialize on untrusted input has been known-dangerous for well over a decade. It persists because the sink is convenient, the source is often several files away, and the gadget chain usually lives in a dependency nobody on the project chose.

The detail that makes it unauthenticated

Exploitation normally requires an account. GiveWP supplies one.

An unauthenticated registration action — give_action=user_register — creates accounts even on sites where registration is disabled.

So an administrator who turned off user registration, reasonably believing that closed the door, still has it open. The setting in the WordPress admin and the behaviour of the plugin are two different things, and only one of them is enforced.

This is the same failure as the Gitea flaw this week, where an "authenticated" bug is reachable by anyone because registration is open by default. There, the door was open by design. Here it is open despite being shut.

Who actually runs this

GiveWP is a donation plugin. Its install base is charities, religious organisations, community groups, mutual aid funds, small nonprofits.

That population has the least capacity to respond of anyone in the WordPress ecosystem: no security staff, often no maintenance contract, frequently a volunteer who built the site years ago and moved on. And the plugin sits directly in the payment flow, which is where the useful data is.

It is worth being blunt that the standard advice — patch promptly, monitor, have a response plan — assumes an organisation that does not exist here.

What to do

  • Update to 4.16.7.2 immediately. It is the whole fix.
  • Check your user list for accounts you did not expect, particularly recent ones, and particularly if you believe registration is disabled.
  • Look for unexpected files in the WordPress directory and for scheduled tasks you did not create.
  • If you run a site for an organisation that cannot maintain it, turn on automatic plugin updates. The risk of an update breaking something is smaller than this.
  • Rotate database credentials and any payment API keys if you find evidence of access.

What is not established

  • The CVSS numeric score. Not published.
  • Whether it is being exploited. No in-the-wild activity reported.
  • How many of the 100,000-plus installations have updated.
  • Which bundled library supplies the gadget chain.
  • Whether the affected condition applies to every configuration, or only some.