Otter Blocks unsigned cookie lets anyone forge Stripe ownership

TL;DR - otter-blocks <= 3.1.4: get_customer_data trusts an unsigned o_stripe_data cookie to decide Stripe product ownership. No server-side verification against the Stripe API. Set the cookie to any product ID - which is visible in the checkout block's HTML source - and check_purchase treats you as a paying customer. Unauthenticated, no credentials needed. Patched in 3.1.5.

What happened

Otter Blocks is a WordPress block suite that includes conditional visibility and Stripe checkout blocks. It's used to gate content behind purchase checks - think paid courses, premium downloads, or members-only pages.

CVE-2026-2892 is a purchase verification bypass. The plugin's get_customer_data method reads an o_stripe_data cookie and uses it to determine whether a visitor owns a given Stripe product. For one-time payment mode purchases, the check_purchase method trusts that cookie-derived value without ever confirming it against the Stripe API.

The cookie is unsigned. Anyone can forge it. Wordfence notes the target product ID is already exposed in the checkout block's HTML source, so the attacker doesn't even need to guess.

This is the entitlement anti-pattern in its purest form: a client-controlled value standing in for a server-validated claim. It shows up repeatedly across payment integrations, and the fix is always the same - verify ownership server-side, every time.

Who is impacted

• WordPress sites running otter-blocks at versions <= 3.1.4.
• Sites using Otter Blocks conditional visibility to gate content behind Stripe purchase checks.
• Highest exposure where the gated content is genuinely sensitive: signed download URLs, API keys or credentials embedded in pages, premium documentation, or private assets intended for paid customers only.

What to do now

• Update immediately to 3.1.5 or any newer patched release.

  "Remediation: Update to version 3.1.5, or a newer patched version"

• Inventory your WordPress instances for the otter-blocks plugin and confirm installed versions across all environments.
• Treat any purchase-gated content on affected versions as potentially already bypassed:
  • Identify what was behind the gate: downloads, embedded credentials, private URLs, premium documentation.
  • If anything sensitive was protected only by this gating, rotate or re-issue it now. Regenerate signed download URLs, rotate any embedded API keys, invalidate shared credentials.
• After patching, manually test purchase-gated flows end-to-end. Confirm the site is no longer making access decisions based on client-supplied purchase state.