(Out of Scope) Vulnerabilities: Knowing What Not to Report in Bug Bounty Programs

However, in the world of security research and bug bounties, there are several common findings and false positives that are constantly being flagged by scanners, passive analysis tools, browser extensions, and command-line logs. It is incredibly useful to have a clear understanding of what vulnerabilities companies are not interested in. This knowledge allows you to both avoid wasting your time submitting doomed bug reports and configure your tools to report less noise to you in the first place, leading to a much more efficient workflow.

The core common theme for most of the vulnerabilities covered here is that they don’t have a clear, direct path to exploitation that affects a company or its users. They generally fall into categories where they either:

Only affect the attacker (the security researcher).
Require other (more serious) vulnerabilities to be present before they can be exploited.
In the case of leaked information, don’t give an attacker any actionable information to launch a meaningful attack.

This detailed article will cover the specific vulnerabilities that companies often exclude from bug bounty programs, including how they work and, critically, why they’re often not covered. It will also highlight some of the common themes in what makes a bug ineligible for reward consideration.

System Requirements for Analysis

Since this discussion largely focuses on vulnerabilities that should be excluded from a typical testing workflow, the only tool needed is a standard web browser. For example, a version like Chrome version 66.0.3359.139 will suffice for examining the concepts discussed.

DoS/DDoS – The Denial-of-Service Problem

Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) are familiar strains of cyberattack to anyone who follows security news. Flooding a target with traffic that is indistinguishable from a legitimate surge of visitors remains a popular method for either taking down or crippling a web property. This is especially potent when combined with amplification attacks (attacks that increase the volume of malicious traffic) caused by hijacking other servers, spoofing connected services, or taking advantage of an internal performance flaw or bottleneck.

In 2018, the software development platform GitHub was hit by what was, at the time, the largest DDoS attack ever recorded (a record that was quickly broken just five days later), clocking in at a saturation rate of about 1.3 TBps (terabytes per second). One reason the attackers were able to achieve such a high throughput was because they relied on commandeering unsecured Memcached database servers.

Memcached is a general-purpose distributed memory caching system, which stores data and objects in RAM to speed up dynamic web applications.

The attackers were able to spoof a query packet, making it look like the target server was asking for data from the Memcached server. In response, the Memcached server would then batter the target server with data up to 50,000 times the size of the spoofed request. This technique, known as a Memcached reflection attack, drastically amplifies the attack traffic. GitHub, in particular, has been repeatedly targeted, with this incident being just the latest in a sustained campaign against the site.

If you look at GitHub’s bug bounty program, you’ll notice they call out DDoS attacks specifically—stating clearly that they do not allow them:

Don’t perform any attack that could harm the reliability/integrity of our services or data. DDoS/spam attacks are not allowed. (emphasis theirs)

Why DoS/DDoS is Typically Out-of-Scope

The reason DoS/DDoS attacks are typically out-of-scope is simple: they are often not the result of anything the victim did wrong. The company didn’t miscode the application or leave a critical application-layer vector open. Defending against these attacks requires an entire proactive security architecture, which involves redistributing the load across different networks and intelligently throttling/isolating malicious sources of traffic—it’s a network defense problem, not an application vulnerability problem.

The exception is when a DoS/DDoS attack is made more effective because it can leverage a specific security flaw that exists on the victim’s network. If, as a security researcher, you come across, for example, an unsecured NTP server (Network Time Protocol) that could be hijacked to amplify a DDoS attack, you should certainly report it. This would be a vulnerability that could be used to threaten the company’s network or another bystander’s network.

Important Note: You should not try to validate any vulnerabilities like this by leveraging them for increased bot traffic, even if you believe the traffic falls below the threshold of something that could damage the target’s infrastructure. The fact that DDoS prohibitions are so common is a clear sign of how seriously they are taken by bounty program operators.

Sandboxed and Self-XSS – Low-Threat Cross-Site Scripting Varieties

