The HTTP test creates a disposable donor user, metadata, and GiveWP session rows. Use the included reset command after testing.

Quick start

Requirements:

• Docker with Compose v2
• Python 3.10 or later
• curl
• unzip
• sha256sum or shasum
• Network access to downloads.wordpress.org for official plugin archives

Run the complete vulnerable/patched matrix:

The command:

1. Downloads GiveWP 4.16.5.1 and 4.16.7.2 from WordPress.org.
2. Verifies both SHA-256 hashes.
3. Builds a fresh loopback-only WordPress 6.6.2/PHP 8.1 lab with normal WordPress registration explicitly disabled.
4. Tests pristine 4.16.5.1 and requires marker creation by the web user.
5. Builds a second fresh lab with pristine 4.16.7.2.
6. Requires the HTTP marker to remain absent.
7. Bypasses ingress in a direct control and confirms the patched ProviderForwarder terminal also rejects the string callable.

The patched lab remains running at the end. Remove it with:

To use another loopback port:

Expected evidence

The vulnerable control must end with concrete terminal evidence:

The patched control must show:

An HTTP 500, stored payload, exception, or detector hit without the marker is not accepted as RCE proof.

Manual lab lifecycle

Start and test the vulnerable release:

Start and test the patched release:

Inspect current state:

Remove containers, volumes, test users, sessions, and marker state:

Cached plugin ZIPs and extracted assets are preserved for faster reruns. Remove those exact generated assets as well with:

Affected and tested versions

The public advisory identifies releases through 4.16.7.1 as affected. This repository directly proves only the two versions in its positive/negative test matrix.

References:

• Patchstack advisory
• CVE-2026-82222
• GiveWP hardening commit
• Official GiveWP plugin page

Root cause

The exploit combines several behaviors:

1. GiveWP 4.16.5.1 exposes a registration action that creates and authenticates a low-privilege donor even when normal WordPress registration is disabled.
2. That user can persist serialized data in their own name metadata.
3. Give\Helpers\Utils::maybeSafeUnserialize() uses allowed_classes => false, producing __PHP_Incomplete_Class, but a later serialization preserves the original class names and properties.
4. The graph is stored in a GiveWP purchase session.
5. A later unrestricted maybe_unserialize() revives the shipped classes.
6. Automatic destruction enters a complete POP chain to system().

Four literal namespace backslashes are required in the HTTP carrier. The two effective stripping passes reduce them 4 -> 2 -> 1. The payload is NUL-free, and PHP 8.1.30 was verified to hydrate the plain serialized name for the private Session::$attributeName property.

Complete POP chain

Attacker-controlled graph:

The critical hidden transition is PHP's implicit IteratorAggregate dispatch. TCPDF::$imagekeys is untyped, so assigning a Symfony Session causes foreach to invoke Session::getIterator().

The marker command executes before Symfony enforces the getAttributeBag(): AttributeBagInterface return type. The resulting TypeError and HTTP 500 are post-sink effects.

What earlier attempts missed

The rejected candidate graph used:

That graph cannot work. TCPDF::_destroy() only unsets objcopy; PHP does not route automatic destruction through __call('__destruct', ...).

The missing operation was:

The earlier review followed destructors and explicit method calls but did not recursively inspect the implicit object protocol triggered by foreach. Symfony Session supplies the missing bridge:

• foreach invokes getIterator().
• getIterator() reaches getBag($attributeName).
• Attacker-controlled storage is a DonationFactory.
• The undefined getBag invokes ProviderForwarder::__call().
• loadedProviders['getBag'] = 'system' selects the callable.
• attributeName supplies the command argument.

Source evidence

Relevant GiveWP 4.16.5.1 locations:

Official release hashes:

The lab re-extracts each plugin from its verified ZIP before every fresh start, copies it into WordPress without modification, and byte-compares the deployed complete plugin file tree with the verified source. The three official Docker base images are also pinned to their multi-architecture manifest digests.

Why 4.16.7.2 blocks the chain

GiveWP 4.16.7.2 adds independent defenses across registration, serialized input handling, session revival, data migration, and gadget hardening.

The terminal hardening requires the resolved object to implement the expected provider contract:

The attacker-controlled string system is therefore rejected. The direct control in this repository bypasses the HTTP carrier and verifies that this terminal defense alone leaves its marker absent.

Checking a real deployment

A negative PoC result by itself does not prove a site is patched. A WAF, different routing, disabled registration, missing legacy form, session configuration, or disabled PHP command functions can all prevent the marker on a still-vulnerable codebase.

Preferred validation procedure:

1. Record the deployed GiveWP version and source revision.
2. Back up or snapshot the WordPress site and database.
3. Restore that snapshot into an isolated staging environment.
4. Disable unnecessary outbound network access.
5. Run this marker-only verifier against the clone.
6. Update GiveWP to the latest supported release, with 4.16.7.2 as the minimum release containing the tested fixes.
7. Repeat the identical test and require marker absence.
8. Independently verify the installed plugin version and patched source.

Version check:

Remediation and incident review

Update GiveWP to the latest supported version. After updating:

• Clear PHP opcode caches where applicable.
• Confirm no older GiveWP copy remains active or web-accessible.
• Review unexpected WordPress or donor accounts.
• Search user metadata and GiveWP sessions for serialized TCPDF, Symfony Session, or loadedProviders graphs.
• Correlate registration, profile changes, donation requests, and subsequent HTTP 500 responses from the same session.
• Investigate unexpected web-server child processes or filesystem changes.

If an internet-exposed vulnerable installation contains object-injection artifacts, treat it as a potential compromise rather than only updating the plugin.

Repository layout

Not committed:

Validation boundaries

The proof standard is deliberately strict: only an observable command marker through the unmodified stock chain is labeled RCE. HTTP acceptance, serialization, exceptions, and detector hits are intermediate evidence.