How to Determine Bug Bounty Out-of-Scope Assets


Applications and networks are rarely hardened as well as they should be, so why not encourage third-party bug discovery? Organizations that run their own bug bounty program can pay security researchers to submit any bugs they find instead of posting them online or letting attackers find them first.

Those interested in getting started can use Corporate Cybersecurity: Risk Identification and Bug Bounty Program by author and security researcher John Jackson. One aspect to consider when creating a program is what it contains. It is important to note that not all bugs found are always included in a bug bounty policy. Paying for these out-of-scope bugs, Jackson said, is important.

“If you have remote code execution on a server with 100,000 PII [personally identifiable information] records, so ‘out of range’ doesn’t really mean anything anymore,” Jackson said. “Attackers don’t care about out of range. If a hacker touches that data and leaks it, you’re looking at paying a lot of money per record.”

In the following excerpt from Chapter 4, Jackson explains how to determine what out of reach means while not being bound to it at the same time.

Check out a Q&A session with Jackson to learn more about bug bounty programs and how they differ from vulnerability disclosure programs.

Click for more information on

Enterprise Cybersecurity:
Identification of risks and
Bug Bounty Program

4.9 When is an asset really out of scope?

Overall, the purpose of off-scope reporting is never to discourage a security researcher from reporting, but to ensure that basic restrictions are in place to avoid any legal or financial impact. With that in mind, ideally program managers should be fair in assessing which vulnerabilities are in and out of scope.

A security researcher extracts a list of subdomains for the company and finds many assets, some of which are explicitly marked as out of scope. Researchers are curious, either by nature or acquired in life. They want to know how the components work. In this specific scenario, let’s assume that this asset is well known to be out of scope (defined in the out of scope section of the Enterprise Bug Bounty program): should it be tested?

If the answer that comes to mind is Nope, it can be both the right and wrong answer. To illustrate the scenarios managers of bug bounty programs may face, consider an example of vulnerability (P1) — critical — and vulnerability (P4) — low.

(P1) – Critical: Admin Account Takeover

In this scenario, while testing various subdomains, the researcher notices something odd. It looks like one of the subdomains found was “”. The researcher examines the scope and sees that * is listed as out of scope. Nevertheless, curiosity takes over and, to the researchers’ surprise, they find an exposed client-side Laravel debug bar. At this point, they have to make a choice: “Out of scope or not?”

Now, in the case of Laravel Debugbar, imagine that the finder intercepts admin credentials and can connect to the web application that resides on the admin endpoint. The web application portal contains internal employee email addresses, sensitive workflow information, customer addresses and other contact information, etc. A moral dilemma arises and the researcher must now decide whether it is worth reporting a vulnerability identified as “out of scope”.

In most cases, the researcher will report the vulnerability, especially if it involves account takeover or PII (personally identifiable information).

Now run through the following scenario, keeping example P1 in mind.

(P4) — Low: Leaked server information on Apache server status page

Comparably, the same security researcher may have stumbled upon a subdomain named “”. As shown in our previous example, * is out of scope. When loading the web page, the searcher finds the web server’s page/server status and can now see specific information, such as the version, the URL paths it logs, the CPU usage and some internal IP addresses.

Although this may seem like a serious vulnerability for an amateur researcher, the severity of such a vulnerability depends entirely on the level of information accessible. For example, if this server status page logs all endpoints in the root domain, the researcher may find an endpoint that reveals sensitive information after navigating to it. However, if no sensitive information is revealed, either directly or through registered endpoints, the vulnerability will be considered low.

The researcher will once again have to make a choice, report it or not. In many cases, it may simply be pointed out out of love for doing the right thing. The researcher knows that he is in the hands of a program manager to decide whether he will be paid or not. Nevertheless, a bug bounty program manager will have to make the right decision by paying the hacker. Alternatively, with the use of bug bounty platform providers, program managers can resolve the report without monetary rewards which can still benefit the credibility of the researcher.

4.10 The house wins – or does it?

