GitHub is a platform where millions of devs store and share code. And at this very moment, as I speak, someone just published something they shouldn't have . A payment key, an AI model access, or a database password, completely open for anyone to see.
Hold on, you might be thinking I'm going to talk about forgotten dot-env files that people leak. And yes, I will talk about that, but also show in practice just how dangerous this is. In this video, I built a bot that finds these secrets, and it gave me access to systems with corporate financial data, user IDs, databases with thousands of people, and even Mercado Pago accounts.
All because of some secrets forgotten on GitHub. But first, if you don't know what a secret is, think of it this way: when your system needs to send an email, process a payment, or call an AI, it has to talk to another system. And to prove it's the one calling, it needs a key; in this case, a secret—the secret is the access.
And that's the catch. Many people put it right in the middle of their code, and at first, there’s no problem. Except that anyone with the code also has access to that secret.
That’s why the most common practice is to put these keys in a separate file, like a . env. Then you configure the project to ignore that file when pushing to GitHub, so it stays only on your machine.
But guess what? Many people forget to configure that part and end up uploading the entire . env file to a public repository , or even hardcoding the secret.
And today, we’re going to try to find them. But there’s a problem. A public repository can have thousands of files and a million lines of code.
How do you find a lost key in the middle of all that? Well, we have to understand that various services generate keys in a specific format. Anthropic starts with "sk-," AWS starts with "AKIA," Mercado Pago with "APP_USR," even database URLs have a format.
But not every key has such an obvious look. Several systems use generic tokens, which are basically a bunch of random letters and numbers with no prefix, but for now, we can recognize most major keys just by looking at them. So the most obvious idea is to use GitHub's own search.
You just throw in a key prefix and see what appears. And, in fact, it works. Searching for "sk_live," which is for Stripe, reveals a key right in someone's code.
But doing this manually isn't very efficient, so let's automate it. GitHub has an API route, search code, that searches for code. I call it by sending the key patterns I want, and it returns the files that matched.
Then , for each file, a script goes into it and uses regex to extract the exact key . And finally, it takes that key and tests it directly against the provider to see if it's alive, meaning if it's still working. And the best part is that there's already a program that does exactly this flow.
It's called Key Hunter. I used it as a base and made some modifications. I added more providers, added a cache, a database to save what it finds, and let it run for a good while.
And I think you know that it took a while. And after two days running, we got 14,000 secrets, of which 900 are valid. They range from MongoDB, Resend, to Telegram, but the most important thing here are the valid secrets that were tested against the provider and actually work.
And you can see there’s a lot of Mercado Pago, not just test credentials, but also quite a few production ones. But there is a problem I haven't mentioned yet. When you search for something on GitHub , it doesn't go out and read every repository in the world at that moment.
It has an index, but this index is not instantaneous. So when someone creates a new repository or makes a commit, it takes a while to be indexed. There are millions of new repositories every day.
The indexer can't keep up with all of this in real time. So it prioritizes. And guess what doesn't get indexed?
Exactly the small, single-person projects, which are precisely the ones that leak secrets. And besides that, GitHub search returns a maximum of 1,000 results per search, even if there are 50,000. And they are sorted by relevance; there is no way to sort by date.
So, if I want to find what just leaked, which are the ones most likely to have active secrets, searching by prefix is not the best way. So, instead of searching for the key itself, let's look for a specific type of repository. But what do you mean by type of repository?
Which projects have secrets that are worth it? Things like Pix/ payment, Pix QR code, or Postback URL are pieces of gateway integration code. It is highly likely that whoever has this in their code is dealing with real payment systems.
But how am I going to find a secret in the middle of the code ? It can be written anywhere: in a . env file, hardcoded into the code, or even in an old commit that the person thought they had deleted.
TruffleHog is a tool made exactly for this. It clones the repository, goes through all the files and commit histories since the beginning of the project. And after a few hours of running, we got 294,000 secrets in over 1,000 repositories.
Now , let's see what we can do with all of this. But before we continue, if you want to become an ethical hacker and have certifications that really open doors, Solid One has the right path for you. There are over 600 hours of content where you'll see everything from the basics, web development, pentesting in different environments, Wi-Fi security, AI exploitation, and much more.
And by signing up, you become part of Solid Hunter, which is the talent pool that connects hackers to exclusive job openings and companies worldwide. Link in the first pinned comment. Going through there, you get a discount on your subscription.
Let's start by looking for database URLs. Filtering by MongoDB, several results appear, and the very first one is from an active repository that was updated 11 hours ago. Let's try to connect to the database, and I'll use MongoDB Compass for this.
And trying to connect , it worked. There are quite a few different tables, from email templates, push notifications, and most importantly, the users. In this system, there are a little over 100 users, and luckily, the password isn't in plain text.
And do you know the coolest part? The database wasn't leaked in the code, in a . env file, or anything like that.
It was a text file that was apparently for testing. Taking the next URL from our list, we can see that it's from a repository from three months ago. And if we try to connect, it also works.
And this time, there's a table for payment gateway settings, transactions, and also the list of users. There are over 3,200 with name, email, CPF, and the password is in SHA-256. The leak was in a file called appsettings.
json. There were also access tokens for Facebook, Amazon S3, and even the guy's email password was there. I even found the deployment URL, but when I tried to access it, it was already offline.
Another DB that was also open belonged to a Discord bot that was apparently quite popular. According to the "about" section, it had over 400 bots online. The last change was three months ago, and unlike the others, I didn't find anything significant here.
Just some bot settings that aren't a problem. But get ready, because this next one is absurd. A Postgres one and an active repository.
The last change was five days ago. And again, the secret wasn't leaked in a . ENV file, but inside a Markdown file in a troubleshooting guide from 9 months ago.
And that same file includes a link to the project. So this time, we can actually access the site. Taking the credentials and trying to log into the database.
You guys already know it works. There are many tables, from sessions, legal, accounting documents, but most importantly, the users. There are 12 registered, and ID 1 is the admin.
The password is in bcrypt, so there's no way to know the original, but we can overwrite it. From the rest, we can see it uses 10 rounds. So let's generate a 10-round password too.
Then just copy the resulting hash and overwrite it in the table. And if we try to log in with the new password, we can access his system. "Ah, but why access the site if you have access to the database?
" I don't know either, it just seems cooler . Apparently, it's an internal system for his company. It has a dashboard with event notifications, a financial page where revenue reaches almost 100,000 Reais per month, and a list of receipts showing the person responsible , the amount, and description, all wide open.
And if you think it's just some throwaway system that isn't used for anything, I found a documents page that I clearly can't show here. And just to keep him on his toes, I changed the rest of his password to a warning. And looking at it now in editing, I don't think the warning I gave was very useful.
Well, there was nothing else interesting in the database, but have you ever thought about having infinite keys? Some of the secrets caught were for Gemini. And if we test by sending a request to their API, prompting it about the dangers of committing secrets to a public repository, we get an answer.
Of course, not all of them worked. Many were invalid or expired. In the end, there were about 10 valid ones.
And regarding DeepSeek, the story is completely different. As I was testing them manually, all of them were returning "insufficient balance. " And seriously, it was really all of them.
I even made a script that tests all the keys found, and every single one, without exception, returned that same error. And that’s no coincidence. Right now, there are many people running these bots to try and collect API keys and credentials, which are among the most sought-after.
Well, enough about databases, let's talk about the real danger: payment systems, and specifically one of the most famous in Brazil, Mercado Pago. The bot captured dozens of production credentials in several different codes. And if we try to access it by sending a request to/users/me, which identifies who I am, we find some interesting results: email, tax ID, full name, and address of several different users.
And if you haven't grasped the danger of all this yet, this isn't just about a few leaked emails, no. People can find keys to tax systems that issue invoices , documents of various people who will never know they were leaked. Everything left in a repository that anyone can download in two clicks.
Just to be clear, I did absolutely nothing with any of the credentials that appeared. The goal of this video is to show you that this leaking of secrets is not just a problem for big companies. That personal app you're building, a bot on Telegram, on Discord, anything.
It could have a gateway key, a database with your information completely open that you didn't worry about. What I did here in this video is nothing special, and as I said, there are many people doing this right now. But unlike me, they are not doing this to warn anyone.
And that's it, I hope you enjoyed the video. Follow me on other social media and don't forget to like and subscribe to the channel. Thanks.
M.
