The CVSS 6.5 rating for this vulnerability materially undersells its actual business impact. For a subscription-based SaaS product, this is closer to a P1 incident than a medium-severity bug — the attack is trivial to execute, requires no technical skill, and results in direct revenue theft that compounds over a full year per exploitation.
The vulnerability is straightforward: the original code treated the existence of a Stripe Checkout Session as equivalent to successful payment. When a user initiates a Stripe checkout, the request includes a client_reference_id field that maps to their account ID. The callback endpoint received this ID back from Stripe and granted premium access without verifying that payment actually succeeded. There was no check of payment_status, no verification of session.status, and no expiration window on the grant — just a simple question: does a session with this user's name on it exist? If yes, here's your premium subscription.
The fix in version 3.4.0 addresses this correctly by requiring both payment_status === 'paid' AND session.status === 'complete'. Stripe can have edge cases where payment_status is 'paid' but the session remains 'open' or becomes 'expired', so checking both fields is proper fails-closed design. The addition of a unique constraint on stripeCheckoutSessionId also closes replay attacks where someone might re-trigger the callback with a legitimately-paid session ID they obtained.
However, there's a critical gap the disclosure doesn't address: retroactive remediation. Anyone who exploited this vulnerability before patching still has an active premium subscription they never paid for. You should audit your user database for subscription grants that occurred without corresponding payment records in your Stripe dashboard. Identify accounts created around the time of exploitation, cross-reference subscription activation timestamps against payment events, and be prepared to revoke access for users who bypassed payment. This isn't just security hygiene — it's quantifiable revenue recovery.
The practical attack surface is every authenticated user in your system. Unlike vulnerabilities requiring phishing or technical sophistication, any user who ever created an account can trivially exploit this. For self-hosted deployments, the CVE publication creates an immediate exploitation window — operators must upgrade to 3.4.0 promptly, as every existing user now has a direct path to free premium if the instance remains unpatched.