A flaw was found in Foreman. The Usergroup model in Foreman does not properly validate role assignments against the calling user's permissions. This allows an authenticated user with usergroup management permissions to attach arbitrary roles, including administrative roles, to a user group and then add themselves as a member. Successful exploitation of this vulnerability leads to full privilege escalation, granting the attacker administrator-level access.

A command injection flaw was found in Red Hat Satellite 6.16.5.2 (Foreman 3.12.0.8-1). Although a whitelist for CoreOS Transpiler Command and Fedora CoreOS Transpiler Command is implemented, the whitelist is only enforced on the client-side and is not validated on the server-side. This flaw allows an authenticated user with editsettings permissions to modify these parameters to achieve arbitrary command execution on underlying operating system and bypass safe mode rendering.

A flaw was found in Foreman. A remote attacker could exploit a command injection vulnerability in Foreman's WebSocket proxy implementation. This vulnerability arises from the system's use of unsanitized hostname values from compute resource providers when constructing shell commands. By operating a malicious compute resource server, an attacker could achieve remote code execution on the Foreman server when a user accesses VM VNC console functionality. This could lead to the compromise of sensitive credentials and the entire managed infrastructure.

A flaw was found in the foreman-mcp-server. A session management vulnerability in the MCP Server allows unauthenticated attackers to hijack active administrative sessions due to an improper cache of authenticated client connections, by trusting a non-secret session ID without re-validating authentication tokens and by logging all newly created session IDs to standard logs. This issue can result in privilege escalation and infrastructure-wide code execution.

A disclosure of sensitive information flaw was found in foreman via the GraphQL API. If the introspection feature is enabled, it is possible for attackers to retrieve sensitive admin authentication keys which could result in a compromise of the entire product's API.

A flaw was found in foreman before version 3.3. The server exposes a GraphQL API with limited access. If introspection is enabled (usually by default), it allow attackers to query a settings type without any authentication and retrieve the product settings, including the OAuth consumerkey and OAuth consumersecret properties. These elements can be used to authenticate as foremanapiadmin and gain full control of the product's REST API.

Summary: A critical command injection vulnerability exists in Foreman's WebSocket proxy implementation (lib/wsproxy.rb). The vulnerability occurs when constructing shell commands using unsanitized hostname values from compute resource providers. An attacker operating a malicious compute resource server (VMware vSphere, Libvirt, etc.) can achieve remote code execution on the Foreman server when an administrator accesses VM console functionality.

Requirements to exploit: An attacker needs to operate a malicious compute resource server (such as a fake vSphere server) that returns poisoned hostname values. The Foreman administrator must then configure this malicious server as a compute resource and attempt to access the VM console through the normal workflow.

Component affected: foreman

Version affected: Foreman <= 3.17.0 (confirmed), likely all versions from the past 4+ years (wsproxy.rb unchanged since 2020)

Patch available: Yes (need to be reviewed and verified)

Line 44 - Sanitize host parameter safehost = Shellwords.escape(host) Use array form to prevent shell injection cmdarray = [ 'websockify', '--daemon', "--idle-timeout=#{idletimeout}", "--timeout=#{timeout}", port.tos, "#{safehost}:#{hostport}" ] Add SSL options cmdarray += ['--ssl-target'] if ssltarget if Setting[:websocketsencrypt] cmdarray += ['--cert', Setting[:websocketssslcert]] if Setting[:websocketssslcert] cmdarray += ['--key', Setting[:websocketssslkey]] if Setting[:websocketssslkey] end Execute without shell interpretation Open3.popen3(cmdarray) do |stdin, stdout, stderr| # ... existing error handling End Version fixed (if any already): N/A

CVSS: Proposed by reporter - CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (Base Score: 8.8 High)

My understanding of the situation (6.8 Medium/High; Still serious, but not "internet critical" – CVSS:3.1/AV:A/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H) Impact (optional): This vulnerability allows remote code execution as the foreman user, providing direct access to Foreman's database credentials and encryption keys. This enables decryption of all stored infrastructure credentials (vCenter, AWS, SSH keys, API tokens), allowing the attacker to pivot and compromise the entire managed infrastructure. Based on Red Hat's classification, this would be considered Critical impact due to the potential for complete infrastructure compromise. Embargo needed: Yes Reason: Given it is command injection Public date: Need to set default 90-days. There is no date received from the reporter.

Acknowledgement: Houssam Sahli

Steps to reproduce if available: 1. Start malicious vSphere server (attacker system): python3 maliciousvsphereserver.py 2. Configure Foreman compute resource (Foreman UI): - Navigate to: Infrastructure → Compute Resources → Create Compute Resource - Provider: VMware - VCenter/Server: <attackerip> (malicious server address) - Username: user - Password: pass - Load Datacenters (it will load EvilDatacenter) - Display Type: VNC - Uncheck "VNC Console Passwords" and "Enable Caching" - Click "Submit" 3. Trigger exploitation: - Navigate to Virtual Machines tab - Locate "TestVM" in the list - Click Actions → Console 4. Verify RCE (Foreman server): find /tmp -name "vsphererce.txt" 2>/dev/null cat /tmp/systemd-private-/tmp/vsphererce.txt Expected output: foreman

