Skip to main content

Reporting leaked secrets & credentials

Inti avatar
Written by Inti
Updated over 2 years ago

Accidentially leaked secrets such as access tokens, passwords and API credentials can have a significant impact on the cybersecurity posture of an organisation. With dark web and leak monitoring services becoming increasingly popular, it is not uncommon for third party cybersecurity researchers to responsibly disclose leaked secrets to organizations. Vulnerability reports containing leaked credentials may not always include a technical vulnerability that can be addressed by program managers and may therefore follow a different assessment process.

By default, our team of security analysts will always forward submissions containing valid credentials to our clients. Depending on the situation, we may not always advice to issue a reward for the submission, even if the credentials are valid.

During the assessment process, we make a destinction between the a leak's credential types and leak cause and leak source.

Credential types

We typically see two types of credentials reported:

  1. Personal passwords, access tokens or credentials

    These are secrets that belong to an individual user or employee. Some organisations may consider these tokens as out of scope for their vulnerability reporting program if there is no clear actionable path to prevent these leaks from happening (e.g. a third-party leak in which the user used the same credentials). Bruteforcing personal or employee passwords is typically not allowed within the scope of a bug bounty program.

  2. Application secrets

    These credentials are not tied to a specific individual and may be the only way to programmatically get access to a certain resources. Since application secrets leaks are frequently caused by technical vulnerabiities or misconfigurations, we recommend to consider them in-scope for your bug bounty program. Guessing weak credentials that do not belong to a user (e.g. a basic authentication prompt with 'admin' as the username) are typically in-scope for a bug bounty program.

Leak cause

The leak cause defines who or what is responsible for the credential leakage.

  1. Internal leaks

    An incidental leaks are caused by a bug, software error, vulnerability, misconfiguration or oversight caused by a process, system or individual within the affected organisation. Internal leaks may occur on third-party services (such as GitHub or Postman), but are always the result of an action or process from within the affected organisation.

  2. External leaks

    External leaks are caused by third-parties. They may either be accidental or malignant. A hosting or DNS provider may accidentially leak data from their clients that may result in compromise, or a leaked database may contain access tokens for in-scope services. While most companies accept these reports as part of their responsible disclosure process, they may not qualify for a bounty.

Leak source

The source defines where the leaked data is accessible.

  1. First-party source

    If the leaked data is displayed on an in-scope asset beloning the organisation, it may be considered as a vulnerability and typically follows the standard disclosure process.

  2. Third-party source

    Incorrectly configured third-party software or repositories

    If the leaked data is shown on an asset that is out of scope or does not belong to the affected organisation, it may be considered in-scope if the credentials were discovered through passive web browsing (e.g. using the search functionality of GitHub, Bitbucket), depending on the program guidelines and credential types.

    Leaked credential lists, databases, monitoring services and marketplaces

    There are several third-party applications that specialise in collecting and monitoring leaked secrets. While these tools may not be illegal when used for legitimate purposes such as security testing, it may raise some ethical concerns.


    In general, we do not recommend to issue bounties to reporters who responsible disclose leaked secrets originating from credential marketplaces. While reporters may be act in good-faith and trying to help, they may be indirectly funding the activities of cyber criminals by purchasing this data. Programs that issue bounties for these credentials may further incentivise that and encourage cybercriminals to further conduct attacks against their assets.

Did this answer your question?