Critical Formidable Forms Access Control Vulnerability

Plugin Name	Formidable Forms
Type of Vulnerability	Access control vulnerability
CVE Number	CVE-2026-2890
Urgency	High
CVE Publish Date	2026-03-17
Source URL	CVE-2026-2890

Urgent: What WordPress Site Owners Need to Know About the Formidable Forms Payment Integrity Vulnerability (≤ 6.28) — and How to Protect Your Site

Published: 13 Mar, 2026
Author: WP-Firewall Security Team

---

Summary

• A recently disclosed broken access control vulnerability affects Formidable Forms (versions ≤ 6.28).
• The issue allows unauthenticated actors to bypass payment integrity checks by reusing PaymentIntent identifiers (a Stripe concept), which can result in false-positive payment acknowledgements or unauthorized payment-related state changes.
• A patched release is available (6.29). Update immediately. If you cannot update right away, apply mitigations described below — including WAF rules, server-side verification against your payment provider, and monitoring.
• This post walks through the risk, practical mitigations for site owners and developers, and a hardened incident response checklist drawn from real-world WordPress security practice.

Note: This advisory is written from a WordPress security perspective. We do not include exploit code or step-by-step instructions to reproduce the issue. If you manage a site that accepts payments via Formidable Forms + Stripe (or similar integrations), read on and take action.

---

What happened — plain English

Formidable Forms includes integrations for accepting payments. A fault in access control logic in versions up to and including 6.28 meant an unauthenticated user could trigger a flow that appears to accept or validate a payment by reusing a previously issued PaymentIntent identifier. In short: an attacker can present or reuse a PaymentIntent reference in a way that the plugin treats as a valid completion check, without possessing the proper authorization or controls that should guard that operation.

Consequences can include:

• Transactions being marked “completed” or “accepted” when they were not (fraudulent orders)
• Discrepancies between your site’s order/payment records and the payment provider (chargebacks, reconciliation issues)
• Confusion in order fulfillment and potential financial loss
• A vector that attackers could use as part of a larger fraud campaign

The plugin author released version 6.29 with a fix. If your site still runs ≤ 6.28, please update immediately.

---

How severe is this?

• The advisory lists a CVSS-like score (7.5) driven by the potential for bypassing payment integrity checks; however, the real-world impact depends on several factors:
  • Whether your site uses Formidable Forms for payment processing (Stripe, etc.).
  • Whether your site uses server-side verification against the payment provider to confirm PaymentIntent status.
  • Whether the endpoint that processes payment confirmations is exposed to unauthenticated access.
• Some sites may be at low real-world risk if they already validate payments server-side and tie PaymentIntents to authenticated sessions or orders. Other sites that rely solely on the plugin’s internal checks may be exposed.

Because payment processing is high-value, treat this as high priority for sites that accept payments. Even if exploitation is not trivial, the potential impact on revenue and customers makes this a situation where immediate remediation is justified.

---

Immediate actions for site owners (what to do in the next 60–90 minutes)

1. Update the plugin
   • The simplest and most reliable fix is to update Formidable Forms to 6.29 or later. Do this as soon as possible.
   • If you have staging before production, push the update there first; but if you cannot test quickly, prioritize production update for eCommerce sites.
2. If you cannot update immediately, apply temporary mitigations:
   • Temporarily disable any payment forms backed by Formidable until you can update and verify them.
   • Block or restrict access to endpoints used for payment confirmation when possible (see WAF and web server rules below).
   • Enforce rate limiting on payment-related endpoints to slow mass attempts.
3. Review logs and recent transactions
   • Check access logs and form-submission logs for suspicious patterns: repeat POSTs with payment_intent parameters, spikes in payment-confirmation calls, or non-matching IPs.
   • Reconcile recent site-marked “paid” orders with your payment provider dashboard (Stripe, etc.) to identify mismatches.
4. Notify stakeholders
   • If your commerce team or finance needs to reconcile payments, inform them immediately so they can monitor chargebacks and refunds.

---

Short-term WAF and hosting mitigations (recommended until plugin is updated)

If you operate a Web Application Firewall or can configure rules at the server/host level, you can reduce risk immediately without changing plugin code.

Suggested protections (conceptual — adapt to your WAF or host controls):

• Block or require authentication for requests that attempt to confirm or modify payment status on public endpoints.
• Require a valid WordPress nonce or custom header when endpoints receive POSTs that include a payment_intent or payment-related parameter.
• Rate-limit POST requests that include the string “payment_intent” or other payment parameter names to reduce mass attempts.
• Monitor and block suspicious IPs exhibiting many payment-related POSTs.

Example pseudo-rule descriptions (do not copy verbatim into production without testing):

• If POST contains “payment_intent” and request is unauthenticated: block or challenge.
• If POST to admin-ajax.php (or a Formidable REST endpoint) contains payment parameters and lacks a valid nonce header: block.
• Enforce request rate limits on payment endpoints per IP (e.g., 5 requests per minute) and block if exceeded.