A vulnerability was found in Satellite. When running a remote execution job on a host, the host's SSH key is not being checked. When the key changes, the Satellite still connects it because it uses "-o StrictHostKeyChecking=no". This flaw can lead to a man-in-the-middle attack (MITM), denial of service, leaking of secrets the remote execution job contains, or other issues that may arise from the attacker's ability to forge an SSH key. This issue does not directly allow unauthorized remote execution on the Satellite, although it can leak secrets that may lead to it.

n authorization flaw in Foreman's GraphQL API allows low-privileged users to access metadata beyond their assigned permissions. Unlike the REST API, which correctly enforces access controls, the GraphQL endpoint does not apply proper filtering, leading to an authorization bypass.

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.

A potential XSS issue within Foreman / Katello has been reported. It is possible to inject JavaScript code into the Description field of a User and save it. This code is then executed when opening certain pages (e.g., Host Collections).

A command injection vulnerability was identified in Foreman, affecting the "Host Init Config" template. The issue arises when commands are injected through the "Install Packages" field on the "Register Host" page. An attacker with elevated privileges on the Foreman server could craft malicious commands, which would be executed when the host is registered. This could lead to unauthorized actions.

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

larry campbell reports via the foreman bug tracker:

This was found on Foreman 1.9.0:

I came across this issue by chance. I was forced to change my Active Directory password today. After doing so, I then (mistakenly) attempted to log onto Foreman with my previous password and was able to successfully log in. The new password also worked. I tried with other browsers and even another workstation that I had never logged onto and all attempts allowed me to log on with my non-valid previous password. Perhaps something on foreman/passenger/ruby/etc is caching my credential and not re-checking?

Initial Setup: Have an Active Directory enviornment available for LDAP Authentication. Setup LDAP Authentication Source in Foreman and have a test user account created in Active Directory.

Steps to recreate: 1. Log on to Foreman with the Active Directory user. This should succeed. Log off. 2. Change your Active Directory account's password. 3. Log on to Foreman with the Active Directory user, and use the previous password. This should fail with authentication denied method, however it succeeds.

Upstream references: http://projects.theforeman.org/issues/11471

A password leak was identified on Foreman project which will expose password in plaintext through Foreman Datacenter plugin.

In puppet-candlepin shipped with the foreman-installer rpm, when calling /usr/share/candlepin/cpdb with --password, cpdb calls liquibase.sh (which calls java) and that leaks the password in the process list.

It was reported that non-admin users with the viewhosts permission containing a filter are able to access API routes beneath "hosts" such as GET /api/v2/hosts/secrethost/interfaces without the filter being taken into account. This allows users to access network interface details (including BMC login details) for any host.

Affects Foreman 1.10.0 and higher.

Upstream bug:

http://projects.theforeman.org/issues/15653

An authentication bypass vulnerability has been identified in Foreman when deployed with Gunicorn versions prior to 22.0, due to the puppet-foreman configuration. This issue arises from Apache's modproxy not properly unsetting headers because of restrictions on underscores in HTTP headers, allowing authentication through a malformed header. This flaw impacts all active Satellite deployments (6.13, 6.14 and 6.15) which are using Pulpcore version 4.0+ and could potentially enable unauthorized users to gain administrative access.

Hi, From [2]: #### CVE-2024-7923: Authentication bypass in Pulpcore An authentication bypass vulnerability has been identified in Pulpcore when deployed by the Foreman Installer with Gunicorn versions prior to 22.0. This issue arises from the way Apache is configured to do certificate authentication and pass this information to the Gunicorn backend, without unsetting all headers coming from a possibly malicious client. Affects Katello 4.0.0 and higher Fix released in Foreman 3.10.1, 3.11.2, 3.12.0 GitHub PR puppet-pulpcore#357 #### CVE-2024-7012: Authentication bypass in Foreman An authentication bypass vulnerability has been identified in Foreman when deployed by the Foreman Installer with External Authentication. This issue arises from the way Apache is configured to do certificate authentication and pass this information to the Puma backend, without unsetting all headers coming from a possibly malicious client. Affects Foreman 2.2.0 and higher Fix released in Foreman 3.10.1, 3.11.2, 3.12.0 GitHub PR puppet-foreman#1181 Further References: [1] https://community.theforeman.org/t/foreman-3-11-2-is-now-available/39370 [2] https://theforeman.org/security.html#2024-7923 [3] https://access.redhat.com/security/cve/CVE-2024-7012 [4] https://access.redhat.com/security/cve/CVE-2024-7923 https://projects.theforeman.org/issues/37786?tab=changesets https://projects.theforeman.org/issues/37787?tab=changesets

Kind regards, Christian

