An object-level authorization bypass in Katello's Content View Filter Rules API.

Katello::Api::V2::ContentViewFilterRulesController#find_filter (app/controllers/katello/api/v2/content_view_filter_rules_controller.rb) loads the parent filter with ContentViewFilter.find(params[:content_view_filter_id]). That before_action 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 (view_content_views for read, edit_content_views for write). It does not authorize the Content View Filter supplied by the user.

The adjacent ContentViewFiltersController already resolves filters with ContentViewFilter.readable.find_by(...) for reads and ContentViewFilter.editable.find_by(...) 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.