GitHub Dorking for Bug Bounty: How Vexta Hunts Leaked Secrets and Endpoints

What is GitHub dorking for bug bounty hunting, and why treat source code hosting as a recon target? GitHub dorking means running targeted code searches across a platform's own search API to surface secrets, configuration files, or internal endpoints that a developer committed to a public repository by mistake. Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, automates this as part of its reconnaissance engine, running GitHub REST API code searches with configurable dork patterns and extending the same search to GitLab when a GitLab key is supplied.

What does Vexta actually search for on GitHub?

Vexta's GitHub dorking runs REST API code searches aimed at three categories of exposure: leaked secrets, exposed configuration files, and internal endpoint references that were never meant to be public. The dork patterns are configurable, and by default the engine auto-searches for terms like password, api_key, and JWT, alongside common configuration file names, the kind of strings that show up when a developer commits a.env file, hardcodes a credential during testing, or leaves a debug config in a branch that gets pushed by accident.

Because this runs against GitHub's own search API rather than scraping the site, it returns the kind of structured, code-aware results a plain web search would miss: matches scoped to file content, not just file names, across every public repository the API can see, not just the ones linked from the target's own site.

Does the same search work on GitLab?

Yes. When a GitLab key is supplied, Vexta runs the same dorking approach against GitLab's own search API, so a target whose engineering team hosts some or all of its code on GitLab instead of GitHub still gets the same category of coverage: secrets, exposed configuration, and leaked endpoint references. This matters because plenty of organizations split their code between the two platforms, or migrated from one to the other without fully cleaning up the platform they left behind.

Why does this belong in passive recon rather than active scanning?

Querying a code-hosting platform's own search API for text a developer already committed publicly never sends a single request to the target's own infrastructure. That puts GitHub and GitLab dorking in the same category as certificate transparency logs or DNS history: it draws on data a third party already indexed, so it carries none of the rate-limit or detection risk that active probing against the target itself does. For a hunter working a program with strict active-testing rules, that makes code search one of the highest-value places to spend early recon time, since a real finding can surface before any request has touched the program's own systems.

It also tends to surface a different class of finding than infrastructure recon does. Subdomain enumeration and passive DNS reveal what exists; code search reveals what a specific developer, on a specific day, accidentally exposed. A leaked API key or a hardcoded internal endpoint often points directly at a system that infrastructure recon alone would never have surfaced, because it was never linked from anything public in the first place.

How does dorking fit alongside the rest of Vexta's recon?

GitHub and GitLab dorking sits inside the same reconnaissance engine that runs Vexta's passive OSINT collection and subdomain enumeration, not as a bolted-on side tool. A subdomain surfaced through certificate transparency logs or a passive DNS provider becomes far more useful once code search turns up an internal API path or a staging credential referencing that same host, and an endpoint pulled from a leaked configuration file is often exactly the kind of asset a wordlist-based brute-force pass would never guess on its own. Run together, the two approaches cover different blind spots: infrastructure recon finds what is reachable, and code search finds what someone specifically, if accidentally, wrote down.

That overlap is also why the dork patterns are configurable rather than fixed. A hunter working a target built on a specific stack, a particular cloud provider's SDK, an internal tool with a known naming convention, can tune the search terms toward the credential and config formats that stack is likely to leak, rather than relying solely on generic terms like password or api_key.

What should a hunter do with a leaked secret once it's found?

A secret or endpoint surfaced through code search still needs the same verification discipline as any other finding before it goes anywhere near a report: confirming it is current rather than a rotated or already-revoked credential, confirming it is genuinely in the program's stated scope, and reporting it through the program's own disclosure channel rather than testing it further without authorization. Vexta's job here is to surface the lead cheaply and quietly; deciding what to do with a live credential inside an authorized engagement is still a human judgment call, and one that should default to responsible disclosure every time.

That discipline matters more with leaked secrets than with most other finding types, because a live credential can do real damage if it's mishandled even inside an authorized test. The safest path is almost always to note where the secret was found, confirm just enough to establish it is real and current, and hand it to the program through its disclosure process rather than using it to pivot further on your own. A responsible write-up that shows exactly where the secret was committed, and nothing more, tends to land better with a triager than one built around what an unrestrained hunter could technically do with it.

Key takeaways