These mitigations are effective as temporary measures but are not a substitute for updating the plugin and adding server-side payment verification.

---

Why server-side verification matters (developer guidance)

A robust payments flow should never rely only on client-side or plugin-level acknowledgements without verifying the payment provider’s authoritative state.

Best practice:

1. When a payment is initiated, store an internal record linking:
   • your internal order or submission ID,
   • the PaymentIntent ID,
   • expected amount and currency,
   • customer identifier (if available).
2. When receiving a webhook or a request claiming payment completion:
   • Use your server to call the payment provider API (e.g., Stripe) to retrieve the PaymentIntent status.
   • Confirm the status equals a final, settled state (succeeded, charged) and that the amount/currency match your records.
   • Verify that the PaymentIntent is associated with the same customer/email/order in your system.
3. Only mark an order as “paid” once server-side verification succeeds.

If your plugin uses webhooks, ensure the webhook signing secret is verified (Stripe provides HMAC signature headers) and that webhook endpoints require the signature check and validate payload fields against your stored state.

This vulnerability highlights the danger of trusting only internal plugin logic or unverified POSTs to mark payments as completed.

---

Developer remediation checklist (what plugin authors and site devs should implement)

For plugin maintainers and developers building on top of Formidable Forms:

• Enforce proper authorization
  • Add capability checks so only the intended users (or the system) can confirm the payment status.
  • Avoid exposing payment confirmation endpoints as unauthenticated actions unless the action is safe and validated.
• Apply nonce and CSRF protections
  • Ensure admin-ajax or REST routes require valid nonces or use WP REST capability checks.
• Tie PaymentIntent verification to server-side checks
  • Always call the payment provider API and verify the PaymentIntent status before marking anything as paid.
• Avoid relying on client-side POSTs as the sole source of truth
  • Use webhooks as the authoritative source (with signature verification) and corroborate webhook events with your internal records.
• Log and alert on odd behavior
  • Log every payment-confirmation attempt with IP, timestamp, parameters, and verification outcome.
  • Raise alerts for mismatches between internal records and provider-confirmed states.
• Regression test payment flows
  • Create automated tests simulating payment initiation, success, and failure, including attempts to reuse existing PaymentIntent IDs.

---

How WP-Firewall protects customers (virtual patching & detection)

If you are a WP-Firewall customer (or evaluating protective measures), here are practical ways a managed WAF and security stack helps immediately:

• Virtual patching
  • Our security team can deploy targeted rules that intercept and block exploit attempts against known vulnerable endpoints until the plugin is updated.
  • Virtual patches are non-invasive and do not change plugin files — they act as a protective layer in front of your site.
• Signature-based detection
  • We create signatures that match suspicious POSTs containing PaymentIntent parameters targeting Formidable-related endpoints and flag or block them.
• Behavior-based protections
  • Rate limiting and bot detection protect payment endpoints from mass misuse.
• Monitoring and alerts
  • Continuous monitoring for spikes in payment endpoint activity; immediate alerts sent to admins for unusual patterns.
• Forensic logs and support
  • If a suspicious incident happens, WP-Firewall preserves detailed logs for forensic analysis and can assist with incident response and remediation.

If you operate payments on your WordPress site, a WAF with rapid virtual patching and tailored rules for payment endpoints is an effective layer of defense while you patch.

---

Detection indicators — what to look for in logs

Search your logs (web server, plugin logs, WAF) for these indicators:

• Repeated POSTs to admin-ajax.php, REST endpoints, or Formidable submission endpoints that include parameters like payment_intent, payment_method, or stripe_* identifiers coming from the same IP or small range of IPs.
• Unusual spikes in form-submission traffic outside normal business hours.
• POSTs without valid WordPress nonces to endpoints that normally require them.
• Multiple different PaymentIntent IDs submitted from a single IP or user agent in a short timespan.
• Orders marked “paid” in your system with no corresponding successful capture or charge in your payment provider dashboard.

Any of these could mean someone probing or abusing payment-confirmation logic.

---

Incident response playbook (if you suspect compromise)

1. Isolate the issue
   • Temporarily disable payment forms or place them in maintenance mode if exploitation is suspected.
   • Apply WAF blocks for suspicious IPs.
2. Update and patch
   • Update Formidable Forms to 6.29 or later immediately.
   • Update all other plugins/themes and WordPress core.
3. Verify payments
   • Reconcile site-marked paid orders with your payment provider ledger. Identify mismatches.
   • For any questionable orders, consider refunding or contacting customers while investigations continue.
4. Rotate sensitive credentials
   • Rotate payment API keys if you suspect exposure or unusual activity related to payment validation calls.
   • Enforce new keys in server configs and re-deploy.
5. Scan for compromise
   • Run a full site malware scan and integrity check for modified files, backdoors, or unknown admin users.
   • Look for added scheduled tasks, rogue admin accounts, or unusual outbound connections.
