GitHub, The Goldmine for P1s and P2s - Sensitive Information Exposure via GitHub by a Company Employee

This is the writeup for a recent bug I found which leaked PostgreSQL credentials using GitHub. This is a hands on guide, which you can also use while enumerating your target.

GitHub, The Goldmine for P1s and P2s - Sensitive Information Exposure via GitHub by a Company Employee

GitHub Leaks - We have seen a lot of people in the bug bounty community tweeting about their GitHub Findings and getting paid out four figs for their reports. That's awesome and Kudos to them for that but, if we take a step back and take a look, there aren't many blogs on GitHub Findings. Don't get me wrong, there are a few blogs and they are great too, but unfortunately not enough. We need more. In this write-up, I will tell you EVERYTHING that led me to finding a GitHub Leak that was triaged and paid out as a High/P2 Severity bug. Keep reading.

To find leaks on GitHub like Credentials, Keys, Secrets, you have to put in the time. It can take hours to find valid credentials. This means that you will need patience more than anything else to find those high-paying juicy creds.

How I started my GitHub Recon

Like any other day, wanting to work on my target, grinding myself to find a bug, I opened my PC and checked my Google Keep. It said "GitHub Day", well this meant I had to start with the GitHub Recon on my target. I thought this was gonna be a very boring day but little did I know that I would end up with a really awesome bug. Anyways, I went over to and started searching for domain specific things with basic GitHub Dorks like:

  • "" subdomains
  • "" language:python
  • "" NOT
  • "" NOT staging language:xml
  • "" password
  • "" secret
  • "" token
  • "" api_key

And a few more, you get the idea. I got a few results, one of them caught my eye. I saw a password in a file. The filetype was JSON and the contents looked like this:

	"host": "",
	"port": "2083",
	"cpanel_username": targetcpanel,


I got excited and a little bit out of control because it took me a lot of time to find this. I navigated to and to my disappointment, the port was closed :(

I went back to the file and saw that the name of the file contained "test" in it and at the end of the file, the developer had commented out "Test Data". This led to frustration and I ended up closing my PC and watching Netflix.

Back on the Grind

After some time, when I was feeling motivated again, I launched GitHub once again and this time I did not want to give up. I thought of removing certain keywords from the search results so that I only find the results which are not False Positives and not Test Data.

For this, I used the following GitHub Dork: password NOT test NOT sandbox NOT staging NOT development NOT docker NOT help NOT language:java

Now, from the above Dork, as expected, I found all the good results, test data and other data that I didn't want was now filtered out and I could finally focus on the important stuff. I had a good feeling about this. One thing to note here for me was that I found a lot of bash results. Files ending with .sh. I then  appended this into my dork:


Now, I was only looking at bash code. I started searching for keywords like secret, key, token, etc, but I couldn't find any good results. I had the program policy open in another tab and I was reading the little information that is sometimes given about the in-scope domains. Next to the domain that I was searching for, I saw the keyword PostgreSQL written. I thought it would be a good addition to my search query and I searched for it. I got a lot of results, I clicked on the Sort button, and then I clicked on Recently indexed. This shows me the latest index results. On the top of the page, I saw a bash file which contained some random bash and I thought it was nothing interesting but when I took a closer look at it, I saw that I had found PostgreSQL credentials for a host!

Here is the screenshot:

The credentials were in the URL and they were very easy to spot. The format in which they were present looked like this:


This time, I tried to stay calm (it's hard!) and find out if these were actually valid credentials or not. This is a GitHub Tip that I would like to share. Whenever you find something that may look like credentials, always check if these were published to GitHub by someone related to the Target Company or were published by some random person on the Internet.

The way you do this is, by visiting the profile of the person who has leaked the credentials and copy their name and search for it on LinkedIn. I did this and found out that this guy is a former Senior Software Engineer at the Target Company.

I tried to login using the credentials, port and the host, but I couldn't because the port was filtered or closed. Because of this, I tried to send the report in as a Medium severity bug but I guess I mis-clicked and it got set to High. The next week, I woke up and checked my phone, I saw that the report got triaged, It didn't impress me much because I had started getting a lot triages and I was expecting this bug to get triaged so I went over to my PC and opened the report to acknowledge the triage and found out that I was paid out for the bug as well! Yes, as a High/P2!

I was shocked because I didn't expect this to get triaged as a High because I wasn't able to gain access with the credentials.
The team said that they are considering this because they open this port monthly for maintenance and other reasons.
Then this would become exploitable and pose a real security risk.


  • Search the code on GitHub related to your target using normal, basic search queries at first to get a feel of the code there is present about your target. Slowly progress towards more complex and specific queries.
  • Now, you will be able to make out which results you want and which are useless. For example, you can remove the domain from the results using the NOT query in your search. The things you filter out depend on your target. Remember, Nobody can give you a crafted GitHub Dork which when pasted will give you valid credentials. It all depends on your Target's code. Remove the useless stuff ;)
  • Don't forget to remove keywords like test, docker, staging, etc. to reduce false positives and false leads.
  • If you think you have found valid credentials, ALWAYS find out if the code published on GitHub was published by someone related to the Organization or not, usually these are Software Developers. To do this, make use of LinkedIn.
  • Finally, GitHub Recon is hard. There is a lot on GitHub. It takes a lot of time to actually do what you want and navigate this Gold mine in your favour. You have to make the effort and put the hours in to see results.
  • PATIENCE IS KEY. If you fall down, stand right back up.

Resources, Credits and Shout-outs

  • Youtube Video uploaded by @BugCrowd and made by Th3G3nt3lman is a great resource for beginners to learn GitHub Recon and find leaks.
  • Join my Discord Server by clicking here.
  • Subscribe to @securibee's newsletter, @Intigriti's bug bytes to stay up-to-date with the resources.
  • Not exactly a resource but I wanted to share with the community something else that I have been doing on the side, I am trying to start my own Online Print-On Demand Business using Teespring.

Thanks for Reading this, hope you enjoyed my blog :)
If you have any questions regarding this, feel free to shoot me a Dm on Twitter, or Discord!
Many more to come xD

Until next time!


NOTE: The awesome artwork used in this article was created by Cecilio Ruiz.