Topic starter
19/10/2026 5:39 pm
TL;DR: Truffle Security's analysis of public GitHub comments, issue threads, and pull requests finds live API keys and passwords are exposed in plain text. Security teams need to treat comments as an exposure surface and revoke leaked credentials immediately, because cleanup alone may leave the secret usable.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Think Twice Before Commenting: Thousands of GitHub Comments Leak Live API Keys”.
By the numbers:
- Human users authored 97% of comments containing leaked secrets in the dataset.
- Truffle Security sees 1800 new secrets leaked in GitHub git pushes every day.
Key questions
Q: Why are public issue and pull request comments risky for secret exposure?
A: They are persistent, searchable collaboration surfaces where users can paste live credentials into plain text.
A: Security teams should assume deletion, editing, or privacy changes do not guarantee removal of exposed secrets.
Q: What should teams do first when a live API key is posted in a public comment?
A: Rotate or revoke the exposed credential immediately.
Practitioner guidance
- Expand scanning to comments and edit history Include GitHub issue comments, pull request comments, and prior comment versions in secret-detection coverage so exposed credentials are found where users actually paste them.
- Rotate exposed keys before cleanup is considered complete If a live secret appears in a public comment, revoke or rotate the credential immediately and treat deletion of the comment as a secondary housekeeping task.
- Mask automated bot output in public threads Review any automation that comments on pull requests or issues and ensure its output never reveals tokens, credentials, or other sensitive values in plain text.
Bottom line: Public collaboration tools can leak live API credentials even when no code is committed.
Glossary terms: Secrets Leakage, Comment History Exposure, Credential Revocation
What's in the full report
Truffle Security's full post covers the operational detail this post intentionally leaves for the source:
- The sampling method used to inspect public GitHub pull request and issue comments across a large historical dataset
- Examples of how users exposed secrets in plain text comments and how edit history preserved the original values
- The TruffleHog scan flags used to inspect issue and pull request comments directly
- Practical disclosure examples showing how the researchers contacted affected parties after finding live credentials
👉 Read Truffle Security's analysis of live API keys exposed in GitHub comments →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago 2 times by NHI Mgmt Group
19/10/2026 5:39 pm
Secret leakage has moved out of the codebase and into the collaboration layer. The important governance shift in this article is that public issue and pull request comments are now part of the credential attack surface, not just a communication channel. That widens the control boundary for NHI programmes because secrets governance has to cover text entry fields, comment history, and disclosure response as one workflow. The practitioner implication is to expand secret detection to every user-generated field that can persist or be replayed.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between secret leakage in code and secret leakage in comments?
A: Code leakage usually happens inside the development artifact, while comment leakage happens in a communication layer that many teams do not monitor as closely. Both can expose live credentials, but comment leakage is often driven by support or collaboration behaviour rather than build mistakes. That means secret detection must cover non-code text fields, and response playbooks must assume the secret may already be public even if the repository itself is clean.
👉 Read our full editorial: GitHub comments expose live API keys beyond committed code
This post was modified 2 days ago by NHI Mgmt Group