Bug bounty programs have revolutionized the world of cybersecurity, enabling organizations to tap into the collective expertise of security researchers worldwide. As security researchers diligently identify and report vulnerabilities, they eagerly await the outcomes of their submissions. While many reports receive the coveted “resolved” status or a generous bounty, some find themselves closed out as “informative.”

In this blog, we will explore specific bug categories often resulting in reports being closed as ‘Informative’. This would definitely help anyone refine their submission and ensure the submission of high-quality, valid bugs.

Let’s get started.

1. Self-XSS: Let’s begin with the simplest. Normally, an XSS is rated Medium. But self-xss is an XSS that works for self. There won’t be a way to send this exploit to victims and attack them. Because a victim will have to copy-paste the payloads in their browser to get the trigger. Copy-pasting would be very unlikely in a real world and will always be closed as Informative.
2. Any other kind of self attacks: Like self-XSS, there can be self-htmli which would have no impact. A self-open-redirect is insignificant.
3. Insufficient session expiration: Have you ever seen situations where the session continues even after you log out or reset/change your password? Although it appears to be a legitimate problem, it is generally closed out as Informative. Because this category broadly falls under having physical access to victim’s device. So think through the impact and verify if it requires some highly unlikely scenario to happen.
4. Pre-account takeover: Ability to create an account with the victim’s email id and if the victim further uses sign-in-with-google, you should still be able to view the details of the account. That is basically a pre-account takeover. It occurs in the first place due to lack of email verification on signup. This issue generally gets closed out because we never know if the victim is actually going to sign-up ever. This has significantly high attack complexity and hence is informative.
5. Dmarc policy: Have you found an issue where you can send spoofed emails? Don’t submit it as it would be likely to be closed out as Informative. Reason? The spoofed emails will likely go into the spam folder and a victim will never see it, unless they explicitly visit the spam folder to click malicious content.
6. Cache poison with limited impact: Does the cache poisoning last, say, five seconds, after which it becomes impossible to poison the cache again with the same cache-buster? This is cache-poisoning with limited impact and may get closed out as Informative. Reason? Yes, there is unavailability. But, just for 5 seconds. The actual users won’t see or realize any difference in the application and hence no impact.
7. Exposed configuration files with no sensitive data: We often come across reports where the reports contain a link to any xyz config file. However, some of them end up as Informative as there is no evidence of sensitive information disclosure. When submitting a report, consider the impact it might have if it were exploited in the actual world. If none comes to mind, it is informative.
8. .git where no source code is exposed: Typically, we evaluate impact depending on the information that is exposed. This frequently occurs with git as well, where tools that are used to fetch data do not reveal any important information. Typically, this would result in an informative finding.
9. Debug mode enabled with no sensitive information disclosed: Generally findings where debug mode is enabled are treated as low. But if no sensitive information is disclosed within the page, this can be closed out as Informative finding as well.
10. Directory listing enabled with no sensitive information disclosed:A directory listing is not a bug unless it allows you to access sensitive files that you otherwise wouldn’t have been able to. A directory listing maybe a critical find when each file exposes user information and file name format is UUID.
    
    PS: If you are able to access files that are already public (for example .js, .css, logos), the finding would still be considered Informative.
11. Email enumeration: We see loads of submissions on email enumeration. But please note that email enumeration in general has no impact in bug-bounty would as you would have to conduct social engineering attacks to leverage it further. And as you know, social engineering is Out of Scope in almost all programs. However, many programs would reject it as Informative, while others could be interested in fixing the submission. So Feel free to submit these ones!
12. Non-Sensitive Information disclosure: Reports about information disclosure that doesn’t involve sensitive data, such as Google dorks revealing non-confidential pdf documents, are likely to be considered ‘Informative’ unless the content has significant potential for exploitation. A quick self-analysis of docs would really help in decreasing the Informative report count.
13. No password confirmation while deleting an account or changing mail: Similar to insufficient session expiration, issues where a password confirmation is missing while changing account details might require physical access to the victim’s device, leading to an ‘Informative’ classification.
14. Leaking API keys: API key found!!!!
    While finding API keys can be exciting, many API keys are meant to be public for proper functionality. Unauthorized usage is handled through backend restrictions, making these reports typically ‘Informative.’ To prove impact, demonstrate actions like viewing sensitive account details.
    To prove the impact, always leverage it to perform actions like the ability to view account details or data.
