Disclosing BCC Recipients of an email

Home > Blog > HackerOne

Disclosing BCC Recipients of an email


This post will cover an interesting logic flaw found in a private bug bounty program. Whilst the name of this company will be known as [REDACTED], the purpose of this post is to demonstrate how we can turn a feature into a bug. The feature in question allows users to send and receive emails in a secure manor but by checking a few response headers the integrity of the application is broken. Here's the report submitted via Hackerone albeit slightly redacted..


The [REDACTED] product has an end point /rest/users/preauth which is used to validate whether a user has access to a certain object before redirecting them to a login page.

The issue is that this logic can be used against [REDACTED] to work out who an email was sent to. This itself may not be a huge worry but I am able to disclose whether a user is within the BCC field, without authentication - this would be a privacy issue and goes against concept of a blind carbon copy.

Steps To Reproduce

Lets say my business decides to use [REDACTED] as a product, we have 8 members of staff who's emails are as follows:

  • ashleyking@wearehackerone.com
  • ashleyking+original@wearehackerone.com
  • ashleyking+bcc@wearehackerone.com
  • ashleyking+user1@wearehackerone.com
  • ashleyking+user2@wearehackerone.com
  • ashleyking+user3@wearehackerone.com
  • ashleyking+user4@wearehackerone.com
  • ashleyking+user5@wearehackerone.com
  1. User ashleyking@wearehackerone.com sends an email to ashleyking+original@wearehackerone.com and BCC's ashleyking+bcc@wearehackerone.com.
  2. Both of the recipients receive an email - only ashleyking+original@wearehackerone.com is visible in the message headers
  3. ashleyking+original@wearehackerone.com can now use the Intruder feature of Burp Suite to see if any of their colleagues were BCC'd into the email.

Step 1

Create a new request in the Intruder tab, set the target to be hackerone.bounty.[redact].net and Port 443 (use HTTPS)

Step 2

Create the request in the positions tab. Where w= is followed by the ID of the email. You can find this in the link that was sent via the email.

We also need to include the header X-[redact]-Version with a value of [redact]

Step 3

Add your known list of users within the business to the `Payloads` tab. (encode the `+` symbol if necessary)

Step 4

Start the attack. For this particular example we will see the following output:

  • If we see a response status of 200 we can confirm that the user is a recipient of the email
  • if we see a response status of 403 we can confirm that the user is NOT a recipient of the email.


A user is able to validate whether any of their colleagues has been BCC'd into any email they receive. This defeats the original purpose of a blind carbon copy and breaks the integrity of the email sent from [REACTED].

This business logic issue was worth $750


about me

30 year old multistack developer & security researcher based in Gosport, UK. I like to blog about interesting vulnerabilities I come across, when allowed 🙄