Summary

I found an open redirect (CWE-601) in the Contact Form 7 – PayPal & Stripe Add-on WordPress plugin, affecting all versions before 2.5. It was assigned CVE-2026-14236 and coordinated through WPScan.

The plugin takes a user-supplied return URL and drops it straight into the Stripe Checkout success_url and cancel_url without checking the host. An unauthenticated attacker can craft a link that runs a real checkout on the legitimate store and then bounces the victim to any external site — a high-credibility phishing primitive, since the whole flow starts on the trusted domain.

The bug

During the Stripe checkout flow, the plugin reads a cf7pp_return parameter from the request and uses it to build both the success and cancel redirect targets that Stripe sends the user to after checkout.

The only validation applied is:

filter_var($url, FILTER_VALIDATE_URL)

That check only confirms the string is a syntactically valid URL — any absolute external URL passes it. There is no same-origin or host allow-list, so https://attacker.example/... is accepted just as happily as a path on the store’s own domain.

The tainted value flows into:

success_url = https://attacker.example/fake-error?cf7pp_stripe_success=1&cf7pp_fid=4&id={CHECKOUT_SESSION_ID}
cancel_url  = https://attacker.example/fake-error

Proof of concept

Prerequisites: a Contact Form 7 form with a Stripe price set and Stripe configured — i.e. the plugin’s normal payment state. No non-default option is required.

An unauthenticated attacker crafts a link to the store using their own URL as the return parameter:

https://victim.example/?cf7pp_stripe_redirect=4&cf7pp_fid=4&cf7pp_return=https://attacker.example/fake-error&cf7pp_p=55

The victim engages a real Stripe Checkout on the legitimate store domain, and on completion (success_url) or cancel (cancel_url) is redirected to the attacker’s site.

Because the transaction genuinely happens on the trusted store, the victim has every reason to trust whatever page they land on afterwards — a fake “payment error, re-enter your card” page on the attacker domain is extremely convincing.

Impact

  • Phishing / credential harvesting: land the victim on a look-alike error or login page right after a legitimate payment.
  • Trust abuse: the flow begins on the real store domain, so the redirect inherits that credibility.
  • Unauthenticated + one click: the whole thing is a single crafted link, no account needed.

Notes on the fix

Confirmed still present in 2.4.10 at the time of research: the redirect code (includes/redirect_stripe.php, includes/redirect_methods.php) was byte-identical to 2.4.6. The vendor’s earlier 2.4.8 / 2.4.10 security work only hardened the separate PayPal IPN handler — the Stripe redirect path was untouched until 2.5.

Takeaway: FILTER_VALIDATE_URL is not an authorization check. Validating that something is a URL says nothing about whether it points where you want. Any user-controlled redirect target needs a host allow-list or a same-origin check.

Timeline

  • 2026-06-30 — Reported to WPScan
  • 2026-07-03 — Vendor fix released (2.5)
  • 2026-07-27 — CVE-2026-14236 published

References