CVE-2026-81668: Rubygem-katello: cross-tenant content view filter rule access and modification via unauthorized parent filter lookup
A flaw was found in Katello where the Content View Filter Rules API does not properly enforce authorization on the parent Content View Filter. An authenticated, low-privileged user with Content View permissions in one organization may be able to access and modify filter rules belonging to a Content View Filter in another organization by supplying that filter's identifier. This can result in unauthorized disclosure of filter-rule information and unauthorized changes to unpublished Content View filter configuration.
Other sources
An object-level authorization bypass in Katello's Content View Filter Rules API.
Katello::Api::V2::ContentViewFilterRulesController#findfilter (app/controllers/katello/api/v2/contentviewfilterrulescontroller.rb) loads the parent filter with ContentViewFilter.find(params[:contentviewfilterid]). That beforeaction runs for every action. The rules route is top-level and carries no content view identifier, so this lookup is the only object resolution in the request. Authorization only checks whether the user may invoke the action (viewcontentviews for read, editcontentviews for write). It does not authorize the Content View Filter supplied by the user.
The adjacent ContentViewFiltersController already resolves filters with ContentViewFilter.readable.findby(...) for reads and ContentViewFilter.editable.findby(...) for modifications. ContentViewFilter has no default organization scope; readable and editable are explicit class methods and are unused here. Katello::Model does not include Authorizable, so there is no post-save permission rollback when a rule is created or deleted.
An authenticated, low-privileged user with Content View permissions scoped to one organization can therefore read, create, update, and delete filter rules on a Content View Filter belonging to another organization by supplying that filter's identifier, even when that filter is absent from ContentViewFilter.readable and ContentViewFilter.editable.
The disclosed data is filter-rule metadata. Modifications persist in the live filter configuration used for the next Content View publish. Already-published Content View versions are snapshots and are not rewritten by this endpoint. Publish and promote remain separate permissions.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated low-privileged user who has Content View permissions in one organization can target filter rules in another organization. Read actions require permission to view Content Views, while modification actions require permission to edit Content Views.
What does an attacker need to provide?
The attacker must supply the identifier of a Content View Filter belonging to another organization. The API loads that parent filter directly from the supplied content_view_filter_id without authorizing access to that specific filter.
Are unpublished configurations affected?
Yes. The issue can disclose filter-rule information and allow unauthorized changes to unpublished Content View filter configuration.