CVE-2026-3177: WordPress Charitable Plugin Auth Bypass Flaw

CVE-2026-3177 Overview

The Charitable – Donation Plugin for WordPress is vulnerable to Insufficient Verification of Data Authenticity in versions up to and including 1.8.9.7. This vulnerability stems from missing cryptographic verification of incoming Stripe webhook events, allowing unauthenticated attackers to forge payment_intent.succeeded webhook payloads and mark pending donations as completed without actual payment processing.

Critical Impact

Attackers can bypass payment verification to falsely mark donations as completed, resulting in financial fraud and theft of goods or services from charitable organizations using this plugin.

Affected Products

• Charitable – Donation Plugin for WordPress versions up to and including 1.8.9.7
• WordPress sites using Charitable plugin with Stripe payment gateway integration
• Organizations processing donations through the vulnerable webhook endpoint

Discovery Timeline

• 2026-04-07 - CVE CVE-2026-3177 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-3177

Vulnerability Analysis

This vulnerability is classified under CWE-345 (Insufficient Verification of Data Authenticity). The core issue lies in the plugin's webhook handler failing to implement proper cryptographic signature verification for incoming Stripe webhook events.

Stripe provides a webhook signing mechanism where each webhook payload includes a Stripe-Signature header containing an HMAC signature computed using a shared webhook endpoint secret. The Charitable plugin's affected versions do not validate this signature before processing webhook events, creating a trust boundary violation.

When a payment_intent.succeeded event is received, the plugin should verify the signature against the configured webhook secret before updating the donation status. Without this verification, an attacker can craft arbitrary webhook payloads that the plugin will accept as legitimate Stripe communications.

Root Cause

The root cause is the absence of cryptographic signature verification in the Stripe webhook handler. The plugin processes incoming webhook data without calling Stripe's signature verification methods (such as Stripe\Webhook::constructEvent() with the webhook signing secret). This allows any HTTP request mimicking the Stripe webhook format to be accepted and processed, regardless of its origin.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can send crafted HTTP POST requests to the WordPress site's Charitable webhook endpoint. By constructing a valid-looking payment_intent.succeeded event payload with a target donation ID, the attacker can trigger the plugin to mark donations as completed.

The attacker would need to:

1. Identify the webhook endpoint URL (typically predictable WordPress REST API routes)
2. Obtain or guess valid donation IDs (potentially through enumeration)
3. Craft a forged webhook payload mimicking Stripe's payment_intent.succeeded event structure
4. Send the payload to the vulnerable endpoint

The attack does not require valid Stripe credentials or access to the victim's Stripe dashboard, making it exploitable by any remote attacker who can reach the WordPress installation.

Detection Methods for CVE-2026-3177

Indicators of Compromise

• Donations marked as completed without corresponding legitimate Stripe transactions in the Stripe Dashboard
• Webhook requests to the Charitable endpoint originating from IP addresses outside Stripe's documented webhook IP ranges
• Donations completed without matching payment records or with mismatched payment amounts
• Unusual volume of webhook requests to the donation plugin endpoint

Detection Strategies

• Cross-reference completed donations in WordPress with actual payment records in the Stripe Dashboard to identify discrepancies
• Monitor web server access logs for POST requests to the Charitable webhook endpoint from non-Stripe IP addresses
• Implement web application firewall (WAF) rules to flag webhook requests with missing or malformed Stripe-Signature headers
• Review donation records for entries marked complete that lack proper payment metadata or transaction IDs

Monitoring Recommendations

• Enable detailed logging for all Stripe webhook events processed by the Charitable plugin
• Set up alerts for donations completed without corresponding Stripe payment confirmation emails
• Monitor for sudden increases in donation completion rates that deviate from historical patterns
• Implement periodic reconciliation between WordPress donation records and Stripe transaction history

How to Mitigate CVE-2026-3177

Immediate Actions Required

• Update the Charitable plugin to a patched version beyond 1.8.9.7 immediately
• Audit recent donation records to identify any potentially fraudulent completed donations
• Verify all completed donations against actual Stripe Dashboard transaction records
• Consider temporarily disabling the Stripe payment gateway until the update is applied

Patch Information

The vulnerability has been addressed in a plugin update. The patch implements proper Stripe webhook signature verification using the webhook endpoint secret. For technical details on the fix, see the WordPress Plugin Update changelog.

Additional information is available in the Wordfence Vulnerability Report.

Workarounds

• Restrict access to the webhook endpoint at the web server level to only allow requests from Stripe's documented webhook IP ranges
• Implement a custom middleware or WAF rule that validates the presence and format of the Stripe-Signature header before requests reach WordPress
• Enable Stripe's webhook event notifications via email to manually verify each donation completion
• Consider using Stripe's webhook endpoint verification test feature to confirm your endpoint is properly configured after patching

# Example: Restrict webhook access to Stripe IPs using .htaccess (Apache)
# Note: Verify current Stripe IP ranges from Stripe documentation
<Files "charitable-webhook.php">
    Order Deny,Allow
    Deny from all
    Allow from 54.187.174.169
    Allow from 54.187.205.235
    Allow from 54.187.216.72
    # Add additional Stripe IPs as documented
</Files>