Most Bug Bounty Writeups are Recycled: Real Bugs are Hiding in the Specs

Introduction

A lot of people in bug bounty keep reading the same stuff. Same recon tips. Same payload lists. Same “how I found XSS” stories. Same fake-deep writeups that sound smart but do not actually teach you how real systems work.

That is exactly where I got stuck for a while. I was past beginner level, but I still felt like I was trapped in that middle stage where you know enough to test things, but not enough to consistently spot deeper bugs. I could do the usual workflow. I could try common auth tests, common web bugs, common edge cases. But most of it felt surface-level.

At some point I realized the problem was not that I was lazy or missing tools. The problem was that I was mostly learning bug bounty content, not learning the actual protocols and systems behind the bugs.

That changed when I started reading specs. Not another hype thread. Not another “top 10 bug bounty tips” post. Actual documentation.

The Bug: Google Login Flow

The bug was in a Google login flow. Most implementations get the important part wrong.

What the Vulnerable Logic Looked Like

The application was basically doing this:

1. Google returns email = admin@org.com
2. Application looks for existing account with email = admin@org.com
3. Application logs that Google user into the existing account

Why Email is a Bad Identity Key

The email is just an attribute. It is useful, but it is not permanent. It can be reassigned, recycled, recreated, or returned under a different real-world owner later. Once you understand that, the entire bug becomes obvious.

Scenario 1: Same Organization, Same Email, Different Person

Imagine an organization where an employee leaves and their email is later assigned to a new employee. If the application relies solely on the email claim, the new employee could potentially gain access to the old employee's account if the authentication flow doesn't verify the underlying identity.

Scenario 2: Expired Domain and Recreated Mailboxes

The second case is even more interesting. An organization shuts down and its domain expires. Later, somebody else registers that same domain again and recreates old-looking mailboxes on it. For example: admin@old-practice.com.

The Root Cause

The root cause in one sentence: Email is not a stable identity in OpenID Connect.

What the Correct Implementation Should Do

You find these bugs when you stop treating authentication as a black box and start asking protocol questions:

• What exactly is this app using as the account key?
• Is it trusting email or trusting iss + sub?
• What happens if the mailbox changes owners?
• What happens if the domain expires?
• What happens if the same email comes back under a different Google identity?

Those are not payload questions. Those are protocol questions.

The Bigger Lesson

Account recovery edge cases and protocol nuances are not as glamorous as XSS, but they are often much more meaningful. Most of them become easier to spot once you stop only reading writeups and start reading the docs those writeups never mention.

Final Thought

This finding did not come from some magic trick. It came from understanding one boring but important truth: email is not a stable identity in OpenID Connect.

Once you really understand that, you start seeing the bug everywhere an application makes identity decisions on the email claim alone. That is the difference between recycled content and real bug hunting.

Credits: This article was originally written by sin99xx on Medium. You can read the original post here.