A flaw was found in the foremanremoteexecution plugin's template invocations controller. The showtemplateinvocationbyhost action resolves the job invocation by ID without evaluating the caller's viewjobinvocations permission filter against the record. An authenticated user whose job invocation visibility is restricted by a permission filter can enumerate job invocation IDs and read the live output, rendered script, and input values for other users' job invocations within their own organizations.

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.