Hi,

A security vulnerability has been fixed in Foreman, an open-source infrastructure lifecycle management tool.

CVE-2026-1961: Remote Code Execution via command injection in WebSocket proxy

A command injection vulnerability was discovered in Foreman's WebSocket proxy implementation. The vulnerability occurs when constructing shell commands using unsanitized hostname values from compute resource providers (such as VMware vSphere, Libvirt, etc.). An attacker operating a malicious compute resource server can achieve remote code execution on the Foreman server when an administrator accesses VM console functionality through the normal workflow.

Affected versions: Foreman up to and including 3.18.0

CVSS v3.1 Score: 8.0 (High) Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H

Fixed in: Foreman 3.18.1, Foreman 3.17.2, Foreman 3.16.3

Credit: Houssam Sahli

References: - Foreman security page: https://theforeman.org/security.html#2026-1961 - Redmine issue: https://projects.theforeman.org/issues/39121 - GitHub PR: https://github.com/theforeman/foreman/pull/10921

Thanks, Ondrej Gajdusek Foreman Project

Hi,

Multiple security fixes have been released in Foreman, an open-source lifecycle management tool for physical and virtual servers.

---

CVE-2026-5136: Foreman: Privilege escalation via usergroup role assignment manipulation

The Usergroup model does not validate whether the calling user is permitted to assign the specified roles. A user with createusergroups or editusergroups permission can attach arbitrary roles to a usergroup via the API, add themselves as a member, and inherit elevated privileges.

Affected versions: all Foreman versions CVSS: 8.8 (Important) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Fixed versions: 3.18.2, 3.19.1 Credit: Stanislav Fot (Aisle Research)

References: - Foreman Security: https://theforeman.org/security.html#2026-5136 - Redmine: https://projects.theforeman.org/issues/39478 - Fix: https://github.com/theforeman/foreman/pull/11066

---

CVE-2026-5142: Foreman: Cross-tenant private SSH key disclosure via taxonomy scoping bypass

The KeyPairsController#show action is excluded from the findcomputeresource callback that enforces taxonomy scoping. An authenticated user with the viewkeypairs permission can download the full PEM private key of any compute resource by database ID, bypassing organization and location boundaries.

Affected versions: all Foreman versions since 1.15.0 CVSS: 6.5 (Moderate) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N Fixed versions: 3.18.2, 3.19.1 Credit: Stanislav Fot (Aisle Research)

References: - Foreman Security: https://theforeman.org/security.html#2026-5142 - Redmine: https://projects.theforeman.org/issues/39479 - Fix: https://github.com/theforeman/foreman/pull/11069

---

CVE-2026-5135: Foreman: Unauthorized modification of host configurations via broken access control

When lookup values are submitted as nested attributes during host or hostgroup updates, the match field is permitted and applied without ownership validation. A user with host-edit rights can retarget an existing lookup value override to point at a different host, injecting configuration values into hosts they are not authorized to edit.

Affected versions: all Foreman versions CVSS: 6.5 (Moderate) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N Fixed versions: 3.18.2, 3.19.1 Credit: Stanislav Fot (Aisle Research)

References: - Foreman Security: https://theforeman.org/security.html#2026-5135 - Redmine: https://projects.theforeman.org/issues/39480 - Fix: https://github.com/theforeman/foreman/pull/11072

---

CVE-2026-5138: Foreman: Information disclosure via improper validation of nested request parameters

The taxonomyscope controller method loads organization and location IDs from nested request parameters without checking the user's taxonomy membership. An authenticated user with host-edit permissions can supply a foreign organization ID in nested parameters to scope AJAX queries to a tenant they do not belong to, leaking infrastructure metadata such as domains, subnets, and IP availability.

Affected versions: all Foreman versions since 1.7.0 CVSS: 4.3 (Moderate) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N Fixed versions: 3.18.2, 3.19.1 Credit: Stanislav Fot (Aisle Research)

References: - Foreman Security: https://theforeman.org/security.html#2026-5138 - Redmine: https://projects.theforeman.org/issues/39481 - Fix: https://github.com/theforeman/foreman/pull/11075

---

Thanks, Ondrej Gajdusek Foreman Release Team

CVE-2016-7078: Foreman user with no organizations or locations can see all resources

A user account that is associated to no organizations or locations is able to view resources from all organizations/locations in the web UI or API, when either the organization or location feature is enabled. The user remains subject to permissions and filters on their assigned roles.

Mitigation: ensure all users are assigned to at least one organization or location, or disable the feature if unused.

This issue was reported by Daniel Lobato Garcia.

Affects all known Foreman versions Fix due to be released in Foreman 1.15.0

Patch: https://github.com/theforeman/foreman/commit/5f606e11cf39719bf62f8b1f3396861b32387905

More information: https://theforeman.org/security.html#2016-7078 http://projects.theforeman.org/issues/16982 https://theforeman.org

-- Dominic Cleal dominic () cleal org