Description
The foreman-mcp-server contains two distinct logging mechanisms that expose sensitive session and authentication data.  

Exposure occurs across two tiers: 

Diagnostic Over-logging (INFO Level): The server relies on the MCP Python SDK (Upstream: modelcontextprotocol/python-sdk). By default, this library logs the creation of new transports and their associated mcp-session-id at the INFO level. While this is standard diagnostic behavior for the SDK, the foreman-mcp-server implementation fails to suppress or filter these logs. Because the server improperly treats the session ID as an authentication credential (as proven in F-34 MCP Server: Active Session Hijacking via Insecure Session State Reuse), this default behavior results in the leakage of session secrets in standard, non-debug application logs. 

Incomplete Sanitization Logic (DEBUG Level): The LoggingMiddleware (src/foreman_mcp_server/middleware/logging.py) records the full HTTP request header dictionary when the log level is set to DEBUG. This middleware utilizes a negative security model (block-list) that only masks four hardcoded keys: foreman_password, foreman_token, password, and token. Any header not explicitly on this list, such as Authorization, Cookie, or X-Satellite-Secret, is logged in cleartext. 

IMPACT

 

Confidentiality Breach: Sensitive Bearer tokens, Session IDs, and API keys are persisted in plain text within the container logs. 

Log Aggregation Risk: If logs are forwarded to a centralized platform (e.g., ELK, Splunk, CloudWatch), the secrets become searchable and accessible to a wider pool of users (developers, auditors, SREs) who may not have authorization to the Foreman API itself. 

Non-Compliance: This behavior directly violates global security standards that prohibit the storage of sensitive authentication data in audit logs. 

RECOMMENDATIONS

 

Address Diagnostic Verbosity (Dependency Fix): Configure the application's logging dictionary to set the mcp.server logger to WARNING or higher. This will suppress the default INFO level transport creation logs from the SDK. 

Adopt an Allow-list (Positive Security Model): Re-engineer _sanitize_headers to mask all header values by default. Only allow-list known non-sensitive headers (e.g., host, user-agent, accept, content-type). 

REFERENCES

 

CWE-532: Insertion of Sensitive Information into Log File 

OWASP Logging Cheat Sheet 

https://github.com/modelcontextprotocol/python-sdk