How Verglos handles active credential disclosures
A responsible-disclosure note on live credentials, private maintainer contact, and why public proof should wait until rotation is confirmed.
By TopNotchh Security

Verglos found a credential exposure in a public open-source repository during a normal local scan.
We are withholding the repository name, exact credential type, file path, surrounding code, report artifact, and validation details while outreach is still active. That is the only responsible public position until the affected team or credential owner confirms rotation.
This post is not a victory lap. It is the workflow we follow when a scanner finds something that may still be usable.
The finding
The scanner flagged a committed credential-shaped value in application code. We performed the minimum validation needed to separate a real risk from a false positive, then stopped.
That distinction matters. A security product should produce evidence, but evidence is not a license to publish details before a fix exists.
For now, the public proof is intentionally limited to this disclosure policy. The detailed report remains private.
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:
- Rotate first. Contact the maintainer or credential owner. Get the old value deactivated before any public detail is shared.
- Private advisory or private maintainer channel. Use the repository's security process. Include enough detail for maintainers to verify the issue, but never publish the full key.
- Patch. Once acknowledged, coordinate a patched release. Have the maintainer confirm the new key is in a secret manager, not in source.
- Sanitized public record. Discuss the finding only after the key is dead, the fix is shipped, and the maintainer or credential owner is not put at new risk.
The wrong incentive is to publish faster than the fix. Security content should never outrun rotation.
Why keys keep leaking in AI-era code
The pattern behind this finding is not unique to any one team, and it is not a knock on maintainers. It is the natural consequence of how modern 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. .gitignoreis 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 aconfig.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 one project 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 vergloson 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. Revoke the old key, mint a new one, move it into your secret manager or deployment environment, and verify the app still boots.
- 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. - Keep evidence at handover. If you ship code to a client, keep a dated scan report at delivery. If a credential ever leaks in a delivered codebase, the timeline is unambiguous.
The scoreboard
We publish sanitized disclosure records only when they help readers without exposing maintainers, forks, or downstream users to new risk.
For this active disclosure, the public record stays intentionally narrow until rotation is confirmed.
Responsible disclosure means the proof survives without making the original exposure worse.