ANALYSIS · 5857a242· FINISHED 2026-09-05 · PATCHDIFF

givecache/give_4.13.1 → cache/give_4.13.2✓ COMPLETED

Files9

Vulnerable7

True positives5

CVE matched2

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2025-66533

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 9 CVE 2 Vuln 7

SORT

2 files · page 1/1

includes/donors/class-give-donor-wall.php

AI: 1 vulnerabilities

CVE-2025-66533 1 TP

#%!d(float64=002)

src/Campaigns/Blocks/CampaignDonations/resources/views/render.php

AI: 1 vulnerabilities

CVE-2025-66533 1 TP

#%!d(float64=004)

1–2 of 2

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2025-66533

Security writeup for CVE-2025-66533

✓ 2 FILES

## The Exploit

An unauthenticated attacker can inject WordPress shortcodes into donor names stored in the GiveWP database, which are then executed server-side when the donor wall or campaign donations block is rendered to any site visitor.

**Store the payload** by submitting a donation with a malicious donor name:

```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.wordpress.local
Content-Type: application/x-www-form-urlencoded

action=give_process_donation&donorName=[do_shortcode_injection_here]&donation_amount=10&email=attacker@example.com
```

**Trigger execution** by visiting any page that displays the donor wall or campaign donations block:

```bash
curl http://target.wordpress.local/campaigns/fundraiser-page/
```

The response body will contain the executed shortcode output embedded in the `` tag where the donor name should appear. If the attacker uses a shortcode like `[site_url]` or a custom plugin shortcode, the result renders in the page markup visible to all visitors. More critically, if a malicious shortcode exists on the site (injected via another plugin or custom code), the attacker can trigger arbitrary PHP execution.

## What the Patch Did

**Before**

```php
$html = ob_get_clean();

// Return only donor html.
if (
```

```php
'' . esc_html(!$donation->isAnonymous ? $donation->donorName : __('Anonymous', 'give')) . '',
```

**After**

```php
$html = ob_get_clean();

// Strip shortcodes to prevent execution of user-supplied shortcode syntax.
$html = strip_shortcodes($html);

// Return only donor html.
if (
```

```php
'' . esc_html(!$donation->isAnonymous ? strip_shortcodes($donation->donorName) : __('Anonymous', 'give')) . '',
```

The patch adds two calls to WordPress's `strip_shortcodes()` function. In the donor wall output handler (`class-give-donor-wall.php` line 151), `strip_shortcodes()` is applied to the entire buffer before return. In the campaign donations block template (`render.php` line 93), it is applied directly to `$donation->donorName` prior to HTML escaping. The `strip_shortcodes()` function removes all shortcode syntax (anything matching `[shortcode_name ... ]` pattern) from a string without rendering it, preventing the WordPress do_shortcode pipeline from ever encountering the attacker's input.

## Root Cause

**CWE-94: Improper Control of Generation of Code ('Code Injection')** — specifically, unsafe shortcode execution.

The donor name field accepts user input at the point of donation submission. This value is stored unfiltered in the database. When the donor wall or campaign donations block renders, the plugin calls WordPress rendering functions that eventually invoke `do_shortcode()` on output containing the donor name. WordPress's `do_shortcode()` function parses and executes all shortcode tags in its input. Because the plugin never called `strip_shortcodes()` before passing donor data to rendering contexts, any shortcode syntax in the donor name (e.g., `[wp_mail_smtp_get_current_user]` or custom plugin shortcodes) was executed in the rendering phase, crossing the trust boundary from user-supplied stored data into executable code.

## Why It Works

The single load-bearing line is `strip_shortcodes($html)` in the donor wall buffer handler and `strip_shortcodes($donation->donorName)` in the campaign block. If either were removed, the bug remains fully exploitable — an attacker's shortcode injection still reaches the output and is still parsed by `do_shortcode()`. The subsequent `esc_html()` call does *not* prevent shortcode execution; it only HTML-encodes the *characters* after shortcodes are already processed. A shortcode like `[my_malicious_function]` would be stripped to an empty string before `esc_html()` ever sees it. Without `strip_shortcodes()`, `esc_html('[my_malicious_function]')` outputs the literal string `&lsqb;my_malicious_function&rsqb;`, which looks safe in HTML but still triggers shortcode parsing earlier in the rendering pipeline. This is why the engineer added `strip_shortcodes()` at *both* locations: belt and suspenders defense ensures that no code path bypasses the removal, whether the output goes through the donor wall template or the campaign block template.

## Hardening Checklist

- **Audit all user-input sinks for `do_shortcode()` calls**: Use `wp-cli plugin search-replace` or grep to find every call to `do_shortcode()`, `apply_filters()` with shortcode-aware callbacks, and template rendering functions. For each, trace back to confirm the input has been explicitly stripped via `strip_shortcodes()` or restricted to safe sources (e.g., post content created by admins only).

- **Apply `strip_shortcodes()` to all user-supplied fields before rendering**: Treat donor names, testimonials, custom form fields, and any user-editable text as untrusted. Call `strip_shortcodes()` immediately before output escaping (`esc_html()`, `esc_attr()`), not as an afterthought in a central template.

- **Implement capability checks on donation form submission**: Require `current_user_can('manage_options')` or a custom capability for users who can edit their own donor name post-submission, and sanitize those edits with `sanitize_text_field()` followed by `strip_shortcodes()`.

- **Test shortcode injection in your test suite**: Add a unit test that submits a donation with donor name `[do_shortcode]` or `[site_url]` and asserts that the rendered output does not contain the shortcode's result or any executable syntax.

- **Use `wp_kses_post()` for rich text fields only**: If donor names or testimonials genuinely need to support limited HTML, use `wp_kses_post()` which has a whitelist of safe tags — but still call `strip_shortcodes()` first to be explicit about rejecting code injection vectors.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-66533

CVE CVE-2025-66533

PRODUCT give

AFFECTED ≤ cache/give_4.13.1

FIXED IN cache/give_4.13.2

STATUS Generated

Security writeup · CVE-2025-66533

Source files · 2

includes/donors/class-give-donor-wall.php Linked

src/Campaigns/Blocks/CampaignDonations/resources/views/render.php Linked

↗ NVD