SW-CFG-002: Credential written into an MCP server configuration
Last updated 7 November 2026
| Fact | Value |
|---|---|
| Severity | Critical |
| Checks | Configuration file |
| Malicious indicator | No |
| OWASP Agentic Top 10 | None mapped |
| OWASP MCP Top 10 | MCP01, MCP07 |
| NIST SP 800-53 | IA-5 (provisional mapping to SP 800-53 base controls) |
| First shipped in | Scanner 0.3.0 |
What it detects
The rule reads each server of the MCP client files and tests every value the entry can carry: each item of env, each header of headers and each item of args. A value fires when it matches one of the credential shapes the scanner knows: an AWS access key id (AKIA or ASIA followed by sixteen capitals or digits), a GitHub token (ghp_, gho_, ghu_, ghs_ or ghr_ with at least 36 letters or digits after it, or github_pat_), a GitLab glpat- token, a Slack xox token, an Anthropic sk-ant- key, a 32-character sk- key, a Google AIza key, the header line of a PEM private key, or a JSON web token of three parts.
A header also fires when its name holds the word authorization and its value is Bearer or Basic followed by a literal that is neither a variable reference nor a placeholder. The finding is on the server's line. The evidence names the server, the field (for example env.AWS_ACCESS_KEY_ID) and the first four characters of the value followed by three stars, never the rest. A value under a secret-sounding name that matches none of these shapes belongs to SW-CFG-010.
Why it matters
A configuration file is committed, cloned, forked and read by anything that scans code, so a credential written into one reaches everyone and everything with access to the repository, not only the person who typed it. The file is also copied into build logs, backups and agent context. The scanner maps this rule to OWASP MCP01, Token Mismanagement & Secret Exposure, and MCP07, Insufficient Authentication & Authorization, and to NIST SP 800-53 control IA-5, Authenticator Management. It is critical because a value in a known shape is usable as it stands.
Example
The server below passes an AWS access key id in its environment. The value contains the word EXAMPLE and opens nothing, but it has the shape of a real key id:
.mcp.json
{
"mcpServers": {
"release-notes": {
"command": "npx",
"args": [
"-y",
"release-notes-mcp@1.4.2"
],
"env": {
"AWS_ACCESS_KEY_ID": "AKIAIOSFODNN7EXAMPLE"
}
}
}
}The evidence reads the server name, env.AWS_ACCESS_KEY_ID and AKIA***; the rest of the value is not shown.
How to fix
Remove the value from the file and treat it as exposed: revoke it at the provider and issue a new one, because the old value stays in the git history. Then write a reference where the value was.
The rule accepts ${NAME}, ${env:NAME}, ${input:ID} and $NAME as references. Which of these your client expands is up to the client, so check its documentation before you rely on one.
If it is a false positive
A published sample key that has a real key's shape is reported like any other value. Accept the finding with a note that names the sample, or write the sample in a form the shapes do not match, for example a run of lowercase x characters after the prefix.
If the finding is not a problem in your case, accept it with a note: in the dashboard a manager or owner can accept a finding and the note is kept with it; with the scanner on its own, add it to the baseline file with a reason and an expiry date.