15. UI issues are not security bugs: Reports about non-security-related user interface (UI) issues, such as cosmetic glitches or rendering problems, are usually not eligible for bug bounties and might be classified as ‘Informative.’ Similarly, Functional bugs are not security bugs and must be submitted to programs via support portals.
16. XMLRPC.php enabled : DoS using XMLRPC is generally closed as the endpoint is supposed to reach to external resources. Also, the fact that this can lead to dos isnt something that programs can fix at their end.
17. WordPress user enumeration: Avoid submitting reports where the wordpress’s /users endpoint is publicly available. This is because the usernames are public by default and this is not considered sensitive information.
18. Token leak in the third party domains: A lot of researchers have mistaken this bug. Token leak in Referrer is valid when you visit the reset password URL and then click of a third-party domain present on the vulnerable application and then you observe that the referrer contains the link. However, when you click the reset password link, a lot of other requests are made. These are the analytics requests incorporated by the application to monitor certain things. These third-party apps already have access to the program’s sensitive data. So if you have found the token of these third-party, it is Informative.
19. OTP verification bypass by response manipulation on SIGN-UP: Reports of bypassing OTP verification during sign-up are usually out of scope due to the social engineering aspect, leading to a possible ‘Informative’ outcome.
20. Issues Identified by Vulnerability Scanners: Submissions, where vulnerability scanners detect issues, might result in an ‘Informative’ response, as programs expect manual analysis and proof of impact.
21. Path disclosure bugs: There will be lot of instances where some error page expose internal paths to unauthenticated users. If you see it practically, this has no impact as such. I agree to the fact that it can be chained with some other bug. So always consider submitting any chained issues for this case.
22. Rate Limiting Issues with Multiple Unknown Variables: Rate limiting issues are generally complex ones because in real world the exploitation solely relies upon brute-forcing. So when only the password is the unknown variable, the reports could still be accepted. But when the user name is also unknown, the attack complexity significantly increases. Therefore, instances where self-signup is not available, rate limiting issues would be closed out as Informative becasue you will never know what a successful response code / content length looks like.
23. Subdomain takeover where the subdomain ends on amazonaws.com : We often come across reports where subdomains end on amazonaws.com or similar. Please note that this is not considered a valid PoC. Since in the trail, we see some other page that is not program-owned, the PoC doesn’t appear legit when considering a real-world scenario.
24. Ability to purge varnish cache: We all run nuclei scans a lot! And nuclei has a template to identify instances where cache can be purged by anyone. However, this is an informative finding and not accepted generally. Because the ability to purge cache has no impact on the CIA matrix. The only impact will be a delay in the loading times of the resources. The loading times are generally so less that we wont even see a difference if the resources was fetched from the server or cache.
25. Dependency Confusion for the packages that are not listed in dependency or devdependency object in NPM : When you can takeover a package that is not lised in the dependency/ devdependency object, the package wont be installed automatically when the project setup is done. The vicitm will have to manually run npm install malicious-package. And the basis of this attack is social engineering meaning that the attacker has to lure the victim to run that command which is generally out of scope and gets closed out.

That was a lot right?!

The list doesn’t conclude here, but I trust that it provides a clear idea of what you should avoid submitting. Armed with this knowledge of the exclusions, you can now navigate the bug bounty landscape with greater precision, focusing on high-impact vulnerabilities that truly matter.

Thanks for reading! See you in the next one. Until then, happy hunting!