Attack scenario 5: Credential leakage through logs and crash dumps

Attack scenario 5: Credential leakage through logs and crash dumps

The final scenario does not involve an active attacker at all, at least not initially. The credentials leak through normal operational processes, and the attacker later finds them.

How the attack works

During a debugging session, a developer enables verbose logging on an MCP server to trace an authentication failure with the GitHub API. The debug logs capture the full HTTP request, including the Authorization: Bearer ghp_... header. These logs are shipped to the team's centralized logging platform (Datadog, Splunk, ELK). Six months later, an attacker who compromises the logging platform, or an insider who should not have access to production credentials, searches for common credential patterns and finds valid GitHub tokens, database connection strings, and AWS access keys, enough to access sensitive data across multiple services and establish persistent access.

A related vector involves crash dumps. When an MCP server crashes, the operating system may generate a core dump that captures the entire process memory, including every credential loaded at startup. If crash reports are sent to an error tracking service or attached to a bug report in a public issue tracker, the credentials are exposed.

What to look for

• Log entries containing Authorization, Bearer, token, password, or secret in cleartext
• Core dump files generated by the MCP server processes
• Log searches by users who do not normally access infrastructure logs
• Crash reports from MCP servers that include environment variable dumps

How to defend against it

• Implement automatic secret redaction in logging pipelines: Configure your log aggregation platform to detect and mask credential patterns (API key formats, connection strings, bearer tokens) before they are stored. Most platforms support regex-based redaction rules.
• Sanitize crash dumps: Configure your systems to either disable core dumps for MCP server processes or to automatically scrub them of credential-like patterns before storage or transmission.
• Restrict log access: Apply least-privilege access to your logging platform. Developers debugging application logic should not have access to infrastructure logs that may contain credentials.
• Use runtime credential fetching: Instead of loading secrets into environment variables at startup, fetch them from a secrets manager at runtime, i.e., the moment your MCP server actually needs them. That way, credentials spend less time sitting in process memory and are far less likely to leak into crash dumps or log entries. This does not eliminate the risk, but it meaningfully reduces your exposure window.

Each scenario above includes detection signals tied to their specific attack vector. But in practice, you will get better results by connecting signals across multiple layers rather than relying on a single alert. The checklist below provides a starting point for building layered coverage.