Fedora Account System
Red Hat Associate
Red Hat Customer
The show_template_invocation_by_host action in TemplateInvocationsController resolves the job invocation via JobInvocation.find(params[:id]) and the host via Host.find(params[:host_id]) without performing an object-level authorization check against the caller's view_job_invocations permission filter. The controller-level before_action :authorize checks only that the caller holds a view_job_invocations 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?(:view_job_invocations, @template_invocation.job_invocation), 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 default_scope -> { where(taxonomy_conditions) }, which limits host lookup to the caller's organizations. The attacker must supply a host_id 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 input_safe_value), task details, and host/proxy information. The V2 API controller has a related gap: the output and raw_output actions in Api::V2::JobInvocationsController resolve the JobInvocation via find_optional_nested_object (bare find) rather than find_resource (which applies authorized(:view_job_invocations)). The host IS properly scoped via authorized(:view_hosts), so the V2 gap is bounded by host authorization. Introduced in foreman_remote_execution 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.