foreman-mcp-server EUVD-2026-38603

Two independent exposure conditions exist. First, session identifier logging is unconditionally active at the INFO log level in foreman-mcp-server - no special configuration, feature flag, or mode is required. Any running instance logs session IDs in plaintext, affecting all deployments. Second, HTTP header leakage (Authorization tokens, Bearer tokens, API keys) only occurs when debug logging is explicitly enabled, which is non-default in production but common during troubleshooting. Both paths require the attacker to have read access to the affected container's logs or to a downstream system receiving those logs (SIEM, log archive, OpenShift logging stack). This log-read prerequisite is the primary limiting factor - environments enforcing strict RBAC on log access reduce exploitability substantially. The CVSS PR:N metric reflects that no privilege against Satellite itself is required, but it does not capture the log-access prerequisite. No network-accessible entry point exists; exploitation is confined to the local log access boundary.

The vendor-provided CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, score 6.2) classifies this as Medium severity with local attack vector, low complexity, and high confidentiality impact. The PR:N metric warrants scrutiny: while no privilege is required to trigger the logging behavior (it occurs automatically), an attacker must possess read access to container logs or a downstream log aggregation system to extract credentials - this is a meaningful prerequisite that the raw PR:N signal obscures. Real-world risk is highly deployment-dependent: environments restricting log access to cluster administrators face considerably lower exposure than those routing logs to broadly accessible SIEM platforms with permissive read policies. The INFO-level session ID logging path is always active and does not require debug mode, making it the higher-priority concern. The debug-mode header leakage is conditional but potentially more damaging (API keys vs. session tokens). No EPSS score was provided, no KEV listing exists, and no POC has been identified, which collectively suggest this is not being actively exploited at scale. The primary risk is insider threat or post-breach lateral movement via credential harvesting from log archives.

An attacker or malicious insider with read access to Red Hat Satellite 6 container logs - whether via direct kubectl logs access, a SIEM query, or access to an OpenShift logging namespace - passively scans INFO-level log entries and extracts session identifiers that are persistently written in cleartext. These session tokens are then replayed against the Satellite API to impersonate a legitimate administrator or service account, enabling unauthorized access to managed infrastructure, content views, or provisioning workflows without triggering standard authentication events.