A flaw was found in foreman-mcp-server. This component utilizes two distinct logging mechanisms that can expose sensitive session and authentication data. One mechanism logs session identifiers, which are treated as authentication credentials, at an informational level. The other, when debug logging is enabled, incompletely sanitizes HTTP request headers, leading to the cleartext logging of sensitive information such as authorization tokens and API keys. This vulnerability can result in a confidentiality breach, as sensitive authentication data is persisted in plain text within container logs, increasing the risk if logs are forwarded to a centralized platform.

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/foremanmcpserver/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: foremanpassword, foremantoken, 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 sanitizeheaders 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