The ultimate decision of many bug bounty programs currently operating is usually not to pay the security researcher if they are out of reach. Some that have been heard reside in the school of thought of “We don’t want to encourage our seekers to hack out of reach assets just to get a bounty” or “If we pay a seeker for an out of reach bounty, we’ll have to pay them for every off-screen bonus.”

A major problem with negative thinking toward off-screen research is that it can lead to key research being overlooked. When determining whether paying for a reported vulnerability seems like the right decision, ask yourself the following questions:

  1. What is the impact level of this vulnerability? Could this lead to leaks of extremely sensitive information?
  2. If no sensitive information is disclosed, could the vulnerability seriously damage the company’s reputation?
  3. Do we appreciate the researcher and do we want to reward him?

One size does not fit all in terms of a security researcher’s compensation. Remember that when managing a program, the rules are established by the program manager. While transparency with leadership should always be exercised, goodwill is key to developing a strong and loyal research platform and building brand reputation within the cybersecurity community. Let’s take our previous examples of critical and weak vulnerabilities and perform a dry run to answer the questions above.

P1 – Take control of the administrator account

  1. What is the impact level of this vulnerability? Could this lead to leaks of extremely sensitive information? Yes, the researcher found several pieces of PII and information that may be valuable if sold or obtained by a malicious actor.
  2. If no sensitive information is disclosed, could the vulnerability seriously damage the company’s reputation? Even if the researcher could not divulge sensitive information, this admin panel contains features that could remove key parts of the business, resulting in monetary impact, in turn leading to reputational damage.
  3. Do we appreciate the researcher and do we want to reward him? Personally, this researcher has never reported to us before, but it would be nice to reward them for their efforts.

In this admin takeover example, it is easy to determine that a lot of damage could occur. Company information could be sold, or there could be a direct impact on business continuity, creating a loss of revenue. That being said, the right thing to do would be to pay the security researcher. In a circumstance such as the one described, there would be far more losses in a breach scenario than there ever would be if the researcher were properly paid. Programs should consider setting a moral example and paying for vulnerability discoveries.

P4 – Apache server status page containing server information

  1. What is the impact level of this vulnerability? Could this lead to leaks of extremely sensitive information? No, there is no leakage of sensitive information. Several internal IPs are displayed, but without impact.
  2. If no sensitive information is disclosed, could the vulnerability seriously damage the company’s reputation? No, there is no reputational damage.
  3. Do we value the seeker and want to reward him? This researcher has already reported to us many times. However, we do not see a serious impact.

When a low-end vulnerability is reported out of reach, it is not technically immoral to refuse to reward hackers for their discoveries. The expectations that were set at the start of the process are fair. However, consider paying researchers a small bonus or sending a t-shirt. A little gratitude, especially for someone who has gone out of their way to help, goes a long way.

4.11 Fair judgment on premiums

It is easy to stray from the moral path as a program manager. Sometimes it can seem tempting to claim plausible deniability for a problem. If you use a managed program, the sorters know your environment only as well as possible from an external point of view. Bug bounty programs are only as effective as the engineers and managers who run the program. Similarly, programs cannot be as honest as the parties responsible for validating vulnerabilities.

There are many indiscriminate avenues of exploitation that can easily be denied or questionable from an attacker’s perspective, and it takes proper communication between researcher and engineer to confirm the existence of certain vulnerabilities.

If a researcher were to stumble upon a GitHub repository for an organization and find SQL credentials, that would be an extremely valuable find, especially if they could log in. In the event that the connection is limited to the internal network, it may not have a way to immediately control the server. Sometimes this may require an internal check. Verification may fall out of sight of the triage team and the searcher.

About the Author
John Jackson is a senior offensive security consultant and founder of Sakura Samurai 桜の侍, a hacking group dedicated to legal hacking. He is best known for his multiple contributions to CVE security and government/corporate research. Jackson has contributed to the threats and vulnerabilities space, disclosing several cyber vulnerability research and helping with resolution for the greater good. He continues to work on several projects and collaborates with other researchers to identify key cyber vulnerabilities.


About Author

Comments are closed.