CVE-2026-12432: WP Full Stripe Free Missing Authorization in Payment Status Update

Technical summary

The wpfs_update_failed_payment_status AJAX action in WP Full Stripe Free is registered via both wp_ajax_ (authenticated) and wp_ajax_nopriv_ (unauthenticated) hooks. The underlying update_failed_payment_status() function omits all authorization controls: no capability check via current_user_can(), no WordPress nonce verification, and no explicit logged-in user check. When invoked, the function passes attacker-supplied POST parameters directly to $this->db->updatePaymentByEventId(), allowing arbitrary modification of payment status fields. The attack vector is network-based, requires no user interaction, and no privilege escalation is needed since unauthenticated access is explicitly enabled. Exploitation is deterministic given a valid Payment Intent ID, which is routinely exposed to the customer's browser during normal Stripe.js integration.

Business impact

WordPress sites using WP Full Stripe Free may experience payment reconciliation issues, including inaccurate order records and confused accounting. Attackers could retroactively mark legitimate transactions as failed, creating confusion in financial records and potentially triggering customer disputes or refund requests. The reputational risk is moderate—this is a data integrity issue rather than a data breach—but it directly affects trust in payment handling and order accuracy. Sites relying on automated payment reconciliation workflows are at higher risk of operational disruption. The vulnerability does not expose payment card data or customer personal information.

Affected systems

WP Full Stripe Free plugin for WordPress in all versions up to and including 8.4.3 are affected. Any WordPress site with this plugin installed and active is vulnerable if it accepts payments via Stripe. The plugin is installed on thousands of WordPress sites, making this a broad-exposure vulnerability. No version is known to be patched; check the WordPress plugin repository or vendor advisory for the current status and availability of fixed versions.

Exploitability

Exploitation is straightforward. An attacker needs only a valid Stripe Payment Intent ID (easily obtained by inspecting network traffic during a real or test checkout on the target site) and can then craft an HTTP POST request to the wp-admin/admin-ajax.php endpoint with action=wpfs_update_failed_payment_status and attacker-supplied parameters. No authentication, no user interaction, and no complex setup are required. The CVSS score of 5.3 (Medium) reflects the integrity impact and low attack complexity, tempered by the absence of confidentiality or availability impact. This is not currently listed on the CISA Known Exploited Vulnerabilities (KEV) catalog, but the low barrier to exploitation means discovery and malicious use are likely once the vulnerability is disclosed.

Remediation

Update WP Full Stripe Free to a patched version as soon as it becomes available. Verify the vendor advisory for the minimum safe version. Until a patch is released, consider disabling the plugin if payment processing is not currently in use, or limit access to wp-admin/admin-ajax.php via web application firewall (WAF) rules to authenticated users only. This is a stopgap; proper patching is the only reliable fix.

Patch guidance

Monitor the official WordPress plugin repository and the vendor's security announcements for a patched release. Apply the update immediately upon availability to all affected WordPress installations. Because this plugin handles payment data, treat patching as high priority. Test the update in a staging environment first to ensure compatibility with your Stripe configuration and any custom payment workflows before deploying to production. Verify that the patched version includes proper nonce validation and capability checks in the wpfs_update_failed_payment_status handler.

Detection guidance

Monitor web server logs for POST requests to wp-admin/admin-ajax.php with action=wpfs_update_failed_payment_status originating from untrusted or external IP addresses. Review payment records for anomalous status changes, especially transitions from successful to failed without corresponding customer or administrator action. Enable logging on the WordPress database level if available, and audit updates to payment tables for entries modified outside normal checkout workflows. A WAF rule detecting this specific AJAX action from unauthenticated sessions would provide early warning.

Why prioritize this

Although the CVSS score is Medium (5.3), prioritization should reflect the business context. Sites handling significant transaction volume or those with strict payment audit requirements should patch this promptly due to the integrity risk and potential compliance implications. The low attack complexity and lack of authentication requirements elevate the practical risk. Since no exploit is yet public and KEV listing is absent, there is a window for proactive remediation before active exploitation becomes widespread.

Risk score, explained

The CVSS 5.3 score (Medium) is driven by: network attack vector (AV:N), low attack complexity (AC:L), no privilege requirement (PR:N), no user interaction (UI:N), and isolated scope (S:U). The integrity impact (I:L) is the primary concern—attackers can modify payment status and metadata. Confidentiality and availability are not impacted. The score does not account for the business sensitivity of payment data or the reputational harm of a compromised audit trail; security teams should consider internal risk context and transaction volume when prioritizing beyond the base CVSS metric.

Frequently asked questions