Security1 publisher2 min readPublished
Hush Security found hardcoded credentials in 12% of credential slots across 82,000 public MCP configs
Hush Security searched public GitHub for the configuration filenames coding agents write, classified how each credential slot gets its value, and found a hardcoded literal in 12% of them, most of which match no vendor token format.
The Watch · Security desk
What happened
- Hush Security analyzed around 82,000 configuration files found on public GitHub and reported that 12% of credential slots contained a hardcoded credential literal.
- Where scope could be classified, 53% of the credentials granted organization-, account-, workspace- or database-wide access to whatever holds them.
- Hush calls the numbers lower-bound estimates because GitHub code search indexes only default branches, excludes forks and caps results for individual queries.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- capability Anyone can enumerate this population the way the researchers did, by searching public code for the configuration filenames coding agents write. No exploit is involved, and no vulnerability gets patched.
- exposure For the 24% of literals that are broad-scope and non-expiring by design, one committed slot keeps reaching a whole workspace, account or database until a human revokes it. Time does not close it.
- decision Pre-commit blocking is the wrong lever when the file belongs in the repository, so the control moves upstream to what the slot holds: an environment variable, a secret-manager reference, or a prompt.
- cost Cleanup lands on whoever owns the provider account, not the developer who committed the file, because only rotation at the provider ends an exposure that survives in Git history.
A credential slot, in this study, is an environment value or an authentication header inside a Model Context Protocol configuration file. Hush searched public GitHub repositories for the configuration filenames used by major coding agents and sorted every slot it found into one of six states: hardcoded value, environment-variable reference, client-managed prompt, secret-manager reference, placeholder, or empty [3][4].
A scanner keyed to provider token formats would match 45% of the hardcoded secrets on sight [10]. The other 55% had no vendor-recognizable format [9]. To judge those, Hush used key names, length, entropy and character patterns, and reported that the values were predominantly vendor API keys, bearer tokens and database passwords, with non-secret identifiers a negligible share [11].
The hardest subset is the 31% that Hush classified as opaque bearer tokens for internal MCP servers [9]. "These files are meant to be committed; the secret never should be," said Micha Rave, CEO of Hush Security [15]. "When it is, the highest-risk credentials in them match no known pattern, and the identities behind them have no owner and no expiry," he said [22].
MCP connections can give an agent permission to interact with source code, databases, cloud infrastructure and other services on behalf of a user or an organization [21]. The agent authenticates as a non-human identity, without a person signing in for each interaction [25]. Among credentials that had a defined expiration policy, 80% did not expire by default [20].
Deleting the line does not close it. Hush walked back up to seven revisions through 7,681 credential-bearing configurations and found 243 where the secret was gone from the current file but still present in an earlier commit [12], about 3.2% of that set [13]. Rotating the credential at the provider is what ends the exposure, because removing it from the current file leaves it in Git history [14].
The 12% is a floor. GitHub code search indexes default branches, excludes forks and limits results per query, so Hush treats its numbers as lower-bound estimates [6]. The researchers did not attempt to authenticate with any value they found [7], and some of the credentials may have been revoked or rotated since they were committed [8]. No raw secret values were retained [23]. The work is Hush Security's own, published as The State of MCP Configuration: The Identity Security Gaps [1], and it measures files on public GitHub, not whether any organization's scanning rules cover the filenames its agents write.
What to watch
- Whether an independent researcher reproduces the 12% figure on a corpus outside GitHub default branches, or tests how many of the tokens still authenticate.
- Whether coding-agent vendors change config defaults so a credential slot takes an environment-variable or secret-manager reference instead of a literal.
- Whether GitHub secret scanning and push protection add MCP configuration filenames and entropy heuristics for unrecognized bearer tokens.