Bug Bounty Case Study: How a Public ID Exposed Private Account Emails

The UUID was not guessed or brute-forced.

It appeared inside the server-rendered data of a public page. Viewing the page source revealed an identifier associated with the account behind that page.

In simplified form, the data looked like this:

{ "accountId": { "uuid": "00000000–0000–4000–8000–000000000001"}

}

Putting the UUID into the API request

The email endpoint accepted a UUID as a path parameter. Its relevant shape was:

GET /api/v1/accounts/{UUID}/emails

The key test was whether the endpoint required authentication before returning the email data.

According to the report, an unauthenticated request returned HTTP 200 with this response structure:

{ "success": true, "body": ["controlled-test-account@example.com"] }

Confirming what the response contained

An email-shaped string in a response is not enough to establish its relationship to an account.

The report records validation using two researcher-created accounts. The endpoint returned the email addresses used to register those accounts.

That connected three pieces of evidence:

1. A known account and its registration email.
2. The UUID associated with that account.
3. An unauthenticated API response containing the same email.

This supported the finding that the endpoint exposed account email data, rather than merely returning an intentionally published contact address.

Impact

I enumerated more of those IDs on the public pages of the users and got a list of email addresses.

Exposed account addresses could support targeted phishing or identification of accounts to attack. Those are potential follow-on risks.