CVE-2026-57406

FundEngine – Donation and Crowdfunding Platform <= 1.7.6 - Missing Authorization

mediumMissing Authorization
5.3
CVSS Score
5.3
CVSS Score
medium
Severity
1.7.7
Patched in
7d
Time to patch

Description

The FundEngine – Donation and Crowdfunding Platform plugin for WordPress is vulnerable to unauthorized access due to a missing capability check on a function in versions up to, and including, 1.7.6. This makes it possible for unauthenticated attackers to perform an unauthorized action.

CVSS Vector Breakdown

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
None
Confidentiality
Low
Integrity
None
Availability

Technical Details

Affected versions<=1.7.6
PublishedJuly 8, 2026
Last updatedJuly 14, 2026

What Changed in the Fix

Changes introduced in v1.7.7

Loading patch diff...

Source Code

WordPress.org SVN
Research Plan
Unverified

# Exploitation Research Plan - CVE-2026-57406 ## 1. Vulnerability Summary The **FundEngine – Donation and Crowdfunding Platform** plugin (versions <= 1.7.6) contains a **Missing Authorization** vulnerability. The flaw exists in the `WfpFundraising\Apps\Content` class, specifically within the `wfp_d…

Show full research plan

Exploitation Research Plan - CVE-2026-57406

1. Vulnerability Summary

The FundEngine – Donation and Crowdfunding Platform plugin (versions <= 1.7.6) contains a Missing Authorization vulnerability. The flaw exists in the WfpFundraising\Apps\Content class, specifically within the wfp_donate_return_message function (and potentially wfp_init_rest) hooked to init.

The plugin fails to perform a capability check or verify the authenticity of requests (e.g., via a secure token or gateway signature) when processing donation return messages or custom "REST" actions. This allows unauthenticated attackers to perform unauthorized actions, such as marking a donation as "completed" without actual payment or modifying donation metadata.

2. Attack Vector Analysis

  • Endpoint: Frontend site root (/) or admin-ajax.php.
  • Hook: init (via wfp_donate_return_message) or wp_ajax_nopriv_*.
  • Authentication: None (Unauthenticated).
  • Parameters:
    • wfp-action: The action trigger (e.g., wfp_paypal_success, return, or wfp_init_rest handlers).
    • donation_id / id: The ID of the wfp_donation post to modify.
    • status: The target status (e.g., completed, success).
  • Preconditions: A valid wfp_donation post must exist (usually created by initiating a donation).

3. Code Flow

  1. Entry Point: apps/content.php registers the hook:
    add_action( 'init', array( $this, 'wfp_donate_return_message' ) ); // Line 65
    
  2. Execution: Every request to the WordPress site triggers init. The wfp_donate_return_message function checks for specific $_GET or $_POST parameters.
  3. Sink: The function identifies a donation_id from the request and uses update_post_meta() or wp_update_post() to change the status of the wfp_donation post type.
  4. Missing Check: The function lacks current_user_can() or a verification of a unique transaction hash/nonce from the payment provider (PayPal/Stripe), trusting the user-provided ID.

4. Nonce Acquisition Strategy

This vulnerability typically involves the payment return logic, which often bypasses standard WordPress nonces to accommodate external callbacks. However, if the vulnerability is inside an AJAX handler:

  1. Shortcode Page: The plugin enqueues scripts on pages containing the [wfp-forms] or [wfp_fundraising_form] shortcodes.
  2. Variable Identification: Look for wp_localize_script in apps/content.php (inside wfp_donation_css_loader_public).
  3. Extraction:
    • Create a page: wp post create --post_type=page --post_status=publish --post_content='[wfp-forms]'
    • Navigate to the page.
    • Use browser_eval to extract: window.wfp_fundraising_params?.nonce or window.wfp_fundraising_data?.nonce.
  4. Bypass: If the logic is in wfp_donate_return_message (the init hook), it likely does not require a nonce, as it is designed for payment gateway redirects.

5. Exploitation Strategy

Step 1: Identify a Target Donation

An attacker needs a valid donation_id. This can be obtained by starting a donation as a guest or by enumerating IDs if the wfp_donation post type is publicly_queryable.

Step 2: Trigger Unauthorized Status Update

Send a GET request to the site root simulating a successful payment return.

Request:

  • URL: http://localhost:8080/
  • Method: GET
  • Parameters:
    • wfp-action: wfp_paypal_success (inferred from typical FundEngine return logic)
    • donation_id: [TARGET_ID]
    • status: completed

Tool Call (example):

http_request({
    method: "GET",
    url: "http://localhost:8080/?wfp-action=wfp_paypal_success&donation_id=123&status=completed"
})

6. Test Data Setup

  1. Create Campaign:
    wp post create --post_type=wp-fundraising --post_title="Save the Whales" --post_status=publish
    
  2. Create Pending Donation:
    Use the wfp_donation post type defined in apps/donation-cpt.php:
    wp post create --post_type=wfp_donation --post_title="Guest Donation" --post_status=publish --post_author=0
    # Note the returned ID (e.g., 123)
    wp post primary-setup 123 --meta_input='{"_wfp_donation_status":"pending"}'
    
  3. Place Shortcode:
    wp post create --post_type=page --post_title="Donate Now" --post_content='[wfp-forms]' --post_status=publish
    

7. Expected Results

  • The server responds with a 200 OK or a redirect to the success page (defined by wfp-success shortcode).
  • The wfp_donation post meta or status is updated without the attacker having performed a transaction.

8. Verification Steps

Verify the donation status via WP-CLI:

# Check the post meta for the donation status
wp post meta get [ID] _wfp_donation_status

# Or check the overall post status if used
wp post get [ID] --field=post_status

Successful exploitation is confirmed if the status changed from pending to completed or success.

9. Alternative Approaches

If the init hook requires a more complex payload, investigate apps/content.php for the wfp_init_rest function:

  1. Action Identification: Search for $_REQUEST['wfp-action'] or $_GET['action'] inside the body of wfp_init_rest.
  2. Parameter Fuzzing: If wfp_init_rest handles a delete action, attempt:
    /?wfp-action=wfp_delete_donation&id=[ID]
  3. AJAX Testing: Check if wp_ajax_nopriv_featured_video_get_data in apps/featured.php allows for unauthorized meta retrieval or updates by providing a different post_id than intended.

Check if your site is affected.

Run a free security audit to detect vulnerable plugins, outdated versions, and misconfigurations.