Github Authentication Bypass on Major CRM

This one's a genuinely tiny lab, which is honestly fitting given what it's actually teaching. Same Nagli-hosted Bug Bounty Masterclass series as the others, built around a real critical finding where credentials an employee accidentally committed to their own personal GitHub ended up handing over access to a major CRM's internal systems. Same situation as a couple of the earlier ones in this series though, no public writeup pointing at exactly which company or researcher found this specific instance, so I'm not going to pretend otherwise. What I can do instead, since the lab itself is so short, is actually slow down and talk through how hunters who specialize in exactly this category of bug approach it, because the thinking here matters a lot more than the three clicks it took to solve the lab itself.

The brief points you at a GitHub Enterprise instance and tells you straight out to search for the target's own training domain on GitHub and see what turns up. First thing it hands you, though, is a dead end dressed up as the objective.

A modal asking for a GitHub personal access token to validate and receive the flag, sitting right there in plain view before you've found anything at all. Worth noticing for a second rather than just closing it, this is the shape of the actual bug before you've even started looking, something that wants a token it has no business asking an outsider for. But it's not the way in on its own, it's just confirmation of what you're hunting for. Searching the raw domain straight up turned up nothing.

The actual move, and this is the part worth genuinely sitting with if you're newer to this specific hunting style, was searching with a leading dot in front of the domain instead of the bare domain itself, the way you'd write it if you were referencing a subdomain in a config file rather than linking to the homepage. That one character is the difference between finding nothing and finding an employee's personal "cool-stuff" repo with an .env file sitting in it, committed under their own GitHub handle rather than the company's org account.

That's genuinely the whole trick behind most of these findings. Companies watch their own GitHub organizations reasonably closely these days, secret scanning, branch protection, pre-commit hooks, the works. Almost nobody is watching an individual employee's personal side-project repos, the ones they push to at 11pm testing something unrelated to work entirely, except they copy-pasted a .env file from their actual work laptop to get a local script running and forgot what was sitting inside it. The org boundary that keeps a security team's dashboard clean doesn't extend to someone's own account.

Reading the current version of that .env file wasn't actually where the secret was anymore, people do eventually notice and scrub these things. But GitHub keeps full commit history by default, and plenty of people who delete a secret from the current file never think to purge it from history, or don't realize that's even a separate step. Checked the commit log.

And there it was, an earlier commit titled plainly "Create .env", the internal domain sitting right next to a GitHub token that had clearly been live at some point, GITHUB_TOKEN=ghp_..., committed, pushed, and left sitting in the repo's history for anyone who thought to check past commits rather than just the current file tree. Pulled it, dropped it into the validation modal from earlier, and that's the whole chain closed.

What's actually worth taking from this one isn't the steps, there were only three of them, it's the category of bug this represents and how differently it needs to be approached compared to most of what gets covered in these writeups. This isn't really a vulnerability in the traditional sense, there's no broken access control logic to reason about, no injection point, no flawed authentication flow on the target's own infrastructure at all. It's a leak, plain information a human being put somewhere it shouldn't have gone, and the entire "exploit" is just reading what's already sitting there in public.

That distinction changes how you actually hunt for this category specifically. Serious secret-hunters don't stop at scanning a company's own organization on GitHub, because that's exactly the part companies have gotten decent at monitoring. The real yield sits in personal accounts, specifically searching a target's domain in quotes, trying it both with and without a leading dot to catch subdomain references, checking variations like the internal product name alongside the domain, and critically, always checking commit history rather than just the files as they currently stand, since a scrubbed-looking repo can still have the original secret sitting two commits back. Tools like GitDorker, TruffleHog, and gitleaks exist specifically to automate scanning across exactly this surface at scale, running the same dork patterns you'd try by hand across hundreds of repos and commit histories at once, because doing it manually one dork at a time doesn't scale once you're actually hunting across a whole program rather than one lab.

And this isn't a theoretical category, it's one of the single highest-yield, lowest-effort bug classes in the entire industry, precisely because finding it takes almost no technical skill once you know where to look, just patience and the right search syntax. Uber's 2016 breach traced back to AWS credentials sitting in a public GitHub repo, 57 million users affected. Toyota had a customer-facing API key exposed the same way in 2022. Starbucks had a JumpCloud API key disclosed on HackerOne back in 2019, found sitting in a public repository the same way this lab's token was. Grab had both a Slack bot token and a Google API key pulled out of a public repo after a researcher went as far as reverse engineering a packaged Electron app to dig them out. None of these needed a zero-day. They needed someone patient enough to search, and to keep searching past the first dead end the way checking that single leading dot did here.

Which is really the whole lesson this tiny lab is actually trying to teach, underneath the three clicks it takes to solve it. The vulnerability was never really on the target's servers at all, it was in the gap between how carefully a company watches its own GitHub org and how carelessly it watches the people who work there.

Happy hunting, see you in the next scope :)