Intro - a normal night that turned interesting

Bug hunting looks cool on Twitter: big payouts, P1 RCEs, flex posts. Reality is usually half-cold coffee, many tabs, and small logic bugs that break real user trust.

I found one of those quiet but dangerous bugs on a Google subdomain. Short version: you could create a full account for any Gmail address, get a token, and change profile or cart - all without email verification and without rate-limiting. Bad, right? Very bad.

This is my story - how I found it, how I reported it, the follow-ups, the frustration, and what I learned.

Whoami?

Ek aur din, ek aur vulnerability. Same banda, naye emotions 😭. Intro ke liye purane writeups padho yaar.
(Translation - Another day, another vulnerability. Same guy, new emotions 😭. Read old write-ups for the intro, friend.)

The “wait, that worked?” moment

I was just poking around the Website. I found the website is using graphql , I already had learned how graphql works and stuff so without wasting time I runned Graphql Introspection query and I found many things. Interestingly i found an registeration mutation. I tried and results , Success.

No OTP. No verification. Just a token in response. I could update name, add address, and even pre-fill the shopping cart via GraphQL mutations.

Two feelings hit me: (1) “Yes - proof!” and (2) “Oh no - this is dangerous.”

The main reason it is more dangerous because they only have SSO for Sign-up / Sign-in , if the real user later logged in with Google OAuth, they would land inside the account I had already created. Zero-click takeover. Silent and nasty.

(Fun Fact- They can’t even revoke the account as they don’t have any reset password option or any other way they can revoke the JWT token.)

I tested carefully and kept all sensitive stuff private. I made a small, repeatable PoC: createCustomer → generateCustomerToken → updateCustomer/addProductsToCart → victim logs in via OAuth → victim ends up in attacker account.

PoC and impact (short & clear)

I prepared:

• a private PoC video (redacted here),
• reproduction steps (sanitized),
• a clear impact list.

Why it matters:

• Zero-click account takeover — no phishing, no user interaction needed.
• Persistent access — attacker has a valid JWT; victim cannot revoke.
• Business logic abuse — attacker can prefill carts, spam, change profile, maybe place orders if payment saved.
• Internal risk — I tested behavior for an internal-style email during private testing (kept private here).

This was a logic bug, not a shiny exploit - but the damage could be real.

Reporting to Google VRP — timeline (real, no filter)

I submitted the report and started the usual back-and-forth.

• Jun 13, 2025 — Report submitted (triaged).
• Jun 18, 2025 — Sent detailed attack scenario and PoC video to Google on request.
• Jun 28, 2025 — Clarified that the victim cannot remove attacker or revoke token.
• Jul 7, 2025 — Shared additional impact (internal-style email test — private).
• Jul 10, 2025 — Status: accepted (filed to product team).
• Jul 24 & Jul 31, 2025 — VRP panel’s reward decision: $0.
• Oct 15, 2025 — Final: closed — reason: application is operated by a third-party vendor (out of scope for VRP).

Important: I also tried contacting the vendor directly about the bug, but I didn’t get a reply from them. Still, the vulnerability was eventually resolved now they have forget password option GraphQL is also secured (good - users protected), even though vendor communication was radio-silent from my side.

The emotional part - excitement and a bit of let-down

That PoC moment - big dopamine spike. Getting triaged and accepted - validation. The follow-ups - expected. The closure because of “vendor-operated” scope - frustrating.

I pushed with WHOIS and ownership info, argued that a Google subdomain with user-facing security issues needs fixing regardless of vendor operation. The panel reviewed and still closed the report citing vendor operation. It felt like: I did the right technical job, but the procedural ladder stopped the reward path.

Still - the main win: the bug was fixed. That’s what matters for users.

What I learned (practical, short)

If you hunt logic bugs or build auth systems, keep these in mind:

• Check signup & SSO edges first. Signup, invite, change-email, SSO-linking - these often hide logic mistakes.
• Don’t issue long-lived tokens before verification. Tokens before verification = trouble.
• Give users session visibility & revocation. If someone links via SSO, users should be able to see and remove sessions.
• Rate-limit / CAPTCHA unauthenticated endpoints. GraphQL is powerful — throttle public mutations.
• Collect ownership evidence early. WHOIS, registrar info, footer screenshots — they help if scope is questioned.
• Be ready for non-technical fights. Scope and ownership debates happen. Patience + evidence win.

Message for other researchers — short & real

Be curious more than flashy. Tools help, but thinking wins. Click around like a normal user. Try weird flows. Ask “what if” and follow it.

When you report:

• Make PoC repeatable and clean.
• Explain impact in simple words engineers understand.
• Back your claim with evidence (logs, screenshots, WHOIS) - especially if scope might be a problem.

And emotionally: a $0 reward or closure doesn’t mean you lost. You protected users. You learned. You built credibility. Keep going.

TL;DR

I found an unauthenticated GraphQL flow on a Google subdomain that allowed account creation, token issuance, and profile/cart manipulation without email verification or rate-limiting - enabling 0-click pre-account hijack. I reported it to Google VRP (detailed PoC + follow-ups). I tried to contact the vendor but didn’t get a reply. The VRP eventually closed the report as vendor-operated, but the vulnerability was resolved. Lesson: logic bugs hide in plain sight - be curious, report clearly, and don’t stop.

Signing off,
cyberhrsh