6. Preserve evidence
   • Preserve logs (WAF, web server, plugin logs) to assist forensic investigation.
7. Communicate
   • Inform internal stakeholders and consider notification to affected customers if sensitive data or fraudulent charges occurred (follow payment provider and local legal guidance).
8. Remediate long-term
   • Harden endpoints, implement server-side payment verification, improve logging and alerting, and perform a post-incident review to remediate root causes.

---

Payment processing hardening (Stripe and general)

Whether you use Stripe or another provider, strengthen your payment handling:

• Use server-side verification of payment status. Do not mark payments as successful until verified by provider API.
• Use webhook signatures and verify them on receipt (Stripe sends a signature header you can verify).
• Ensure webhooks are delivered to HTTPS endpoints with TLS 1.2+ enforced.
• Tie PaymentIntent IDs to internal transaction IDs and validate amounts/currency before accepting.
• Keep API keys in secure storage (env variables, not code) and rotate periodically.
• Apply strict webhook endpoint access controls (IP allow lists when feasible).
• Log all webhook events and verification outcomes.

---

Testing & ongoing security hygiene

• Run automated tests for payment flows in staging after plugin updates.
• Employ static and dynamic security checks pre-deployment for plugins you install or develop.
• Implement least-privilege access for WordPress admin accounts and enforce strong authentication (two-factor authentication).
• Monitor the security advisory channels for plugin updates and release notes (subscribe to trusted feeds).
• Maintain an incident response plan and periodic tabletop exercises with your operations/finance teams.

---

Why you should not assume “no one would attack me”

Attackers commonly target WordPress payment flows because they are high-value. Automated scanners and bot networks look for exposed or misconfigured payment endpoints at scale. A small or medium business may be targeted simply because an endpoint is available and can be misused.

Being proactive — by updating plugins promptly, verifying payments server-side, and using a WAF with virtual patching — is the most reliable way to reduce risk.

---

How WP-Firewall helps you stay resilient

As a managed WordPress security provider, our approach prioritizes speed, accuracy, and minimal friction:

• Rapid virtual patching to block exploit attempts for new, disclosed vulnerabilities.
• Tailored WAF rules for payment-related endpoints and widely used plugin patterns.
• Continuous monitoring and alerts for suspicious payment-related activity.
• Expert guidance and incident response support for customers who suspect a compromise.

We focus on reducing business impact: stopping automated exploit attempts, preserving evidence, and helping you return to normal operations quickly.

---

New Title: A Better Way to Protect Your Payments — Try WP-Firewall Free Plan Today

If you manage payments on your WordPress site, protecting payment endpoints and ensuring payment integrity should be a top priority. WP-Firewall’s free Basic plan gives you essential protections immediately — managed firewall, unlimited bandwidth, WAF, malware scanning, and mitigation against OWASP Top 10 risks — all at no cost. Start with the free plan to get baseline protections in place while you update plugins and harden payment verification. Sign up and protect your site here: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(If you need more advanced protections, our Standard plan adds automatic malware removal and IP allow/deny lists, and our Pro plan includes monthly security reports and automatic virtual patching for discovered vulnerabilities.)

---

Practical example: What we block as a temporary safety measure (description only)

When a vulnerability like this is disclosed, the WP-Firewall security team typically implements multiple layers of defensive logic:

• Signature rules that detect and block unauthenticated POSTs containing payment parameters sent to known Formidable endpoints.
• Rate limiting and bot-detection rules to disrupt automated probe campaigns.
• Conditional rules that require a valid WordPress nonce or custom header for payment-confirmation requests; otherwise, the request is challenged or blocked.
• Monitoring/alerting to notify site owners when suspicious patterns occur.

These protections are applied with minimal false positives and are removed after the site applies the vendor patch. Virtual patching reduces exposure window while you update.

---

Final checklist — 10 things to do right now

1. Update Formidable Forms to 6.29 or later. (Top priority.)
2. If you cannot update immediately, disable payment forms or restrict endpoint access.
3. Apply WAF rules: block unauthenticated requests that attempt to confirm payment state, rate-limit payment endpoints.
4. Verify all “paid” orders in your system with the payment provider dashboard.
5. Rotate payment API keys if you detect suspicious activity.
6. Verify webhook signing on your payment endpoints.
7. Search logs for repeated POSTs containing PaymentIntent or unusual activity.
8. Run a malware and integrity scan after any suspicious activity.
9. Enforce server-side verification of payment states before fulfilling orders.
10. Sign up for a managed security plan that can deploy virtual patches and monitoring while you remediate (start with a free plan if you prefer to test).

---

If you need help implementing mitigations, reviewing logs, or setting up virtual patching and WAF rules, WP-Firewall’s security team is available to assist. Protecting payment flows and preserving customer trust is our priority.

Stay safe — update now.