Self-XSS (Self-Cross-Site Scripting) is a variety of XSS that relies heavily on social engineering, which is the primary reason it is excluded from most bug bounty programs. Sandboxed XSS, a similar term for a related strain, is typically used to describe an XSS vulnerability that happens on a machine that is isolated from sensitive user data or operations. Since Self-XSS refers to the specific phenomenon of executing code within your own browser environment to make yourself vulnerable to an XSS attack, it also means that your XSS bug is isolated in terms of what information it can access.

For Self-XSS to take place, the attacker must manipulate the victim into executing the malicious code within their own browser context. This manual execution by the victim is what makes them susceptible to further exploitation by the attacker.

A Simple Self-XSS Scenario

A simple example of self-XSS in action would be as follows:

An attacker advertises a “hacking-kit-in-a-box”—something like, “H4x0rs l18e 1337!” (a common piece of jargon known as leetspeak, meant to appeal to a gullible user). The advertisement tells the victim that all they have to do is copy a specific code snippet and paste it into the developer console of their browser.
The victim, perhaps beautifully gullible, happily copies the code and pastes it into their console, imagining the digital terror of their wrath upon the web.
Instead of hacking someone else, the code they pasted into their console just exposed them to hackers. Any sensitive session cookies or other information available in their browser is now the property of a shadowy cabal of cyber-anarchists.

For an example of this in action, check out a historical write-up of a very similar scam that circulated on Facebook a few years ago. The scam also encouraged users to follow directions to hack any Facebook account, also asking them to copy and execute code in their developer console, and also resulted in the victim being hacked when they actually complied.

Further Reading Example: Facebook Self-XSS Scam: https://www.tomsguide.com/us/facebook-self-xss,news-19224.html

Because this particular bug, like so many of these un-rewardable, almost-vulnerabilities, requires either action outside the application context (such as a phone support worker initiating a change under the influence of social engineering) or other application-based vulnerabilities to be present and ripe for exploitation, it falls outside the scope of most bug bounty programs and is not eligible for a reward.

Even as companies write guides and issue warnings to avoid these kinds of scams, they are limited in terms of the preventative action they can take: there’s only so many ways to secure a house if the owner is intent on giving away their keys by executing malicious code themselves.

Non-Critical Data Leaks – What Companies Don’t Care About

Previously, during discussions about access control, security by obscurity, and data leakage, the different types of data that companies were not interested in rewarding were briefly covered. This included information like usernames, descriptive-but-not-sensitive error messages, different kinds of error codes, and so on.

Here are some other, specific examples of information that security researchers often report, but that companies very rarely pay for.

Emails

Emails are a piece of information many website operators try to deny to bots and automated agents crawling their site. One typical strategy is encoding email links as HTML entities to make them harder to collect. This means an email such as nessus@generalproducts.biz can be hidden as the following entity code:

nessus@generalproducts.biz

Unless a crawler is specifically expecting to detect and decode entities as part of its scraping process, this little obfuscation (the practice of making something obscure or unintelligible) trick can be surprisingly effective.

But if an email is exposed on a company site, it is usually meant to be a public-facing handle. Submitting a bug report about an exposed email like support@company.com or even reporting that you’ve deduced the employee email naming convention (e.g., lastname.firstname@company.com) does not meet the standard for a payout. There are too many extra steps beyond simply enumerating a company’s email username registry before the disclosure becomes an actual, high-impact vulnerability.

HTTP Request Banners

HTTP banners are an integral part of the protocol that stitches the entire web together. On common services, they can include encoding data, device information, general information about the nature of the HTTP request, and other data, which might be privy to many different types of devices.

All of that is to be expected as part of the service and does not constitute a leaked source of sensitive system information. This includes both information contained in the present banners as well as the “missing” security banners that some tools flag.

Known Public Files

This is simple: some files are designed to be accessible! Reporting on the configuration or availability of files such as robots.txt, wp-uploads, or sitemap.xml is not going to merit a payout—or probably even a response—because these files are intended to be public-facing.

Missing HttpOnly Cookie Flags

HttpOnly cookie flags are anti-XSS prevention devices. If a server-side process flags a cookie as HttpOnly, it cannot be accessed client-side (when the browser attempts to read the cookie using client-side script, it just returns an empty string). Every major browser supports HttpOnly cookies. But whatever their value, they are a safeguard, and their absence does not directly imply a vulnerability. If there’s no additional Cross-Site Scripting (XSS) vulnerability present, there is no issue.

