How a Single Leaked Client Secret Exposed a Private GitHub Repo

During a recent assessment, I turned a single hardcoded secret found in a public JavaScript bundle into administrative access to the target's private GitHub repository. The chain took four unauthenticated steps:

hardcoded OAuth app secret (public JS)
 → mint an app access token
 → enumerate webhook callback URLs (internal hosts leak)
 → hit a leaked webhook → production debug page
 → git remote in the debug page contains an admin-scoped GitHub PAT

hardcoded OAuth app secret (public JS)
 → mint an app access token
 → enumerate webhook callback URLs (internal hosts leak)
 → hit a leaked webhook → production debug page
 → git remote in the debug page contains an admin-scoped GitHub PAT

No user interaction, no victim, no privileged account. Just the public bundle.

The starting point: a secret that should never be in the browser

The app's frontend bundle shipped an OAuth App Secret in plaintext. Secrets like this are server-only by definition — the browser can't use them without exposing them.

curl -s "https://graph.example.com/oauth/access_token?client_id=REDACTED&client_secret=REDACTED&grant_type=client_credentials"
# {"access_token":"REDACTED|…","token_type":"bearer"}

curl -s "https://graph.example.com/oauth/access_token?client_id=REDACTED&client_secret=REDACTED&grant_type=client_credentials"
# {"access_token":"REDACTED|…","token_type":"bearer"}

Step 1 done. I now had a valid app token — authenticated as the company's own application. — -

Step 2: the secret maps out internal infrastructure

App tokens are supposed to be low-value. But with this one, the provider's API happily returned the app's webhook subscriptions — including internal callback URLs:

Step 3: a leaked webhook exposes a production debug page

One of the webhook URLs returned an HTTP 500 with a full laravel framework debug page when hit with a plain GET.

debug: true, env: production
framework and language versions
full filesystem paths
a git commit hash and commit message Debug mode in production is a classic finding on its own. But the page had something worse hidden in it

Step 4: the debug page leaks an admin GitHub token

Framework debug pages often embed a JSON "report" with app metadata — including the deployed app's git remote URL. In this case, the remote had a Personal Access Token baked into it:

Validation (metadata-only)

I confirmed the token without touching source code:

Impact

Source disclosure — full read of the private backend.
Supply-chain risk — push access allows code tampering.
Secrets exfiltration — CI/deploy secrets readable by an admin token.
Infrastructure mapping — webhook URLs + admin IDs leaked earlier in the chain.

Why this happened (root causes)

Hardcoded secrets in the client — the OAuth secret should live server-side, behind a proxy/BFF.
Debug mode in production — debug: true rendered stack traces and app metadata to the public.
Token in the git remote — a PAT embedded in the repo's remote URL, which then leaked through error reporting. Each one is a common mistake. Chained together, they produced a Critical. — -

Disclosure

This was found during authorized testing. I validated the token with metadata-only API calls — no source code was read or modified — and the organization revoked the token and rotated their secrets after disclosure.

Contents