How Verglos found a live API key in a 79,000-star repo

The finding: a live hardcoded API key in the hoppscotch/hoppscotch codebase. 79,000+ GitHub stars. Millions of installs. The advisory is now public as GHSA-jhrh-mp85-35j7.

It was found by a default run of Verglos. npx verglos in the cloned repo. No custom rules, no privileged access, no coordinated fuzzing infrastructure. The scan finished in under a minute.

This post is not a victory lap. It's a walkthrough — how the finding happened, how the disclosure ran, and what the pattern says about credential leakage in AI-era codebases.

The finding

The scanner flagged a file that shipped a real, working credential — the kind of secret that would let an attacker consume the associated third-party service on the project's dime and, depending on the API scope, exfiltrate or manipulate data. The scanner's provenance model flagged the surrounding file as AI-adjacent — repetitive tutorial-shaped comments, canonical example structure, and a "just make it work" idiom characteristic of prompt-completion output.

We verified the key was live by attempting an authenticated request to the service. The service returned 200. That is the definition of "not a false positive."

The disclosure

The right thing to do with a live credential is not to open a public PR removing it. Removing a leaked secret from main does not un-leak it — anyone with git access to a mirror already has it, and search indexes may have crawled it. The correct sequence is:

1. Rotate first. Contact the credential owner. Get a new key. Deactivate the old one. This step is a non-negotiable prerequisite for any public disclosure. Rotation happened before we touched GitHub.
2. Private advisory. File a private security advisory through GitHub's Security tab on the affected repo. Include the exact file, the exact line, the exact key prefix (never the full key), the reproduction, and a suggested patch. Give the maintainers a reasonable response window.
3. Patch. Once acknowledged, coordinate a patched release. Have the maintainer confirm the new key is in a secret manager, not in source.
4. Public advisory. The advisory becomes public when it's safe to do so — the key is dead, the fix is shipped, and the maintainer is ready. That's when the GHSA ID appears in searchable databases.

The whole sequence for this finding, from scan to public advisory, took about ten days. Most of that is maintainer response time, which is appropriate — the wrong incentive is to publish faster than the fix.

Why keys keep leaking in AI-era code

The pattern behind this finding is not unique to Hoppscotch, and it's not a knock on the maintainers. It is the natural consequence of how generative code is written:

• Every example works with a real value. LLMs generate example code that runs. A running example needs a value in the credential slot. The model reaches for the most common shape — sk_..., AIza..., ghp_... — and if the developer isn't paying attention, a real-looking placeholder becomes a real key after a copy-paste from a private notebook.
• .gitignore is not the last line of defense. The industry has a decade of muscle memory around gitignoring .env. That helps for framework defaults; it doesn't help when a credential is written directly into a config.ts, a test fixture, or an example folder that wasn't ignored.
• CI secret scanning fires late. Provider scanners (GitHub Secret Protection, similar) are excellent, but they run after the commit hits the platform. That's minutes-to-hours of exposure at a minimum.
• Rotation is skipped because it's operationally painful. Every leaked-secret post-mortem includes some variant of "we didn't rotate immediately because we didn't have a fast, safe way to do it without breaking prod." That gap is why 64% of credentials confirmed leaked in 2022 were still active in 2026, per publicly reported industry data.

The finding is not that Hoppscotch made a unique mistake. The finding is that this mistake is now happening at industrial scale, and the traditional defenses were designed for a world with fewer, more deliberate commits.

What any team can do this week

• Run npx verglos on every deployable repo you own. It's free, it doesn't require an account, and the scan runs locally — no credentials leave your machine. If you have secrets in code, you'll see them.
• When it flags one, treat rotation as step one. verglos rotate handles the common providers — it revokes the old key, mints a new one from the provider's own API, writes it to your .env, and verifies your app still boots. Runs on your machine. Your credentials never touch us.
• Add the scanner to CI as a non-blocking check on PRs, then a blocking check on main. The step-function fix is not "one more security tool" — it's making the same tool run in three places (dev, PR, main) so a leaked secret is caught before the second push.
• Have an attest step at handover. If you ship code to a client, generate a signed report at delivery. verglos attest --client "Acme Corp" produces a dated, verifiable report URL. If a credential ever leaks in a delivered codebase, the timeline is unambiguous.

The scoreboard

We publish every advisory Verglos contributes to as a permanent artifact. Every GHSA ID with our name in the credit line is a bit of public record — good for maintainers who patched fast, good for the developers who need to trust the tool, good for anyone tracking whether the industry is getting better.

GHSA-jhrh-mp85-35j7 is #1. There will be more.

Responsible disclosure enabled by the Hoppscotch maintainers, who acted quickly and correctly. Thanks to the GitHub security advisory team for smooth coordination.