Other Common No-Payout Vulnerabilities

In addition to the larger categories of bugs discussed that typically don’t merit a payout, there are also a lot of one-offs and miscellaneous would-be vulnerabilities you should try to avoid submitting. Keep in mind that these are in addition to previously-submitted vulnerabilities, which are ineligible for payout everywhere.

Vulnerability Category	Why It’s Often Out-of-Scope
Weak or Easily Bypassed CAPTCHAs	CAPTCHA (and their successor, reCAPTCHAs) are Google-administered Turing tests designed to block bot form submission spam. Because they represent a third-party service whose security posture is managed by an outside company, most companies that host them won’t reward any CAPTCHA-related bugs.
The HTTP OPTIONS Method Enabled	The `OPTIONS` method is a diagnostic method that can potentially enable debugging and stack trace data. While it increases the attack surface and should be avoided by developers, having `OPTIONS` enabled is not a vulnerability per se. Like other wannabe bugs, it requires too many extra steps in order to demonstrate a valid attack scenario.
BEAST (CVE-2011-3389) and Other SSL-Based Attacks	The Browser Exploit Against SSL/TLS (BEAST) attack assumes a fair degree of client-side control, typically requiring a Man-in-The-Middle (MiTM) attack to inject packets into the browser’s TLS stream. As the security product company Acunetix notes, if an attacker has reasonable control of the victim’s browser, it’s more probable that an easier attack vector is chosen. The vulnerability is the responsibility of the underlying tech (TLS/SSL connection) and requires several other vulnerabilities to be exploited, making it not the primary concern.
Brute Forcing Authentication Systems	If an authentication system (a GUI form, an API request, or any other implementation) doesn’t lock a user out after failed login attempts, it’s open to brute-forcing. However, the resources involved in brute-forcing and the high level of noise it would make to any observing system engineer mean that, by itself, this ability is not a compelling foundation for a severe attack scenario. Additionally, testing this involves making a brute force attack, which can damage the target’s infrastructure.
CSRF Logout	The ability for a cross-site request to forcefully log a user out (Cross-Site Request Forgery or CSRF) is traditionally considered a security non-issue and is still not rewarded by many programs. Although organizations like Detectify Labs are reevaluating this, it often requires several extra steps to become a true vulnerability with a credible attack scenario, and is therefore not a priority.
Anonymous Form CSRF	Another common CSRF-related vulnerability that doesn’t often receive a payout is an anonymous form (like “Contact Us”) that is susceptible to CSRF. There is no relevant attack scenario that can be derived from it. Even if an attacker submits the form with a different email address or message, it’s not clear what damage that would do, as anonymous forms are isolated from important functions.
Clickjacking and Clickjacking-Enabled Attacks	Clickjacking is when an attacker hides a malicious link in a transparent or obscured link under a legitimate, safe button, tricking users into following the black hat URL. It’s omitted because it either requires the company itself to use dark patterns (malicious user interface techniques, which they would never admit to) or the user to modify code on their own machine.
Physical Testing Findings	Firms interested in rigorous security may hire a researcher to test the physical security perimeter of their data center (most common in industries with strong compliance policies like PCI compliance). However, any finding that consists of a researcher sneaking in through a company break room and messing with an unlocked laptop is out-of-scope and potentially legally actionable for a typical remote bug bounty program.
Outdated Browsers	Finding a vulnerability that depends on an outdated browser (especially one older than IE 8) for an attack vector will not be rewarded. Outdated browsers are not receiving security updates, and it makes no sense for a company to carve out exceptions to an applicable end-of-life policy.
Server Information	Discovering the type of server or hosting service is a valuable part of the discovery phase in any engagement, but it is not a bug. Obfuscation is nice, but the basic public server data itself doesn’t suggest a compelling attack chain worthy of a payout.
Rate-Limiting	Rate-limiting (protecting a server from getting overloaded by selectively throttling requests) is a feature, not a bug. It prevents the server from being hosed and is explicitly excluded as an out-of-scope vulnerability.

