A flaw was found in Foreman. This vulnerability allows an authenticated user with low-level Viewer permissions to cause unauthorized information disclosure by submitting requests to template preview endpoints. By exploiting this issue, the user can access sensitive data, such as host root passwords. Furthermore, under insecure system configurations where Safemode protections are disabled, the flaw may allow the user to execute arbitrary commands as the Foreman system account.

When accessing certain API endpoints (e.g. POSTing to /template/preview) a user with the Viewer role is able to access information they should not be able to (i.e. @host.rootpass). When the system is configured insecurely (i.e. Safemode is disabled), or a Safemode bypass vulnerability exists, then the Viewer is able to perform Remote Code Execution on the system as the foreman system account.

A flaw was found in the foremanansible plugin's Ansible inventory API. The controller builds its host query using an unscoped Host.where call that does not enforce the search filter associated with the caller's viewhosts permission. An authenticated user whose host visibility is restricted by a permission filter can supply arbitrary host IDs within their organization and receive the full Ansible inventory for those hosts, including parameter values marked as hidden.

A flaw was found in Foreman. An authenticated attacker with low-level permissions can achieve remote code execution (RCE) by bypassing the safemode sandbox within the templating engine. Due to improper handling of delegated methods, an attacker can append unauthorized functions to the allowed execution list, enabling them to run arbitrary commands on the hosting server.

A Safemode bypass attack has been identified that exposes a number of weaknesses in Foreman leading to low-privilege (i.e. minimum "view" permissions) to be able to perform limited Remote Code Execution (RCE). It appears that a copy of the delegatemethods to the local scope allows an adversary to append eval to the permitted methods list leveraged by safemode, thus permitting RCE through the templating engine.

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

A flaw was found in Foreman. The foreman-rake initialization logic in /usr/share/foreman/config/settings.rb contains a vulnerable code pattern where configuration data is processed through two distinct executable layers. This creates a multi-stage execution chain that allows for both Server-Side Template Injection (SSTI) and insecure deserialization. This vulnerability can lead to remote code execution, total infrastructure compromise and supply chain risk.

Description

The foreman-rake initialization logic in /usr/share/foreman/config/settings.rb contains a vulnerable code pattern where configuration data is processed through two distinct executable layers. This creates a Multi-Stage Execution Chain that allows for both Server-Side Template Injection (SSTI) and Insecure Deserialization.

The vulnerability execution chain has two stages:

Template Injection (ERB): The first stage uses ERB.new(...).result. This evaluates the file as a Ruby template. Any code inside <%= ... %> is executed by the Ruby interpreter to generate a string. This is an SSTI that allows for direct OS command injection.

Insecure Deserialization (YAML): The second stage takes the rendered string and passes it to YAML.load. Because this is an unsafe parser, it allows for object injection. Even if an attacker cannot use ERB tags, they can craft YAML that instantiates malicious Ruby "gadget chains" to achieve code execution.

The vulnerability exists in two different application functionalities, thus it can be exploited in two different ways:

Primary config:

SETTINGS.merge! YAML.load(ERB.new(File.read(settingsfile)).result) allows an attacker to craft a malicious /etc/foreman-maintain/foremanmaintain.yml file that will be loaded and executed by foreman-rake on start.

Plugins config:

SETTINGS.merge! YAML.load(ERB.new(File.read(f)).result) allows an attacker to craft a malicious file that will be executed from /usr/share/foreman/config/settings.plugins.d/ by foreman-rake on start.

Impact

Indirect Triggering & Privileged RCE: foreman-rake exposes underlying execution primitives that higher-level orchestration tools (like foreman-maintain or foreman-installer) rely on to interact with the application. Because these tools implicitly pass commands down, the vulnerability can be triggered indirectly during routine administrative operations, resulting in Remote Code Execution (RCE) in a high-trust context (often foreman or root).

Total Infrastructure Compromise: Compromising the management plane (Satellite server) allows an attacker to pivot and execute arbitrary code across all Satellite Managed Hosts.

Supply Chain Risk: While direct local exploitation requires prior root access, this flaw presents a critical supply chain risk. An adversary could distribute malicious plugins or compromised configuration files through public repositories (e.g., RubyGems, GitHub). Note: The CVSS vector and severity are based on this supply chain attack vector.

RECOMMENDATIONS

Replace YAML.load with YAML.safeload(content, permittedclasses: [Symbol]) in both locations in settings.rb.

Remove the ERB.new().result evaluation. Configuration files must be treated as static data, never as executable templates.

A flaw was found in Foreman. OS command injection vulnerabilities exist in the foreman-rake db:dump and db:importdump tasks. The application fails to properly sanitize user-supplied input in the destination parameter (during backups) and the file parameter (during imports) before passing them to a Ruby system() call for execution. An attacker with permissions to execute foreman-rake (e.g., via a restricted sudo configuration) can append malicious shell commands to the provided file paths.

A flaw was found in Foreman. The Red Hat Satellite /unattended/provision API endpoint is vulnerable to an authentication bypass due to a semantic logic flaw in hostverifier.rb. The application verifies the database state of a provisioning token rather than its actual presence in the incoming HTTP request. Because a host actively undergoing provisioning has an unexpired token in the database, the server's validhosttoken? method evaluates to true, granting access to the kickstart template even if the requester provides no token at all in the URL.

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 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

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.

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

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.

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 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.

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 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.

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

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.

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.

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 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.

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.

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

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

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