1. Executive summary
Hush Security analysed roughly 82,000 publicly accessible MCP configuration files on GitHub and found that 12% of credential slots contained a hardcoded credential literal, exposing API keys, access tokens and database passwords for connected services. Of the hardcoded secrets, 55% matched no vendor-recognizable token format, meaning pattern-based secret scanning will miss them, and 24% were of types that are broad-scope and non-expiring by design. The research also shows that deleting a secret from the current file does not end the exposure: in a sample of 7,681 credential-bearing configurations, 243 still contained the secret in earlier commits after removal from the current version. No exploitation of these credentials is reported, and no CVE, CVSS score or CISA-KEV entry applies to this item. For EMEA financial services the risk is credential-based access to connected systems through developer tooling configuration, not a patchable product flaw.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item. The research describes an exposure class and aggregate findings across public repositories; it does not report an incident at a named entity, a major ICT-related incident, or a specific third-party provider relationship. Clients that discover their own credentials in this population would trigger DORA Art. 18 (classification of ICT-related incidents and cyber threats) and potentially DORA Art. 19 (reporting of major ICT-related incidents to competent authorities) at that point, but the source material contains no such finding.
3. Technical analysis & attack chain
This is an exposure finding, not an observed attack. There is no confirmed attack chain: the researchers did not authenticate with any discovered value and report no exploitation. The exposure mechanism, confirmed by the source, is as follows.
- Developers commit MCP configuration files for AI coding tools to public GitHub repositories. These files are meant to be committed; the credential inside them is not.
- Credential slots in those files are populated in one of six ways: hardcoded values, environment-variable references, client-managed prompts, secret-manager references, placeholders, or empty fields.
- In 12% of credential slots across the analysed population, the value was a hardcoded credential literal, visible to anyone who can search GitHub code search.
- Discovery is trivial at scale: GitHub code search indexes default branches, so searching for configuration filenames used by major coding agents surfaces the files directly.
The composition of the exposed material matters for detection. Of the hardcoded secrets, 55% had no vendor-recognizable token format, including 31% classified as opaque bearer tokens for internal MCP servers. Where no provider-specific format existed, researchers classified values as likely credentials using key names, length, Shannon entropy and character patterns; the values were predominantly vendor API keys, bearer tokens and database passwords, with non-secret identifiers a negligible share. Scope compounds the problem: 53% of credentials with a classified scope provided organization-, account-, workspace- or database-wide access, and of credentials with a defined expiration policy, 80% did not expire by default. Of the hardcoded credential literals, 24% were of types that are both broad-scope and non-expiring by design.
Git history creates a second exposure surface. Researchers examined up to seven revisions before the current version for 7,681 credential-bearing configurations and found 243 where a secret had been removed from the current file but remained in an earlier commit. Rotation at the provider is the only action that ends the exposure; deleting the value from the current configuration leaves it recoverable from history.
Two caveats on the numbers. First, GitHub code search indexes default branches only, excludes forks and limits results per query, so Hush treats the figures as lower-bound estimates rather than precise counts. Second, some credentials may have been revoked or rotated since they were committed, so the live-exposure rate is unknown. The entire dataset is single-sourced: it comes from one vendor report, Hush Security's "The State of MCP Configuration: The Identity Security Gaps". No raw secret values were retained and findings were aggregated and anonymized, so no repository-level or client-specific indicators exist.
4. Mitigation & containment
P1 (within 24h): Search your organisation's GitHub presence, including public repositories and their full commit history, for MCP configuration files and hardcoded credential literals in environment values and authentication headers. Treat any hit as exposed regardless of whether the file is current, because the value remains in Git history after deletion.
P1 (within 24h): For every credential found, rotate it at the provider. Rotation is the only remediation that ends the exposure; removing the secret from the current file or rewriting history does not invalidate the credential. Prioritise credentials that are broad-scope or non-expiring, which per the source are 24% and, of those with an expiration policy, 80% by default.
P2 (within 72h): Audit how MCP credential slots are populated in your standard developer tooling. Move from hardcoded values to environment-variable references or secret-manager references, which the source identifies as the non-exposed categories. Block commits containing credential literals in these files with pre-commit secret scanning, and note the source's finding that 55% of hardcoded secrets match no vendor token format, so entropy-based detection is required alongside pattern matching.
P2 (within 72h): Assign owners and expiry policies to MCP-connected identities. The source quotes Hush's CEO stating that the identities behind the highest-risk credentials "have no owner and no expiry", which is a governance gap rather than a scanning gap.
P3 (within 7 days): Review historical repositories and forks for MCP configuration files that were deleted or archived, since secrets persist in commit history. Where history rewriting is being considered, treat it as hygiene only and confirm the credential was rotated first.
5. Indicators of compromise
No indicators of compromise available in the source material. The research is aggregated and anonymized, contains no repository names, credential values, file hashes or network indicators, and reports no observed malicious use of the exposed credentials.
6. Detection
Insufficient indicators to author detection rules. The source contains no threat artefacts: no credential literals, no file contents, no command lines, no registry keys and no network indicators. The configuration filenames referenced in the research are described only generically as "configuration filenames used by major coding agents" and are not named, so they cannot be used as rule strings without fabrication.
7. Sources
- Help Net Security, "Hardcoded MCP credentials found in public GitHub files", https://www.helpnetsecurity.com/2026/09/18/hush-security-mcp-credential-exposure-report/, 2026-09-18
- Hush Security, "The State of MCP Configuration: The Identity Security Gaps" (report referenced by the primary source; not independently reviewed)
8. Adverse Trace position
We assess this as a medium-severity exposure finding for EMEA financial services: no exploitation is reported, but the exposed population includes broad-scope, non-expiring credentials to connected services, and 55% of them evade pattern-based secret scanning. The findings are single-sourced from one vendor report and the counts are lower-bound estimates, so clients should verify their own exposure directly rather than rely on the aggregate figures; verify before enforcement. The clients most exposed are those whose developers use AI coding tools with MCP configurations in public repositories, particularly where internal MCP server bearer tokens are involved. We will monitor for follow-on reporting of credential abuse traced to this exposure population and for independent corroboration of Hush's figures, and we will update this advisory if repository-level findings or exploitation emerge.
Published via PulseTrace — Adverse Trace threat intelligence.