CVE-2026-19658 — Unauthenticated PHP Object Injection in Give Tributes for WordPress

Executive Summary

CVSS Score: 9.8 (Critical)

Give Tributes, a donation add-on for the GiveWP fundraising plugin published by LiquidWeb for WordPress, contains a PHP Object Injection vulnerability tracked as CVE-2026-19658. All versions up to and including 2.3.1 fail to sanitize part of the donation form's eCard recipient data before it is written to donation metadata, allowing an unauthenticated site visitor to submit a PHP serialized object where a plain name field is expected.

The critical detail — and the one that should drive triage decisions — is spelled out directly in the vulnerability's own description: no known POP (Property-Oriented Programming) gadget chain currently exists inside Give Tributes itself. PHP Object Injection is only dangerous when the injected object's magic methods (__wakeup, __destruct, __toString, and similar) can be chained into something harmful, and Give Tributes does not ship such a chain on its own. That means, in a site running Give Tributes alone, successful exploitation of this specific flaw currently has no demonstrated impact.

The risk is not standalone, however — it is compositional. If a site also runs any other plugin or theme (regardless of publisher) that happens to contain a usable POP gadget chain, the same injected object can trigger that chain once PHP deserializes it, with consequences ranging from arbitrary file deletion to remote code execution depending on what gadget is present. Because plugin/theme inventories vary per site and can change at any time (a new plugin install introduces a gadget chain that didn't exist yesterday), and because the vulnerable code path requires no authentication, this advisory treats CVE-2026-19658 as critical per its published CVSS 9.8 score — reflecting worst-case, chainable risk — while being explicit that real-world impact on any given site depends entirely on what else is installed alongside Give Tributes.

Vulnerability Overview

The CVSS vector, CWE classification, and assigner above come from third-party vulnerability aggregators (VulDB and Wordfence Intelligence listings) rather than the bare NVD summary, and should be treated as reported-but-not-independently-reverified by CosmicBytez Labs against the plugin's own source.

Affected Versions

Because the fixed-version number above is sourced from a third-party researcher's PoC repository rather than the vendor's own release notes, administrators should confirm the currently installed and latest-available plugin version directly from the WordPress.org plugin listing or their site's plugin dashboard rather than relying solely on the version number quoted here.

Attack Vector

Public technical write-ups describe a narrow but unauthenticated trigger path. These details come from third-party analysis of the plugin's code and have not been independently verified line-by-line by CosmicBytez Labs, but are included because they materially affect how exploitable a given site is:

1. Prerequisite site configuration:
   - The donation form uses the legacy Give form shortcode (v2),
     not the newer Visual Form Builder (v3).
   - "Allow Multiple Recipients" is enabled for eCards, either
     globally or on the specific donation form.
   - eCard "Custom Message" is disabled — this is the plugin's
     default state. (When enabled, GiveWP's give_clean() routine
     blanks serialized-looking input during required-field
     validation, which prevents the payload from being stored.)
   - The form has a working payment method available to complete
     a donation (a manual/offline gateway is sufficient).

2. GiveWP's normal field validation runs submitted values through
   a sanitized copy of the request data (give_clean()), which
   strips or blanks strings that look like PHP serialized data.

3. Give Tributes' own storage routine for eCard recipients
   (insert_tribute_data()) reads the SECOND and later recipients'
   first_name / last_name fields directly from the raw, unsanitized
   request data instead of the sanitized copy.

4. An unauthenticated attacker submits a donation where a second
   recipient's name field contains a PHP serialized object string
   (the classic O:<length>:"ClassName":... prefix) instead of a
   plain name.

5. The unsanitized value is written into donation post meta as-is.

6. When that meta value is later read back and passed through
   PHP's unserialize() — for example when rendering tribute data,
   generating an eCard, or displaying donation details — the
   attacker-supplied object is instantiated.

7. Give Tributes contains no POP gadget chain of its own, so step 6
   alone has no demonstrated impact. If ANY other plugin or theme
   on the same site provides a compatible gadget chain, deserializing
   the attacker's object can invoke it.

No authentication, prior access, or social engineering is required — only the ability to submit a public donation form with multi-recipient eCards enabled.

Impact of Successful Exploitation

Immediate Remediation

1. Update Give Tributes to the latest available version. Confirm the currently installed version and the latest release directly via the WordPress admin Plugins screen or the WordPress.org plugin page — do not rely solely on a specific version number from third-party trackers.
2. If an immediate update is not possible, disable "Allow Multiple Recipients" on all donation forms using Give Tributes. Per the reported trigger conditions, the single-recipient code path applies sanitize_textarea_field(), which neutralizes the payload and closes this specific route.
3. Enable the eCard "Custom Message" option as an additional mitigating control, since GiveWP's required-field validation for that field blanks serialized-looking input before storage — though this should not be relied upon as a substitute for patching.
4. Inventory every other plugin and theme on the same WordPress installation. Since Give Tributes has no POP chain of its own, your actual exposure is determined by what else is installed. Treat any site with a large or infrequently-audited plugin/theme footprint as higher risk.
5. If the plugin is not in active use, deactivate or remove it until a confirmed patched version is verified and installed.

Detection Indicators

Post-Remediation Steps

1. Confirm the installed Give Tributes version is above 2.3.1 and matches the vendor's current released version after updating.
2. Re-enable "Allow Multiple Recipients" only after the update is confirmed, if it was disabled as an interim mitigation.
3. Audit all other installed plugins and themes for known PHP Object Injection or insecure-deserialization advisories, since any one of them supplying a POP gadget chain is what would make this vulnerability exploitable in practice.
4. Review donation records created while the site ran a vulnerable version for anomalous serialized-looking data in recipient name fields.
5. Rotate any credentials or secrets that could plausibly have been exposed if a gadget chain was present and exploited during the vulnerable window.
6. Keep Give Tributes, GiveWP core, and all other plugins/themes on a regular update cadence — this class of vulnerability becomes exploitable the moment a compatible gadget chain is introduced anywhere on the site, not only through Give Tributes' own updates.

References

• NVD — CVE-2026-19658
• Wordfence Intelligence — CVE-2026-19658
• VulDB — CVE-2026-19658
• GitHub — murrez/CVE-2026-19658 (third-party PoC/checker tooling)