Free Account Escalates to Editing the Production Billing Catalog
The Risk
Anyone could create a free account and use it to gain the powers of an internal staff tool, then read and change the live list of subscription products and prices. From there an attacker could set a paid plan to free, deactivate a real product, or invent fraudulent ones, hitting revenue directly. It took only a sign-up that anyone can complete in seconds, with no approval and no victim involved. The same access also exposed the full product list, including internal staff email addresses recorded against each product.
The Vulnerability
The platform's sign-in service issued access tokens to named client applications. One of those clients was an internal back-office catalog-management tool, and it was registered as a public client: it issued a high-privilege token to anyone who submitted valid account credentials with no client secret at all.
Because any free, self-registered account could supply its own credentials against that public client id, any user could obtain a token carrying the internal tool's identity and its broad catalog scope. The root misconfiguration was registering an internal, privileged client as public.
- Supplying a junk secret returned an unauthorized-client error.
- Omitting the secret entirely issued the privileged token.
The resulting token unlocked the catalog read and write routes that should have been reachable only by internal staff.
The Attack
Minting the Privileged Token
Using any free account's email and password, a single token request to the sign-in endpoint, naming the public client id and omitting the secret, returned an access token. Decoding it showed the free account now held the internal tool's identity and its catalog scope.
Reading the Catalog
With that token, the product-list endpoint returned the entire production catalog: every subscription product, pricing across roughly fifty currencies including the live in-market premium trial plans, and a couple of dozen distinct internal staff and contractor email addresses recorded as product owners.
Writing to Production
The update route persisted changes to live catalog records. To avoid touching anything real, the proof edited only an internal, non-retail developer test record, appended a marker to its description, confirmed the change persisted by reading it back, then restored the original. The write capability is generic to the endpoint, not specific to that record. The write also accepted a caller-supplied "updated by" field verbatim instead of stamping the real caller, so an attacker could forge the audit trail and attribute changes to anyone.
Negative Controls
The controls proved the privileged token was what unlocked the catalog, not an open endpoint: with no token the request was rejected at the authorization layer, and with a non-privileged client identity header it was rejected as a client mismatch.
The Impact
Any free account could escalate to an internal back-office identity and both read and write the production subscription and billing catalog. The primary impact is integrity of live pricing, demonstrated and reverted: an attacker could change subscription prices, ship a free premium plan, deactivate a live product, or create fraudulent products. This is direct revenue and platform-integrity risk driven from an account anyone can register in seconds. The secondary impact is disclosure of the full catalog and the internal staff email addresses attached to it.
Remediation
- Re-register the internal catalog tool as a confidential client that requires a client secret, and rotate that secret.
- Never expose internal, high-privilege clients through a public credentials grant.
- Enforce server-side authorization on the catalog read and write routes based on the real user's role, independent of which client minted the token.
- Stamp audit fields server-side from the authenticated caller; never trust a client-supplied "updated by" value.
- Remove internal staff email addresses from data returned to non-staff callers.