This example of Anonymous Form CSRF drives home a general point that is essential to remember: Attack scenarios modeling a critical attack are essential to making sure that your submission is rewarded.

Summary and Key Takeaways

This article has covered different types of security flaws that typically don’t rise to the level of a profitable vulnerability in the context of a bug bounty program. These include issues like DoS/DDoS, Self-XSS, and other types of attacks, as well as information that is commonly reported by scanners and penetration testing tools but that doesn’t necessarily interest bug bounty program operators.

Along with various miscellaneous out-of-scope vulnerabilities, the analysis of the common features that link these bugs together reveals a clear pattern: they are not high-impact on their own.

They are often excluded because:

They require other, more serious exploits to be present.
They have limited reach, often only affecting the attacker.
They require social engineering or attacks on third-party services.

By understanding not only what bugs don’t get rewarded but why they aren’t valuable, you can now tune your own workflow to lower the noise in your reporting. This will help you build a penetration testing regimen that cuts down on time-wasting dead ends and focuses on the vulnerabilities that truly matter to the company and their users.

Questions and Further Analysis

1. Why are DoS/DDoS attacks typically out-of-scope?

Answer: Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks are typically out-of-scope because they are considered an availability issue, not a confidentiality or integrity issue.

The CIA Triad: Security is often measured by the CIA triad:
- Confidentiality: Keeping data secret.
- Integrity: Preventing unauthorized data modification.
- Availability: Ensuring systems are accessible.
Bug Bounty Focus: Most bug bounties focus on flaws that compromise confidentiality (e.g., data theft) or integrity (e.g., taking over an account, changing data). While availability is critical, DoS attacks are often achieved through sheer brute force (flooding a server with traffic) rather than a unique, exploitable software “bug.” Defending against them is more about infrastructure scaling, rate limiting, and DDoS mitigation services (like Cloudflare) than fixing a specific line of code.

Scenario where a DoS-related bug would merit a reward:

If a researcher finds a logic flaw that causes a service to crash or become unresponsive with a single, low-resource request, it would often be in-scope. This is sometimes called “Low-Rate Denial of Service.”

Example: Sending a specially crafted API request that triggers an infinite loop on the server, consuming 100% CPU with a single HTTP packet. This demonstrates a vulnerability in the application’s logic, not just network-level flooding.

2. What is Self-XSS? Why does it not usually merit an award?

Answer: Self-XSS (Cross-Site Scripting) is a vulnerability where the payload (the malicious script) can only be executed by the user themselves. It typically requires the user to paste malicious code into their browser’s developer console.

It’s not rewarded because:

No Security Impact: It does not allow an attacker to compromise another user’s account or data. The victim is only “attacking” themselves.
No Privilege Escalation: It cannot be used to escalate privileges or perform actions the user couldn’t already do manually.
Social Engineering, Not a Technical Flaw: Exploiting it relies entirely on tricking the user, which is a human problem, not a technical software vulnerability. Bug bounties are for finding technical flaws in the application.

3. What’s the potential damage of leaving HTTP’s OPTIONS method enabled?

Answer: By itself, the OPTIONS method is harmless and is part of the HTTP standard for CORS (Cross-Origin Resource Sharing) preflight requests. The damage is in information disclosure.

Reconnaissance: An attacker can use the OPTIONS method to “fingerprint” the server and discover which other HTTP methods are enabled (e.g., GET, POST, PUT, DELETE, TRACE).
Attack Planning: Finding that powerful methods like PUT or DELETE are enabled gives an attacker a clear direction for further attacks. For example, if PUT is allowed, they might try to upload a malicious file.

The primary risk is leaking information that makes it easier for an attacker to plan a more serious attack.

4. Why don’t BEAST and other SSL vulnerabilities typically qualify for bug bounty programs?

Answer: Vulnerabilities like BEAST (Browser Exploit Against SSL/TLS) are usually out-of-scope for a few key reasons:

