REDHAT-BUG-2535942: Medium severity foreman_remote_execution vulnerability
The showtemplateinvocationbyhost action in TemplateInvocationsController resolves the job invocation via JobInvocation.find(params[:id]) and the host via Host.find(params[:hostid]) without performing an object-level authorization check against the caller's viewjobinvocations permission filter. The controller-level beforeaction :authorize checks only that the caller holds a viewjobinvocations permission covering the controller action; it does not evaluate the permission's search filter against the specific record. The sibling show action in the same controller explicitly performs User.current.can?(:viewjobinvocations, @templateinvocation.jobinvocation), which is the object-level form.
JobInvocation includes Authorizable but not Taxonomix and has no taxonomy default scope, so the job invocation ID is unconstrained. Host::Base carries defaultscope -> { where(taxonomyconditions) }, which limits host lookup to the caller's organizations. The attacker must supply a hostid within their organizations that was targeted by the job invocation.
The action returns live output (stdout/stderr), the rendered script preview, template input values (hidden values are masked via inputsafevalue), task details, and host/proxy information.
The V2 API controller has a related gap: the output and rawoutput actions in Api::V2::JobInvocationsController resolve the JobInvocation via findoptionalnestedobject (bare find) rather than findresource (which applies authorized(:viewjobinvocations)). The host IS properly scoped via authorized(:viewhosts), so the V2 gap is bounded by host authorization.
Introduced in foremanremoteexecution v15.0.0 by commit 45bd8b894424c9316516001fa0c44a0cedd70a2b (MariaAga, 2025-01-24, Fixes #38123, "add template invocation info to new job details"). The sibling show action has had the object-level User.current.can? check since 2016 (commit d194bf0, Fixes #13287). The new action added in 2025 did not replicate the check. All versions from v15.0.0 through v18.0.0 (current HEAD) are affected.
Affected Software
Event History
Frequently Asked Questions
What access and conditions are required to retrieve another job invocation's details?
The caller must have permission to access the controller action and must provide a host_id for a host in their organizations that was targeted by the job invocation. The job invocation ID itself is not constrained by the caller's organizations or by the permission's object-level search filter.
What information can the affected action disclose?
The action returns live job output, including stdout and stderr, along with the rendered script preview and template input values. Hidden input values are masked.
Does the host organization restriction prevent cross-organization job invocation access?
No. The host lookup is limited to the caller's organizations, but the job invocation lookup is not taxonomy-scoped and does not perform the required object-level authorization check. A qualifying in-organization host targeted by the invocation is still required.