The Vulnerability: Receipt Replay / Lack of Binding Based on analysis of grey market operations, attackers have automated the following workflow:
Create fresh Google Play accounts to trigger introductory offers (Free Trials/Discounts).
Intercept the purchaseToken / receipt data returned by Google's Billing API.
The Exploit: The backend validation endpoint appears to accept valid Play Store receipts without strictly verifying if the obfuscatedAccountId (or internal user ID binding) matches the OpenAI account requesting the upgrade.
This allows attackers to "inject" or "transfer" a legitimate trial receipt onto unrelated OpenAI accounts, effectively cloning the subscription status.
Current Impact This is not a theoretical bug. It has spawned a massive reselling market. Telemetry from reseller communities suggests a throughput of 8,000 to 10,000 accounts per day.
Evidence / Attribution Several large-scale unauthorized resellers are openly utilizing this method. These platforms claim to have distributed hundreds of thousands of accounts. Examples of domains involved in this distribution include:
bewildcard . com (Widely known for virtual cards, now allegedly distributing these subs)
nf . video
Technical Mitigation If any OpenAI engineers are reading this: You must enforce strict 1:1 binding verification on the server side. The developerPayload in the purchase request must be cryptographically signed and matched against the user ID during the verifyPurchase callback.
This post is intended to bring attention to the flaw so it can be patched, as standard support channels have been unresponsive.