Client-Side vs. Server-Side: BEAST is primarily a client-side attack. It exploits a weakness in the client’s browser (or TLS library), not a flaw in the configuration or code of the target server.
Deprecated and Patched: BEAST is an old attack (from 2011) against TLS 1.0. Modern servers and browsers have long since mitigated it by supporting newer protocols (TLS 1.2, 1.3) and using different cipher modes.
Infrastructure-Level Issues: These types of vulnerabilities are often related to the underlying web server (Apache, Nginx) or protocol implementation, not the unique application code that bug bounties are designed to protect. Program owners expect teams to keep their server TLS configurations up-to-date as a matter of standard hygiene.

5. What is Clickjacking?

Answer: Clickjacking (UI Redress Attack) is an attack that tricks a user into clicking something different from what they perceive. An attacker uses transparent or opaque layers to overlay a malicious button or link on top of a legitimate, hidden webpage.

How it works: The victim sees a harmless-looking page (e.g., a game), but an invisible iframe containing their email account or bank website is positioned directly underneath the “Play” button. When they click “Play,” they are actually clicking the “Delete All Emails” or “Confirm Transfer” button on the hidden page.

6. What is Physical Testing?

Answer: In the context of bug bounties, physical testing refers to attempting to find security vulnerabilities through direct, physical interaction with a company’s assets.

This includes:

Attempting to gain unauthorized physical access to corporate offices or data centers.
“Shoulder surfing” (looking over someone’s shoulder for passwords).
Plugging devices into corporate network jacks.
Dumpster diving for sensitive documents.

This is almost always strictly out-of-scope for bug bounty programs due to the high legal and safety risks involved.

7. What makes a CSRF vulnerability out-of-scope?

Answer: Cross-Site Request Forgery (CSRF) forces a logged-in user to execute an unwanted action on a web application. Common reasons it might be considered out-of-scope:

Lack of Security Impact: The action has no meaningful security consequence (e.g., changing your own profile theme from light to dark mode).
Presence of Standard Mitigations: The application already uses anti-CSRF tokens, but the researcher found a way to bypass them. If the bypass is valid, it’s in-scope, but if the tokens are correctly implemented and unbypassable, there is no vulnerability.
Self-Exploitation: The attack can only be performed against the attacker’s own account.
Requires Extensive User Interaction: The exploit requires the victim to perform a complex, unlikely series of steps.

8. What are Dark Patterns?

Answer: As you defined, dark patterns are user interface and user experience design choices that deliberately trick or manipulate users into taking actions they might not otherwise take.

Examples:

Confirmshaming: Using guilt to prevent a user from taking an action (“No thanks, I don’t want to save money”).
Sneak into Basket: Adding additional products to your cart without your clear consent.
Roach Motel: Making it very easy to sign up for a service but extremely difficult to cancel it.
Privacy Zuckering: Tricking you into sharing more personal data than you intended.

While unethical, dark patterns are generally a business practice or design ethics issue, not a security vulnerability, and are therefore out-of-scope for bug bounties.

9. Why aren’t brute force-related vulnerabilities rewarded?

Answer: Brute force attacks (e.g., repeatedly trying passwords) are not considered a software vulnerability but rather a configuration or design flaw in the security controls.

Focus on Technical Flaws: Like DoS, a successful brute-force attack is often a matter of “brute force” rather than exploiting a technical weakness in the code itself. Program owners expect basic security hygiene like rate limiting to be in place.

Mitigation is Standard: The defense against brute-forcing is well-known and standard: implement strong rate limiting and account lockout policies.

Lack of Novelty: Finding that a login endpoint doesn’t have rate limiting doesn’t demonstrate a unique “bug”; it demonstrates a missing security control. Bug bounty programs are looking for novel flaws in the application logic.

Trending Top-Read Articles

The Mathematical Foundations of Viral Propagation: A Forensic Analysis of Gleissner’s 1989 Theory

A Computational Model of Computer Virus Propagation: A 2026 Forensic Retrospective

A Comprehensive Program for Preventing and Detecting Computer Viruses: A 2026 Forensic Retrospective on the IRS Security Crisis of 2000

Trending Tags